Re: QUIC and WebRTC Comments

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

> On Wed, Jan 10, 2018 at 4:52 PM, Peter Thatcher <pthatcher@google.com>
> wrote:
> > 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).
>
> Sounds a bit like science fiction right now, but that's partly why we
> do this, right?
>

If we want the science fiction to come to life, we have to start at some
point.  I think now is a good time :).


>
> As a reminder, there are good reasons for the browser to at least
> retain the ability to generate media that is not accessible to the
> site.
>

> > 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.
>
> For some definition of "easiest".  I'm trying to point out that this
> might not in fact be the easiest overall.  Something more narrowly
> targeted might avoid closing out different avenues of investigation.
>

> > 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?
>
> Yeah.  And even if they aren't on the same 5-tuple, you have things
> that you might want to do.
>
> > 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.
>
> Now you are actually talking about defining a protocol.
>

Not exactly.  I'm talking about the possibility of using a feature of QUIC
that isn't defined yet, but that I hope will be.  If it is, great.  If not,
oh well.


>
> > 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.
>
> I wouldn't rule out QUIC without ICE, but the server consent issues
> are a minefield.
>

> >> 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.
>
> Maybe I should take some time to explain how the buffering design of
> the API can produce a deadlock.  Or you could read the quic@ietf.org
> mail that explains it.
>
>
I'll try and take some time to take a look.


> More importantly, I would contend that an API designed for future use
> doesn't need anything other than streams.
>
>
If I can build the API we have so far on top of WHATWG streams (which I'm
not entirely sure we can do) and I can build the WHATWG streams on top of
the API we have so far (which I'm sure we can do) , I'll take the API we
have so far.    I think the closer to QUIC that it is, the better.  Let the
JS build up abstractions from there.


> >> 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?
>
> Yes, and to select what to use on the server.  All the pieces you
> usually associate with that.
>
> Not using ALPN might be OK for some uses of the API, but it's
> necessary for some of the more advanced use cases (HTTP, for instance,
> or this protocol that does stream grouping you mention).
>

OK, sounds like a good thing to add to the API (to choose the ALPN value).


>
> > 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.
>
> Exposing the role isn't sufficient.  You have to provide some way to
> influence role selection because only a client can use 0-RTT.
>

That's what I'm saying: the JS gets to choose the role (client or server).
Not just know what it was.


>
> >> The API does nothing meaningful for peer authentication, using
> >> certificate fingerprints only.  If only we had something better...
> >
> >
> > What do you have in mind?
>
> We have this thing that allows you to authenticate a peer.  You might
> have heard of it.  It sounds like you also have aspirations of
> connecting to servers with real names.  We have something for that
> too.
>
> > 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)).
>
> There isn't a plan to build separate protocols that share a
> connection.  That's a protocol that someone would have to design.
>

I hope the QUIC WG comes up with something built into QUIC.   If so, we can
expose it in the API for the JS to use.

If not and someone comes up with something on top of QUIC, then that thing
can be implemented in JS.