Re: QUIC and WebRTC Comments

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?

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.

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

More importantly, I would contend that an API designed for future use
doesn't need anything other than streams.

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

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

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

Received on Wednesday, 10 January 2018 06:22:34 UTC