Filling in relative information from @martinthomson's post in the original TAG review:

The Role of QUIC

As a generic building block, ICE has some fairly dire limitations. ICE relies on some out-of-band arrangement (in RTC terms, a signaling channel) that establishes session identifiers (in ICE terms ufrag and password) that are used to indicate consent. That makes it difficult to use. Servers that want to provide their own access would need to provide an HTTP server that provided a rendezvous capability.

QUIC presents a new possibility. Right now, deployment of QUIC is non-existent in its standardized form. The QUIC handshake provides the same sort of consent that ICE provides, without the awkward signaling requirements. So it is possible that we could decide that the web could support direct QUIC connections from browsers.

That is, direct access to QUIC connections, with no additional protections other than its inherent consent-to-communicate mechanisms and an expectation that QUIC deployments do not assume that access to the network implies authorization. That might be too risky, but a simple flag in the QUIC handshake would be all we need to signal consent to communicate with a web browser. No need for ICE, except where it is necessary for establishing peer-to-peer communications.

That's a discussion I think that we should have with our friends at the IETF. I don't think that shipping an RTC-based API for QUIC is advisable without having some discussion of the more fundamental issues (and possibilities).

That discussion might take some time, because it's not currently a priority for the QUIC WG. At least, that is my understanding, but you could check with @mnot and @larseggert for a more authoritative view on that, I'm merely a document editor.

One immediate consequence of this for the proposed QUIC API is in the way in which it does authentication. The mechanisms presently replicate the mechanisms we have for peer-to-peer, which would not fit with a more generic model. They assume that the site that oversees the signaling is trusted to decide identity and do not attribute any particular identity to communication peers (absent other work, which allows that authority to be shifted to a third party).

Of course, there are many other things to consider here, such as how an API like this potentially results in multiple connections from the same browser to the same server because multiple origins use the same capability, or how this might interact with the service worker lifecycle.

Other Issues

These are relatively minor concerns, but I thought I append them anyway, so there is a record in text. The editors of the WebRTC QUIC API spec (and chairs of the WG) haven't been particularly receptive to these comments, and will no doubt provide some defense, but I'll list them anyway. These are minor points relative to the rest of this, but it's worth pointing out.

1. QUIC isn't finished. The IETF getting closer to finishing the core transport, but the protocol is still subject to change. In particular, there are very few HTTP/QUIC implementations, so we are concerned that we might learn something important. The response to this has been something like "we intend to be ready when QUIC is and the basic API contracts seem to be stable". That is fine for experiments, but it seems like there is shipping code, or there soon will be. That might have long-term consequences. Waiting a little is probably wise.

2. If the QUIC API contracts are stable, then the API is failing to implement them. Critically, it fails to provide support for unidirectional streams. As a low-level API, it might also be necessary to allow more control over other protocol features like transport parameters, ALPN, and the aforementioned authentication snarl. The API doesn't do anything for 0-RTT either, though here I agree with the spec editors: 0-RTT is hard, so deferring support is sensible.

3. The QUIC API uses the same awful flow control mapping pioneered by websockets. Websockets was developed before streams existed, but that is no reason to keep the bad API. The solution to the consistency problem is to retrofit streams on websockets, not to propagate its infidelities.

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.

Work-in-Progress

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 also evolve to match changes to the transport specification, such as the addition of support for uni-directional streams.

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 supported 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 argument(s) to the createStream method) once those features have been added to QUIC.

Since it is envisaged that QUIC may be utilized alongside SCTP data channels as well as audio/video, it is necessary to support multiplexing of the IETF QUIC transport protocol with other WebRTC protocols, including RTP/RTCP/STUN/TURN/DTLS.

While multiplexing is supported by the most recent IETF QUIC transport draft (see: https://tools.ietf.org/html/draft-ietf-quic-transport), initial QUIC implementations did not support multiplexing. As a result, experimental implementations of the WebRTC-QUIC built on earlier versions of the QUIC protocol may require a newly constructed RTCIceTransport to be passed in the RTCQuicTransport constructor, rather than being able to reuse an RTCIceTransport vended as described in WebRTC 1.0, since transporting QUIC over an RTCIceTransport vended as a the result of an SDP negotiation of audio/video or data channel support would require multiplexing.

Low Level Design

The design provides low-level access to the QUIC stream abstraction rather than offering a message-based API similar to Websockets or WebRTC data channels or direct access to the Streams abstraction defined in the WHATWG Streams API. However, this approach did not arise from a desire to exclude support for a message-based or Streams interface. Since background work indicated the feasibility of providing support for the RTCDataChannel API or Streams API on top of the RTCQuicStream abstraction, the low-level approach taken in the design enables alternative APIs to be built on top of it.

To counter the arguments against streams:

1. One could implement the currently proposed read/write API on top of the streams API. It is just as low level (if you want it to).
2. Streams allow implementations to optimise the data flow when piping from an internal source to an internal sink (e.g. piping an HTTP response to a QUIC stream - one could for example skip the extra hop though the JS layer) or when applying internal transform streams (that are exposed).
3. The API of streams potentially reduces copying with the BYOB concept by writing data directly into the provided buffer whereas the currently proposed API provides no way to achieve that.

Yeah, I second @lgrahl's points, and remain optimistic that as this API graduates out of the incubation and prototyping phase into something that browsers would be willing to implement and ship, it aligns with other web platform streaming primitives and reuses that infrastructure.

Much like the previous transition across the platform from ad-hoc callback interfaces to a standardized promise interface, an interoperable base primitive that solves many of the hard problems makes things easier for developers and spec-writers alike. I imagine that new RTC APIs will want to join that work, and look forward to working with them to make it happen. With any luck it should reduce the effort for the spec authors and implementers both. E.g. the reinvention of the high-water mark concept and the tracking that goes along with it in https://github.com/w3c/webrtc-quic/pull/53 and elsewhere would be unnecessary if the streams infrastructure was used.

/cc some of the active folks in the recent pseudo-streams work, @pthatcherg and @aboba.

I get an "Access denied" page if I try to look at the explainer. Could it be made visible?

I get an "Access denied" page if I try to look at the explainer. Could it be made visible?

It should be public with the link. Let me know if you're still having problems.

Thank you for raising the review. We've discussed this during the last call (and I have volunteered to provide feedback on this, but haven't managed to find time until now) and we share the concerns from @martinthomson regarding this being dependent on a incomplete spec.

During the last call, we generally found that the explainer may need a bit more coverage on the problems this proposal is attempting to solve, including tradeoffs and generalization potential outside of the scope of WebRTC.

The API pattern being built on top of the WebSockets design feels quite a lot like a limitation rather than a convenience, which we'd like to hear if there is potential for alternative approaches on.

While the lower layer access mechanism does feel like a extremely useful addition to the platform, but the limited scope would be something we'd like to discuss in depth. If you plan to meet during TPAC, that might be a good time to sit down and discuss this in detail. (We'll make sure someone representing the TAG is also there, hopefully up to date with more background on the work)

<speaking as WEBRTC WG chair> ping Do we expect to have a resolution of the TAG review any time soon? The WEBRTC WG is currently discussing whether to adopt the spec or leave it in the CG - the TAG's input would be valuable here.

Apologies that this is taking so long. We've been waiting on QUIC to stabilize a bit more (based on IETF feedback) so we can think about whether or not QUIC streams is something that is worthwhile exploring as a future powerful feature of the web platform, and if so how to deal with the security issues that follow if we decide to do so. If so, we will be introducing a redundant feature so that would be undesirable.

We would like to have a second pass discussion with our friends at the QUIC/HTTP WG in IETF about this and see if this is worth exploring.

The QUIC APIs have been reworked and are no longer handled by the WEBRTC WG.

The WebTransport API (the client/server API) has been proposed in WICG: https://discourse.wicg.io/t/webtransport-proposal/3508 https://pthatcherg.github.io/web-transport/

The P2P API is now under development in the ORTC CG, as part of the ORTC API: http://draft.ortc.org/ (pre-requisite for understanding the P2P API) https://github.com/w3c/webrtc-quic

That is great news! We will take a look at the links. (and hopefully provide feedback if it is deemed necessary)

Should we then close this and the IceTransport review, since it has since been superseded?

The WebRTC-ICE document is still being handled by the WEBRTC WG, so that review should remain open.

I'll let Peter Thatcher and Seth Hampson respond with respect to what they would like to do with respect to TAG review of the QUIC APIs.

Hi Cynthia, I think it would be valuable to continue with the reviews. The RtcIceTransport review can continue as is. The QUIC APIs have been split into two separate places, but share the same base interface. The QuicTransportBase interface exists with the WebTransport API (https://pthatcherg.github.io/web-transport/) and is extended by both the RtcQuicTransport (P2P version with ICE) and the WebTransport (client/server version w/o ICE).

For the QUIC APIs it would be great to continue the review and look at these base objects as well as the P2P specific APIs that exist in the ORTC repo. I don't think there are any objections to extending the review to include the client/server API (QuicTransport) as well, and we would value this feedback.

Thank you!

@cynthia and I are looking at this in a breakout at the TAG's virtual face-to-face meeting.

In so far as we're able to understand what's going on, and given that further in-depth review by the TAG seems unlikely, I think we're comfortable closing this review. The TAG isn't really the best source of expertise in this area; there's a lot more knowledge of this across a number of other venues such as the IETF QUIC WG and the IAB.

Given that there have been significant changes from the original proposal, we can only extrapolate the impact of the changes in terms of these proposals as general APIs outside of a WebRTC context. An updated explainer that explains the connection between the proposals would have been useful.

That said, we're happy to see that it is at least connected to Web Transport and to RTCIceTransport in what I think are reasonable ways, although it's not especially clear that the naming of the classes expresses those relationships clearly. (For example RTCQuicTransport and RTCIceTransport sound like things that are at the same layer, rather than one being on top of the other.)