Re: [Webtransport] Http3Transport pooling/sharing

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).

On Mon, Nov 9, 2020 at 7:18 PM Martin Thomson <mt@lowentropy.net> 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.
> 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
> > Webtransport@ietf.org
> > https://www.ietf.org/mailman/listinfo/webtransport
> >
>
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>