Re: [Webtransport] Http3Transport: Connection-basd Functionality

[Luke Curley <[e-mail]>]

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