Subject: [Webtransport] Http3Transport: Connection-basd Functionality

From: Luke Curley <[email-masked]>
Date: Fri, 19 Feb 2021 12:49:28 -0800

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?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Feb 2021 13:32:14 -0800

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 <[email-masked]> wrote:

> <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.
>
> The WebTransport specification specifically mentions MAX_STREAMS, as
> HTTP/3 servers can no longer use this to limit the number of simultaneous
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Luke Curley <[email-masked]>
Date: Fri, 19 Feb 2021 13:56:05 -0800

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 <[email-masked]>
wrote:

> 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.
>
>> Hey everybody, I wanted to start the discussion now that Victor's
>> document has been adopted!
>>
>> I filed some issues
>> 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.
>>

---

From: David Schinazi <[email-masked]>
Date: Fri, 19 Feb 2021 14:27:21 -0800

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 <[email-masked]> wrote:

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

---

From: Luke Curley <[email-masked]>
Date: Fri, 19 Feb 2021 14:59:07 -0800

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.

---

From: David Schinazi <[email-masked]>
Date: Fri, 19 Feb 2021 16:11:42 -0800

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 <[email-masked]> 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
> 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.
>

---

From: Ian Swett <[email-masked]>
Date: Sun, 21 Feb 2021 12:57:11 -0500

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 <[email-masked]>
wrote:

>> 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.
>>
>>> 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
>>>
>>>>> 1. Under what circumstances can WebTransport connections be pooled,
>>>>> and what kinds of pooling are allowed?
>>>>> 2.  What are the differences in API behavior between Http3Transport
>>>>> and quic-transport?
>>>>> 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?