Re: [Webtransport] Http3Transport: Connection-basd Functionality

[David Schinazi <[e-mail]>]

Thanks!

WebTransport is intentionally designed to be limited because we don't want
to expose too much to JavaScript.
Similarly, when JavaScript is using WebSocket, we don't let it access TLS
extensions or TCP flow control information, as doing that could cause
security issues.

To your MAX_STREAMS/MAX_DATA example, I think there's value in having
WebTransport-specific flow control, but I don't think that should rely on
the underlying transport and connection, we can easily build that inside
WebTransport itself.
In other words, if there are QUIC-connection-level features that we think
might benefit WebTransport applications, we should analyze their security
implications and add those specifically to WebTransport instead of giving
JavaScript blanket control over connection properties.

David

On Fri, Feb 19, 2021 at 2:59 PM Luke Curley <[e-mail]> wrote:

> Good examples, because HTTP/3 is currently the only QUIC application and
> it doesn't utilize both of those. But QUIC doesn't prohibit an
> application/protocol from utilizing the connection ID or TLS extensions. It
> could be useful for some future purpose, like the client using a
> pre-arranged connection ID (encoded with routing info?) or new TLS
> extensions/parameters (remove a round trip for a handshake?).
>
> WebTransport does prohibit using these connection-level functionalities
> for the sake of pooling. None of this is critical functionality, but it
> might hamper future efforts which is why I wanted to bring up the one-way
> door.
>
> It's on my mind because I'm designing a video protocol over QUIC. It would
> be nice if I could use MAX_STREAMS, MAX_DATA, etc, but as it stands now,
> I'll need to implement my own flow control mechanisms for WebTransport
> (browser) support.
>
> On Fri, Feb 19, 2021 at 2:27 PM David Schinazi <[e-mail]>
> wrote:
>
>> Hi Luke,
>>
>> Can you elaborate on what benefits you see in exposing
>> QUIC-connection-level information to a WebTransport application?
>> In particular, which information would benefit WebTransport applications?
>> Because for example I don't see how knowing the connection ID or transport
>> parameters would be useful, but I could just be missing something.
>>
>> David
>>
>> On Fri, Feb 19, 2021 at 1:56 PM Luke Curley <[e-mail]> wrote:
>>
>>> Oh man I just noticed the typo in the email subject... that's
>>> embarrassing.
>>>
>>> I mentioned this earlier, but I think pooling is a potential future
>>> optimization. The benefit is that pooling can avoid additional TLS
>>> handshakes iff a client has multiple WebTransport or HTTP/3 connections to
>>> the same host (rare?). The cost of pooling is that connection-level QUIC
>>> functionality is no longer available, and must be avoided or worked around.
>>>
>>> I liked how QuicTransport was connection oriented and I think something
>>> similar could be done for Http3Transport without precluding pooling support
>>> in the future.
>>>
>>> On Fri, Feb 19, 2021 at 1:32 PM Bernard Aboba <[e-mail]>
>>> wrote:
>>>
>>>> Luke --
>>>>
>>>> Thanks for bringing this up!
>>>>
>>>> At the Interim meeting, we talked about having the API provide some
>>>> control over pooling (e.g. allowing an appiication to specify that a
>>>> WebTransport connection not be pooled), as well as allowing a server to
>>>> specify that it doesn't support pooling.
>>>>
>>>> In W3C WebTransport WG we are now in the process of developing PRs to
>>>> deal with pooling, and are running into some of the same questions, such
>>>> as:
>>>>
>>>> 1. Under what circumstances can WebTransport connections be pooled, and
>>>> what kinds of pooling are allowed?
>>>> PR: https://github.com/whatwg/fetch/pull/1171
>>>>
>>>> 2.  What are the differences in API behavior between Http3Transport and
>>>> quic-transport?
>>>> PR: https://github.com/w3c/webtransport/pull/205
>>>>
>>>> 3.  For Http3Transport, are there differences in API behavior between
>>>> non-sharable connections and sharable ones (e.g. behavior of
>>>> webtransport.close())?
>>>> Also coming up in PR: https://github.com/w3c/webtransport/pull/205
>>>>
>>>> 4. For a non-sharable WebTransport connection, is it possible to obtain
>>>> some of the stats that were supported for quic-transport, but would not be
>>>> appropriate for a sharable transport?
>>>> Issue: https://github.com/w3c/webtransport/issues/206
>>>>
>>>>
>>>>
>>>> On Fri, Feb 19, 2021 at 12:49 PM Luke Curley <[e-mail]>
>>>> wrote:
>>>>
>>>>> Hey everybody, I wanted to start the discussion now that Victor's
>>>>> document has been adopted!
>>>>>
>>>>> I filed some issues
>>>>> <https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-http3> earlier
>>>>> on Github over a few small things. Overall, the draft is clean and it's
>>>>> nice that we've converged on a single WebTransport protocol. One bigger
>>>>> topic I wanted to discuss is the ramifications of connection pooling.
>>>>>
>>>>> Broadly speaking, any QUIC parameters or frames that operate on the
>>>>> connection as a whole can no longer be exposed to the application.
>>>>> Specifically: MAX_DATA, MAX_STREAMS, CONNECTION_CLOSE*, connection ID, and
>>>>> any transport parameters.
>>>>>
>>>>> The WebTransport specification specifically mentions MAX_STREAMS, as
>>>>> HTTP/3 servers can no longer use this to limit the number of simultaneous
>>>>> requests. Returning an error code instead of utilizing the built-in flow
>>>>> control is not a problem, but it's not ideal either.
>>>>>
>>>>> I believe this is a one-way door in general. Any protocols or
>>>>> applications built on top of QUIC will no longer be able to use
>>>>> connection-based QUIC features without breaking WebTransport compatibility.
>>>>> This primarily means HTTP/3, but it also includes any new protocols that
>>>>> utilize QUIC and desire browser support.
>>>>>
>>>>> What does the group think? Is this something worth caring about?
>>>>> --
>>>>> Webtransport mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>>
>>>> --
>>> Webtransport mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>
>>