3 ms·

Well, HTTP 3 is standardized off the initial QUIC implementation (UDP), yes. Update: I guess, technically, HTTP 3 is the protocol built on top of the QUIC prot

Well, HTTP 3 is standardized off the initial QUIC implementation (UDP), yes. Update: I guess, technically, HTTP 3 is the protocol built on top of the QUIC protocol.

jupp0r 3y ago
Exactly, it uses QUIC as the transport layer. You can do more with QUIC, there are beta implementations to use it for WebRTC data channels[1] and there have been experiments to use it for for WebRTC media transport, for example[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_over_QUIC_At_WebRTC_TPAC_2018.pdf https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_ove...
- still_grokking 3y ago
  WebRTC? I'm not sure WebRTC has a bright future. AFAIK nobody ever implemented WebRTC on top of QUIC. The new kid on the block is called WebTransport. WebTransport could be described in short as "WebRTC / WebSocket, the good parts". It's way simpler than WebRTC and solves some issues with WebSocket like the lack of low-latency unreliable transport (WebTransport can send Datagrams without having to use a reliable connection channel for that). A big difference to WebRTC is: All the STUN / TURN complexity is gone. WebTransport gives you at the end more or less almost "raw" QUIC streams or datagrams. It's almost like a socket interface for web user agents, only with all the features of QUIC. Given you have already HTTP/3 (which implies you have also QUIC) WebTransport is a pretty simple and slim addition on top: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht... (The only thing I'm missing is client authentication. It would be really good to do this in-band, and for example allow to send client certs with the WebTransport CONNECT request. For some reason this was left out on purpose. Only that I did not find out why actually.) What I'm not sure about is who good WebTransport would be in a P2P scenario. But given libp2p implemented WebTransport it would seem that it's good for that also. (So could replace WebRTC completely.)
  - jackewiehose 3y ago
    > A big difference to WebRTC is: All the STUN / TURN complexity is gone but STUN / TURN is there for a reason. I always thought of the P2P scenario as the main use case for WebRTC.
    - still_grokking 3y ago
      I don't know about any significant use case of WebRTC in the P2P space. OTOH, like mentioned, libp2p implemented WebTransport. So WT seems to be also adequate for the P2P use case. (No clue about the details there, though. So maybe they had to jump loops to make it happen. But it doesn't look like there would be major show stoppers.)
      - jackewiehose 3y ago
        It looks like STUN/TURN can be integrated with QUIC so you don't need additional ports, but I wouldn't say "the complexity is gone" ;-) https://w3c.github.io/p2p-webtransport/ https://w3c.github.io/p2p-webtransport/ > This specification extends the WebRTC [WEBRTC], ORTC [ORTC] and WebTransport [WEBTRANSPORT] APIs to enable peer-to-peer operation using QUIC [RFC9000]. This specification supports the exchange of arbitrary data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. As specified in [RFC7983bis], QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, allowing the API defined in this specification to be utilized along with the functionality defined in [WEBRTC] and [ORTC] including communication using audio/video media and SCTP data channels.
        still_grokking 3y ago
        Oh, that's cool! :-D It implements the missing parts on top of WebTransport. I was especially sad that WT doesn't do client authentication. You can't send credentials with a CONNECT request. But this thingy adds exactly this. Great! Also having some standardized way to open QUIC Streams through NAT sounds nice. (Even I think the proper fix for this issues would just be IPv6.) Frankly it's very early days. It's not implemented, and not even considered currently. > It is not a W3C Standard nor is it on the W3C Standards Track. But as I'm currently into implementing a WebTransport lib maybe I should try to add the features form this draft. Would be funny to have a P2P ready WT lib. Only that NAT traversal part I would leave out for now, I guess, as I'm not sold on the idea that this complexity is strictly needed. NAT just needs to die finally…

Well, HTTP 3 is standardized off the initial QUIC implementation (UDP), yes. Update: I guess, technically, HTTP 3 is the protocol built on top of the QUIC protocol.

jupp0r 3y ago

Exactly, it uses QUIC as the transport layer. You can do more with QUIC, there are beta implementations to use it for WebRTC data channels[1] and there have been experiments to use it for for WebRTC media transport, for example[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Using_data_channels https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/... [2] https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_over_QUIC_At_WebRTC_TPAC_2018.pdf https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_ove...

still_grokking 3y ago
WebRTC? I'm not sure WebRTC has a bright future. AFAIK nobody ever implemented WebRTC on top of QUIC. The new kid on the block is called WebTransport. WebTransport could be described in short as "WebRTC / WebSocket, the good parts". It's way simpler than WebRTC and solves some issues with WebSocket like the lack of low-latency unreliable transport (WebTransport can send Datagrams without having to use a reliable connection channel for that). A big difference to WebRTC is: All the STUN / TURN complexity is gone. WebTransport gives you at the end more or less almost "raw" QUIC streams or datagrams. It's almost like a socket interface for web user agents, only with all the features of QUIC. Given you have already HTTP/3 (which implies you have also QUIC) WebTransport is a pretty simple and slim addition on top: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3/ https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht... (The only thing I'm missing is client authentication. It would be really good to do this in-band, and for example allow to send client certs with the WebTransport CONNECT request. For some reason this was left out on purpose. Only that I did not find out why actually.) What I'm not sure about is who good WebTransport would be in a P2P scenario. But given libp2p implemented WebTransport it would seem that it's good for that also. (So could replace WebRTC completely.)
- jackewiehose 3y ago
  > A big difference to WebRTC is: All the STUN / TURN complexity is gone but STUN / TURN is there for a reason. I always thought of the P2P scenario as the main use case for WebRTC.
  - still_grokking 3y ago
    I don't know about any significant use case of WebRTC in the P2P space. OTOH, like mentioned, libp2p implemented WebTransport. So WT seems to be also adequate for the P2P use case. (No clue about the details there, though. So maybe they had to jump loops to make it happen. But it doesn't look like there would be major show stoppers.)
    - jackewiehose 3y ago
      It looks like STUN/TURN can be integrated with QUIC so you don't need additional ports, but I wouldn't say "the complexity is gone" ;-) https://w3c.github.io/p2p-webtransport/ https://w3c.github.io/p2p-webtransport/ > This specification extends the WebRTC [WEBRTC], ORTC [ORTC] and WebTransport [WEBTRANSPORT] APIs to enable peer-to-peer operation using QUIC [RFC9000]. This specification supports the exchange of arbitrary data with remote peers using NAT-traversal technologies such as ICE, STUN, and TURN. As specified in [RFC7983bis], QUIC can be multiplexed on the same port as RTP, RTCP, DTLS, STUN and TURN, allowing the API defined in this specification to be utilized along with the functionality defined in [WEBRTC] and [ORTC] including communication using audio/video media and SCTP data channels.
      - still_grokking 3y ago
        Oh, that's cool! :-D It implements the missing parts on top of WebTransport. I was especially sad that WT doesn't do client authentication. You can't send credentials with a CONNECT request. But this thingy adds exactly this. Great! Also having some standardized way to open QUIC Streams through NAT sounds nice. (Even I think the proper fix for this issues would just be IPv6.) Frankly it's very early days. It's not implemented, and not even considered currently. > It is not a W3C Standard nor is it on the W3C Standards Track. But as I'm currently into implementing a WebTransport lib maybe I should try to add the features form this draft. Would be funny to have a P2P ready WT lib. Only that NAT traversal part I would leave out for now, I guess, as I'm not sold on the idea that this complexity is strictly needed. NAT just needs to die finally…