QUIC Websockets

[maxogden]

I was talking with Van Jacobsen who is on the Websockets spec committee and he suggested a strategy might be to propose for Websockets V2 that they add a QUIC transport, which would address a lot of the issues raised in the readme here. There was a googler working on QUIC datachannels (https://www.youtube.com/watch?v=mIvyOFu1c1Q) but I dont think it ever shipped.

[Maksims]

Sounds like this is relates to WebSockets UDP Extension option with use of QUIC extension.

This is definitely worth exploring!

[Maksims]

Sounds like this is relates to WebSockets UDP Extension option with use of QUIC extension.

This is definitely worth exploring!

[Matheus28]

I'm a bit against using QUIC, since just like WebRTC, it feels too bloated. Here's Google's example server/client.

Giving access to raw UDP datagrams might be way simpler for developers (after a handshake, probably over TCP, and possibly taking advantage of WebSocket's existing handshake and only extending it with an extension).

[Matheus28]

I'm a bit against using QUIC, since just like WebRTC, it feels too bloated. Here's Google's example server/client.

Giving access to raw UDP datagrams might be way simpler for developers (after a handshake, probably over TCP, and possibly taking advantage of WebSocket's existing handshake and only extending it with an extension).

[MstWntd]

What about sctp?.. Last I heard it is somewhat of a mashup between tcp and udp.

[MstWntd]

What about sctp?.. Last I heard it is somewhat of a mashup between tcp and udp.

[Matheus28]

SCTP is dead, many routers don't support it, thus they're rarely routed over public internet.

Just to expand on my last post: QUIC does have its advantages: it automatically handles several things that some developers might overlook in their implementation, like congestion control.

[Matheus28]

SCTP is dead, many routers don't support it, thus they're rarely routed over public internet.

Just to expand on my last post: QUIC does have its advantages: it automatically handles several things that some developers might overlook in their implementation, like congestion control.

[Maksims]

QUIC been out there for some time, but only been adopted by Google.

It looks like its been designed for internal use, not as WebSockets was designed from ground up with simplicity in mind, ensuring widest adoption by back-end developers as well as front-end developers.

[Maksims]

QUIC been out there for some time, but only been adopted by Google.

It looks like its been designed for internal use, not as WebSockets was designed from ground up with simplicity in mind, ensuring widest adoption by back-end developers as well as front-end developers.

[Maksims]

SCTP - has reliability and ordered delivery techniques embedded into protocol. We're not trying to find alternative for TCP, but a different transport protocol that intentionally lacks of reliability and ordered delivery to benefit certain use cases.

[Maksims]

SCTP - has reliability and ordered delivery techniques embedded into protocol. We're not trying to find alternative for TCP, but a different transport protocol that intentionally lacks of reliability and ordered delivery to benefit certain use cases.

[MstWntd]

Dccp was the other one I heard about.. And with that my list of recommendations is exhausted..

[MstWntd]

Dccp was the other one I heard about.. And with that my list of recommendations is exhausted..

[maxogden]

The advantage of QUIC in my mind is that it provides transport level encryption while still offering 0RTT or 1RTT connections. If you expose raw UDP to JS then it opens up a plethora of security and privacy issues. In a post HTTPS-Everywhere world I do not think a new networking protocol that doesn't include mandatory encryption will get introduced to the web platform. WebRTC/SCTP is not suitable as a discovery protocol (e.g. Kademlia) due to the expensive connection overhead (5-6RTT).

[maxogden]

The advantage of QUIC in my mind is that it provides transport level encryption while still offering 0RTT or 1RTT connections. If you expose raw UDP to JS then it opens up a plethora of security and privacy issues. In a post HTTPS-Everywhere world I do not think a new networking protocol that doesn't include mandatory encryption will get introduced to the web platform. WebRTC/SCTP is not suitable as a discovery protocol (e.g. Kademlia) due to the expensive connection overhead (5-6RTT).

[Matheus28]

@maxogden It wouldn't expose raw UDP. It would have a handshake first (being a WebSocket extension is an easy solution). Client requests it with Sec-Websocket-Extensions, server confirms availability with the same header. A simple implementation would provide a sendUnreliable method on the WebSocket object that sends a datagram instead, and also listens for replies. The host it would send to must be the same as the websocket host, but the port could be specified by the server using Sec-Websocket-Extensions.

I am very against mandatory encryption. Sure many argue that encryption everywhere benefits everyone, but there are applications (mainly games) in which it's very desirable to minimize latency and CPU usage, and encryption has a non-zero impact on that.

Allowing insecure datagrams along a secure websocket connection is ideal, as anything that should be secure can just go over the tcp pipe, and stuff that needs to get there fast can use udp.

[Matheus28]

@maxogden It wouldn't expose raw UDP. It would have a handshake first (being a WebSocket extension is an easy solution). Client requests it with Sec-Websocket-Extensions, server confirms availability with the same header. A simple implementation would provide a sendUnreliable method on the WebSocket object that sends a datagram instead, and also listens for replies. The host it would send to must be the same as the websocket host, but the port could be specified by the server using Sec-Websocket-Extensions.

I am very against mandatory encryption. Sure many argue that encryption everywhere benefits everyone, but there are applications (mainly games) in which it's very desirable to minimize latency and CPU usage, and encryption has a non-zero impact on that.

Allowing insecure datagrams along a secure websocket connection is ideal, as anything that should be secure can just go over the tcp pipe, and stuff that needs to get there fast can use udp.

[maxogden]

@Matheus28 wouldnt the handshake to setup the websocket defeat the purpose of trying to expose udp in the first place (unreliable multicast type use cases), and also be more overhead than QUIC?

[maxogden]

@Matheus28 wouldnt the handshake to setup the websocket defeat the purpose of trying to expose udp in the first place (unreliable multicast type use cases), and also be more overhead than QUIC?

[Maksims]

wouldnt the handshake to setup the websocket defeat the purpose of trying to expose udp in the first place (unreliable multicast type use cases)
I'm afraid such use case would be very hard to implement in form of secure API that would live in the web.

An effort of this discussion is to find low-latency server-client communication solution. Not to implement UDPSocket.

[Maksims]

wouldnt the handshake to setup the websocket defeat the purpose of trying to expose udp in the first place (unreliable multicast type use cases)
I'm afraid such use case would be very hard to implement in form of secure API that would live in the web.

An effort of this discussion is to find low-latency server-client communication solution. Not to implement UDPSocket.

[maxogden]

@Maksims if you aren't interested in 0RTT transports (reducing latency of connection establishment to open up the possibility of doing DHT's in the browser, etc) then I'd suggest renaming this initiative

[maxogden]

@Maksims if you aren't interested in 0RTT transports (reducing latency of connection establishment to open up the possibility of doing DHT's in the browser, etc) then I'd suggest renaming this initiative

[Maksims]

@Maksims if you aren't interested in 0RTT transports (reducing latency of connection establishment to open up the possibility of doing DHT's in the browser, etc) then I'd suggest renaming this initiative

Updated the document to make it more clean regarding intentions of initiative.

[Maksims]

@Maksims if you aren't interested in 0RTT transports (reducing latency of connection establishment to open up the possibility of doing DHT's in the browser, etc) then I'd suggest renaming this initiative

Updated the document to make it more clean regarding intentions of initiative.