QUIC and WebRTC Comments

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