Re: [Webtransport] Http3Transport: Connection-basd Functionality

[Luke Curley <[e-mail]>]

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