Re: [Webtransport] Http3Transport: Connection-basd Functionality

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 <kixelated@gmail.com> 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
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>