Re: [Webtransport] Http3Transport: Connection-basd Functionality

[Ian Swett <[e-mail]>]

The MAX_STREAMS/MAX_DATA example does seem like a tricky point I hadn't
fully appreciated earlier.

In H3, we took the attitude that using those transport connection level
features was the right thing to do, which I think makes sense because
HTTP/2 had too much transport(non-HTTP) functionality in it.

But if we allow pooling of H3 with WebTransport or other applications which
need to use MAX_STREAMS/MAX_DATA, then each other application needs to add
transport-style mechanisms and the H3 implementation probably needs to be
aware that MAX_STREAMS needs to be adjusted by the other applications
MAX_STREAMS in order to have the intended effect.

I think I'm leaning towards one of two options: We don't care about
isolating the pooled H3 session from the WebTransport session when pooling
occurs, or we need to spend more time thinking about this
'session-layer'(to use Roberto's phrasing) problem in general now or we're
going to create some problems down the road.

Ian



On Fri, Feb 19, 2021 at 7:12 PM David Schinazi <[e-mail]>
wrote:

> 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
>>>>
>>> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>