Subject: [Webtransport] Http3Transport pooling/sharing

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Nov 2020 10:32:38 -0800

One of the use cases that has been described in the recent W3C WebTransport
WG meeting was sharing of an HTTP/3 QUIC connection between HTTP/3
Request/Response and WebTransport.

In looking into how this would work in practice, it appears that there are
some complications.

Http3Transport requires support for HTTP/3 Datagrams.
draft-vvv-webtransport-http3
Section 4.1 says:

"If "http3_transport_support" is negotiated, support for the QUIC DATAGRAM
extension MUST be negotiated."
What happens if there is an existing HTTP/3 connection to the same Origin
but that connection did not negotiate support for QUIC DATAGRAMS?

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 10 Nov 2020 14:18:29 +1100

There is a common problem with piecemeal negotiation.  I can imagine several responses to the case where you have an existing connection that doesn't support the features you want.

1. Fail.
2. Make a new connection.
3. Synthesize datagram support (probably not worth it).

Failing isn't completely unreasonable.  If the connection doesn't have the features you need, and you have no reason to believe that the negotiation would be different next time, then this is a good reaction.  Of course, you need to be offering datagram support when you make the original connection, even if you are not currently aware of the need for the feature.

The quote you provide indicates doesn't seem at all problematic: both features are negotiated at the same time, and one requires the other.  This is not particularly difficult to arrange.

There is a more difficult problem to address: what if you have a connection to a server that supports h2 and webtransport, but you get Alt-Svc indicating support for h3.  Do you upgrade?  What if the upgraded service doesn't support webtransport?  If, at the time you upgrade, you don't know, it seems reasonable to upgrade.  But then if you later learn that you need webtransport, what then?

On Tue, Nov 10, 2020, at 05:32, Bernard Aboba wrote:
> One of the use cases that has been described in the recent W3C 
> WebTransport WG meeting was sharing of an HTTP/3 QUIC connection 
> between HTTP/3 Request/Response and WebTransport. 
> 
> In looking into how this would work in practice, it appears that there 
> are some complications. 
> 
> draft-vvv-webtransport-http3 Section 4.1 says:
> "If "http3_transport_support" is negotiated, support for the QUIC 
> DATAGRAM extension MUST be negotiated."
> 
> What happens if there is an existing HTTP/3 connection to the same 
> Origin but that connection did not negotiate support for QUIC DATAGRAMS?
> -- 
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 10 Nov 2020 03:44:19 +0000

On Tue, 10 Nov 2020, 03:18 Martin Thomson, <[email-masked]> wrote:

> There is a common problem with piecemeal negotiation.  I can imagine
> several responses to the case where you have an existing connection that
> doesn't support the features you want.
>
> 1. Fail.
> Failing isn't completely unreasonable.  If the connection doesn't have the
> features you need, and you have no reason to believe that the negotiation
> would be different next time, then this is a good reaction.  Of course, you
> need to be offering datagram support when you make the original connection,
> even if you are not currently aware of the need for the feature.
>
> The quote you provide indicates doesn't seem at all problematic: both
> features are negotiated at the same time, and one requires the other.  This
> is not particularly difficult to arrange.
>
> There is a more difficult problem to address: what if you have a
> connection to a server that supports h2 and webtransport, but you get
> Alt-Svc indicating support for h3.  Do you upgrade?  What if the upgraded
> service doesn't support webtransport?  If, at the time you upgrade, you
> don't know, it seems reasonable to upgrade.  But then if you later learn
> that you need webtransport, what then?
>

+1, especially that last part.

Things gets thorny with support of extensions across HTTP versions. I
started on draft-pardue-alt-svc-ext-unsupported [1] to explain some of
this, with the mere solution of coining an error code. I didn't have a
strong problem case for it to apply to yet so it's been sat idle...

Cheers,
Lucas

https://datatracker.ietf.org/doc/draft-pardue-alt-svc-ext-unsupported/

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Nov 2020 08:51:42 -0800

Martin said:

"But then if you later learn that you need webtransport, what then?"

[BA] Exactly.

It doesn't seem right to me to require support for WebTransport (and
associated functionality such as datagrams) on a connection that initially
is only to be used for HTTP/3.  It is also cumbersome to require that APIs
be used in a certain order (e.g. always call the WebTransport constructor
before fetch if you want to share the same connection).

---

From: Luke Curley <[email-masked]>
Date: Tue, 10 Nov 2020 15:33:13 -0800

Do all WebTransports need to have the same functionality? Would it make
sense to have optional functionality? I see a problem trying to force all
of the transports to behave the same in general.

While it's possible to emulate datagrams over reliable streams, this
subtly causes different behavior depending on the transport.
Applications built on top of QuicTransport datagrams will assume UDP-like
functionality. These assumptions are broken when using Http2Transport and
potentially broken when using Http3Transport, depending on extension
support.

On Tue, Nov 10, 2020 at 8:51 AM Bernard Aboba <[email-masked]>
wrote:

>> Failing isn't completely unreasonable.  If the connection doesn't have
>> the features you need, and you have no reason to believe that the
>> negotiation would be different next time, then this is a good reaction.  Of
>> course, you need to be offering datagram support when you make the original
>> connection, even if you are not currently aware of the need for the feature.
>>