- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 10 Jan 2018 11:32:20 +1100
- To: public-webrtc@w3.org
It took me a little while to grok what this group was aiming to do with QUIC as defined in <https://w3c.github.io/webrtc-quic/>. That's because there are many things that you could do with QUIC. The uses that were obvious initially were: * a replacement for data channels * a replacement for RTP There are some potential advantages and several drawbacks to the data channels thing. Randell has already explained the shortcomings and addressed several misapprehensions on this front, so I won't go into more detail on that. Replacing RTP is self-evidently a massive project that is unlikely to be viable in the short term, so that's clearly not ready for consideration. What I didn't expect was that this was an attempt to bring the unadorned QUIC transport stack to browsers. And that's more ambitious than I think that this group realizes. Also, doing so has some pretty serious consequences that I don't see much evidence of having been considered. By making QUIC directly accessible, you enable a fairly comprehensive set of use cases. But you also risk foreclosing on others. Critically, you risk making it considerably more difficult to concurrently deploy QUIC for data channels or RTP. An API for direct use of QUIC means that browsers no longer control access to the protocol. If you wanted to use this direct API at the same time as one of the browser-native uses of QUIC like data channels, then your only option is to have two (or more) QUIC connections. That introduces new complications around shared congestion control (if the connections use the same path, but how can you be sure about that even if the endpoints are the same?) and maybe even multiplexing (it's possible to have two QUIC connections share a 5-tuple, but then you need to have connection IDs, which ruins the work we did to make QUIC multiplex cleanly with STUN). There might be protocol work here, though it's definitely less than I originally thought. You probably need some consideration of QUIC's address validation and connection migration features, since those duplicate features that ICE provides. Regarding the API in its current form: Lennart beat me to this by raising an issue, but this is critical. QUIC is a natural fit for the streams API, and not by accident. It's hard to see why the current API defines its own methods. What is worse, we recently discovered the potential for a deadlock that the current API would be vulnerable to. A QUIC API needs both support for both unidirectional and bidirectional streams. Similarly, stream states need updating to match the specification (not all states need to be reflected, but the current state doesn't match the protocol at all). A QUIC API needs a way to negotiate ALPN. No consideration is given to 0-RTT. It's possible that without any notion of the identity of a peer, this is a feature that the working group decides isn't worth investing effort in. It is a headline feature of QUIC though. If the group is interested, I can provide a simple suggestion that would enable it; we're in the process of landing a C API for that in NSS right now. Note that in order to provide 0-RTT, you need to expose the concept of server and client, which isn't currently visible (which makes me wonder how you manage to avoid setup glare). The API does nothing meaningful for peer authentication, using certificate fingerprints only. If only we had something better... I very much like that the API does not expose stream identifiers. Please keep that. That said, it's probably a good idea to make them accessible on debug consoles and the like for troubleshooting purposes. There is no consideration given to the potential division of responsibilities between browser and application regarding certain of the key transport controls. Here I speak of flow control, stream limits, and other transport parameters. It's possible that the browser should handle these, but there are definitely reasons that the application should at least have some control over stream limits. Obviously, it's early yet and there's a lot more to do. I hope that this is useful feedback. I likely won't make the call later this week.
Received on Wednesday, 10 January 2018 00:32:48 UTC