Re: [Webtransport] Http3Transport: Connection-basd Functionality

[David Schinazi <[e-mail]>]

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
>