Re: [Webtransport] Confirming Consensus on WebTransport protocols

[Bernard Aboba <[e-mail]>]

Martin said:

"I don't think that this group gets to say that.  If we are using HTTP,
then we are using HTTP.  We might decide that in browsers we want to keep
the connections separate for $reasons, but I am opposed to saying that.

Unless of course I'm missing context in the same way I missed the meeting."

[BA] The pooling discussion surfaced both API and protocol concerns, and
it  probably would be wise to separate them, because they are the
responsibilities of different groups.

For example, the W3C WebTransport WG may consider API issues with respect
to WebTransport pooling/ There is in fact an open issue (128
<https://github.com/w3c/webtransport/issues/128>) on this, which the WG
considered sufficiently well understood to label "Ready for PR".  I do
think it is possible to develop a PR for that Issue as well as some of the
API concerns raised at the meeting, addressing issues relating to pooling
of WebTransport connections with each other.

That said, the IETF WEBTRANS WG does get to opine on the protocol aspects
of pooling, and a number of concerns have been raised in that area,
particularly with respect to allowing interleaving of  HTTP/3
Request/Responses and WebTransport on the same QUIC connection.  This does
appear complex enough to not be considered "ready for PR" at either the API
or protocol levels. For example:

1. WebTransport requires negotiation of transport parameters (e.g. support
for HTTP/3 datagrams) that would normally not be required for a QUIC
connection used for HTTP/3 Request/Response.  So even if you were to have a
QUIC connection originally negotiated for use with HTTP/3, it would not be
immediateliy suitable for use with WebTransport.

2. Even if you did find a QUIC connection with the appropriate transport
parameters, interleaving HTTP/3 Request/Responses with WebTransport
streams will raise questions about how the protocols work with each other
(e.g. how stream IDs are allocated, as well as flow control,
prioritization, etc.).

Personally, I don't believe that either of these Issues are unsolvable, but
since pooling is an optimization, an argument can be made that the WG
should intiailly focus on more basic concerns.

On Tue, Jan 12, 2021 at 4:02 PM Martin Thomson <[e-mail]> wrote:

> On Wed, Jan 13, 2021, at 04:25, David Schinazi wrote:
> > The consensus was option 1A.
>
> Great!
>
> > The consensus was option 2A.
>
> I can live with that.  Can I request a brief summary of the reasons?
>
> > Additionally, we discussed pooling and decided that we would
> > not allow pooling in WebTransport over HTTP/3 for now, due
> > to the complexities of pooling.
>
> I don't think that this group gets to say that.  If we are using HTTP,
> then we are using HTTP.  We might decide that in browsers we want to keep
> the connections separate for $reasons, but I am opposed to saying that.
>
> Unless of course I'm missing context in the same way I missed the meeting.
>
> --
> Webtransport mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webtransport
>