Re: [Webtransport] Http3Transport pooling/sharing

[Martin Thomson <[e-mail]>]

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. 
> 
> 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?
> -- 
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>