Re: [w3ctag/design-reviews] TAG Review Request: RTCQuicTransport (#303)

**Introduction to WebRTC-QUIC**

The WebRTC-QUIC specification is designed as an extension to both the ORTC API as well as the WebRTC 1.0 API, to enable peer-to-peer data exchange utilizing the QUIC protocol.  An example scenario addressed by this specification is peer-to-peer file transfer compatible with audio/video (e.g. sending a large photo during a video call with a grand-parent). 

Currently, the WebRTC and ORTC specifications provide support for data exchange based on SCTP/DTLS/UDP protocol stack as specified in the IETF RTCWEB WG , but deployments have encountered limitations that are addressed in QUIC:

1. While in principle SCTP could support pluggable congestion control compatible with audio/video congestion control algorithms, QUIC's rapid adoption as an HTTP transport has attracted the developer commitment to make this possible (multiple implementations supporting pluggable congestion control are in progress), whereas SCTP deployment on the Internet remains rare and therefore the congestion control algorithms have not kept up with the state-of-the-art. 

2. The greater developer interest in QUIC has also enabled the development of multiple QUIC libraries utilizable in a variety of scenarios, including high-performance server-side libraries, whereas all major SCTP data channel deployments utilize a single library that is suitable largely for client-side uses. 

**Limitations**

Given the emphasis on peer-to-peer data exchange, the specification currently assumes that communicating peers first establish connectivity utilizing ICE and then utilize self-signed certificates within the QUIC ciphersuite negotiation, which is based on TLS 1.3. This is similar to the model utilized for DTLS by WebRTC and ORTC user agents.  As currently specified, this means that the WebRTC-QUIC specification is not well suited for client-server scenarios where ICE is not utilized or where validation of a certificate chain would be required.  Extensions to the specification may be considered in the future to enable those scenarios (such as allowing an RTCQuicTransport to be constructed utilizing a URL (similar to Websockets). 

The WebRTC-QUIC specification currently does not enable all of the data exchange scenarios  by the existing RTCDataChannel API, and therefore QUIC data exchange is envisaged as a supplement to, rather than a replacement for SCTP data channel support.  The specification currently supports reliable data exchange only, since this is the only mode of operation supported in the IETF QUIC transport specification.  However, there have been proposals to support unreliable QUIC streams and so the design could be extended in future to support that mode of operation (by adding parameters to the createStream method) once those features have been added to QUIC. 

Since it is envisaged that QUIC may be utilized alongside SCTP/DTLS/UDP as well as audio/video, it is necessary to support  multiplexing of the IETF QUIC transport protocol (see:  https://tools.ietf.org/html/draft-ietf-quic-transport ) with other WebRTC protocols, including RTP/RTCP/STUN/TURN/DTLS.  This is supported by the most recent IETF QUIC transport draft, though not by initial QUIC implementations.  As a result, initial experimental implementations of WebRTC-QUIC will require a newly created `RTCIceTransport` to be passed in the constructor, rather than being able to start with an `RTCIceTransport` vended as described in WebRTC 1.0.  This is a motivation for the WebRTC-ICE specification. 

**About the API Design**

The design provides access to the QUIC stream abstraction rather than offering a message-based API similar to Websockets or WebRTC data channels or the abstractions defined in the Streams API.  However, this design decision did not arise from a decision to exclude support for a message-based or Streams interface, but rather a desire to provide maximum flexibility to developers, after background work indicated the feasibility of providing support for the RTCDataChannel API or Streams API on top of  this specification. 

The WebRTC-QUIC API is based on early versions of the IETF QUIC transport specification which has been evolving, and therefore as noted in the specification, it will evolve to match changes to the transport, such as the addition of support for uni-directional streams.  

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/303#issuecomment-419536789