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

Filling in relative information from @martinthomson's [post](https://github.com/w3ctag/design-reviews/issues/296#issuecomment-418572658) 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.

-- 
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-419521358