Re: QUIC and WebRTC Comments

On Tue, Jan 9, 2018 at 4:34 PM Martin Thomson <martin.thomson@gmail.com>
wrote:

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

Actually, I think we should be considering media over QUIC as a use case
for the QuicTransport.  Not as the first step, but as a next step after.
There was significant interest in doing so at TPAC, and I think we can add
support for it without adding much API surface (as I proposed at TPAC).

We perhaps won't standardize it in the IETF for quite some time, but anyone
can go and build a viable alternative r*ight now *with QUIC*.  *The
question is whether the can do so in a web application.  The answer is
currently no, but if we added all of what was proposed at TPAC
(IceTransport + QuicTransport + Encoder/Decoders/JitterBuffers), then I
believe a web application could do so.

However, I recognize that these sort of things need to be done
incrementally, which is why I think we should to the IceTransport +
QuicTransport first.  We can then focus on sending media over a
QuicTransport later.


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

I think it's less about being ambitious and more about doing the simplest,
easiest thing that provides the JS app with the most power and flexibility.


>
> 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).
>

So let me understand what you're saying: if *later* we define a mapping of
RTP to QUIC and want to put *that* in the browser, a JS app would not be
able to use both *that new thing* and some separate QUIC streams over the
same 5-tuple without using QUIC connection IDs on the wire.

Is that correct?

If so, you're correct.  But that's a general problem with QUIC that would
need to be fixed.  And whatever solution that arises for QUIC (I like the
"stream group" idea) could equally be used by the JS application because
whatever mechanism QUIC comes up with for having separate concurrently
protocols with the same connection ID we can expose and use in the API.

Or, we can just use separate QUIC connection IDs, which doesn't seem that
bad.  But clearly it would be better if QUIC added something like stream
groups.


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

For now, I think we should just stick to QUIC w/ ICE.  But you're right
that there are probably use cases that would benefit from being ICE-free
and should then take those into consideration.


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


The API we have come up with is completely compatible with the WHATWG
streams.  I have written some example code that implements WHATWG streams
on top of the QUIC streams we proposed, so we're not losing anything here.
I can share the example code if you'd like.


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


Supporting both would be fairly minor change to what we've come with so far
in the API.  The only reason we didn't add it so far is that unidirectional
streams didn't exist when we wrote what we have so far.


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

What do you mean by "negotiate"?  You mean let the JS set the value that
goes in the client hello?  Or something else?


>
> 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).
>

0-RTT support would be a nice addition.   I don't know enough about it know
what to put in the API for it.  Perhaps after we land the basics you can
make a PR :).

As for client/server, in ORTC we added a role, just like for DTLS.  Perhaps
we haven't copied that over to the WebRTC repo yet.   But that's something
we intend to let the JS specify.



>
> The API does nothing meaningful for peer authentication, using
> certificate fingerprints only.  If only we had something better...
>

What do you have in mind?


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

Again, I don't know enough yet to know what makes sense here, but after we
land the basics, I hope we can make PRs for this sort of thing.


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

Yes, it's useful feedback.  Thank you.  And, yes, there is plenty of work
to do, which is why I'm glad we're starting now and have lots of people
interested in it.  What we have so far is just trying to get the foundation
right so we can add the things you brought up (0-RTT, unidirectional
streams, separate protocols over the same connection ID (whenever QUIC has
a solution for that)).