Subject: [Webtransport] Confirming Consensus on WebTransport protocols

From: David Schinazi <[email-masked]>
Date: Tue, 12 Jan 2021 09:25:49 -0800

Hi WebTransport enthusiasts,

Today we had an interim of the IETF WEBTRANS WG,
where we reached consensus in the (virtual) room on
the following questions:

Question 1: number of protocols
    Should the working group adopt only one UDP-based transport?
    1A: only one transport (QUIC or HTTP/3)
    1B: multiple transports (QUIC and HTTP/3)

The consensus was option 1A.

Additionally, we noted that this does not preclude us from
building a second protocol at a later date if new information
emerges.

Question 2: UDP-based protocols
    Which UDP-based option should we adopt as a starting
    point for WebTransport protocol?
    2A: WebTransport over HTTP/3
    2B: WebTransport over QUIC directly (separate ALPN)

The consensus was option 2A.

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.

We'd like to confirm this consensus on the list. If you disagree
with these points, please reply on the list. If you do so, please
state how strongly you feel - whether you are expressing a
preference, or an imperative. Please also provide as much
detail as possible to explain your position. Please also respond
if you support this consensus - a simple "I support this consensus"
email to the list would be helpful.

We'll be running this consensus call for two weeks, please reply
before 2021-01-26, the chairs will determine consensus on that date.

Thanks,
David

---

From: Ian Swett <[email-masked]>
Date: Tue, 12 Jan 2021 12:32:05 -0500

I support this consensus.

I do have concerns about the complexity of different types of pooling, but
I'm sure we'll discuss those in the future.

On Tue, Jan 12, 2021 at 12:26 PM David Schinazi <[email-masked]>
wrote:

> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jan 2021 09:35:33 -0800

I also support the consensus, with concerns about pooling (particularly
pooling of HTTP/3 and H3Transport).

---

From: Alan Frindell <[email-masked]>
Date: Tue, 12 Jan 2021 18:10:22 +0000

I support the consensus on Question 1 and Question2.

I think this statement is worded too strongly.  We discussed pooling and made it clear that choosing H3 does not mandate that we will support pooling. My understanding is that it will continue to be discussed in the working group.

-Alan

From: Webtransport <[email-masked]> on behalf of David Schinazi <[email-masked]>
Date: Tuesday, January 12, 2021 at 9:26 AM
To: WebTransport <[email-masked]>
Subject: [Webtransport] Confirming Consensus on WebTransport protocols

Thanks,
David

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 12 Jan 2021 10:14:57 -0800

To Alan’s point, I’d expect that we’ll continue to discuss pooling, but that we’re not committing to delivering something that supports pooling without further identifying the complexities involved and designing something which sufficiently resolves those concerns. (As would be reasonable for any protocol feature.)

Thanks,
Eric

> On Jan 12, 2021, at 10:10 AM, Alan Frindell <afrind=[email-masked]> wrote:
>

---

From: Luke Curley <[email-masked]>
Date: Tue, 12 Jan 2021 10:28:55 -0800

Yeah, I want to reaffirm that my vote for HTTP/3 was tied to the removal of
pooling. The current Http3Transport draft is more complex than it needs to
be in order to support pooling, which is a fringe optimization at best.

On Tue, Jan 12, 2021 at 10:15 AM Eric Kinnear <ekinnear=
[email-masked]> wrote:

> To Alan’s point, I’d expect that we’ll continue to discuss pooling, but
> that we’re not committing to delivering something that supports pooling
> without further identifying the complexities involved and designing
> something which sufficiently resolves those concerns. (As would be
> reasonable for any protocol feature.)
>
> Thanks,
> Eric
>
>
> I think this statement is worded too strongly.  We discussed pooling and
> made it clear that choosing H3 does not mandate that we will support
> pooling. My understanding is that it will continue to be discussed in the
> working group.
>
> -Alan
>
> *From: *Webtransport <[email-masked]> on behalf of David
> Schinazi <[email-masked]>
> *Date: *Tuesday, January 12, 2021 at 9:26 AM
> *To: *WebTransport <[email-masked]>
> *Subject: *[Webtransport] Confirming Consensus on WebTransport protocols
>

---

From: "Morten V. Pedersen" <[email-masked]>
Date: Tue, 12 Jan 2021 21:40:27 +0100

I'm sorry for being uninformed here. But does this preclude unreliable 
datagram support from an application point of view. I.e. will users of 
Webtransport be able to send unreliable datagrams when using 
Webtransport over HTTP/3?

All the best,
Morten

On 12/01/2021 19.28, Luke Curley wrote:
> Yeah, I want to reaffirm that my vote for HTTP/3 was tied to the 
> removal of pooling. The current Http3Transport draft is more complex 
> than it needs to be in order to support pooling, which is a fringe 
> optimization at best.
>
> On Tue, Jan 12, 2021 at 10:15 AM Eric Kinnear 
> <ekinnear=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     To Alan’s point, I’d expect that we’ll continue to discuss
>     pooling, but that we’re not committing to delivering something
>     that supports pooling without further identifying the complexities
>     involved and designing something which sufficiently resolves those
>     concerns. (As would be reasonable for any protocol feature.)
>
>     Thanks,
>     Eric
>
>
>>     On Jan 12, 2021, at 10:10 AM, Alan Frindell
>>     <afrind=[email-masked]
>>     <mailto:afrind=[email-masked]>> wrote:
>>
>>     I think this statement is worded too strongly.  We discussed
>>     pooling and made it clear that choosing H3 does not mandate that
>>     we will support pooling. My understanding is that it will
>>     continue to be discussed in the working group.
>>     -Alan
>>     *From:*Webtransport <[email-masked]
>>     <mailto:[email-masked]>> on behalf of David
>>     Schinazi <[email-masked] <mailto:[email-masked]>>
>>     *Date:*Tuesday, January 12, 2021 at 9:26 AM
>>     *To:*WebTransport <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Subject:*[Webtransport] Confirming Consensus on WebTransport
>>     protocols
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/webtransport>
>
>     -- 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/webtransport>
>
>

---

From: David Schinazi <[email-masked]>
Date: Tue, 12 Jan 2021 12:58:54 -0800

Hi Morten, Yes WebTransport over HTTP/3 supports unreliable datagrams.

David

On Tue, Jan 12, 2021 at 12:40 PM Morten V. Pedersen <[email-masked]>
wrote:

> Webtransport be able to send unreliable datagrams when using Webtransport
> over HTTP/3?
>
> All the best,
> Morten
> Yeah, I want to reaffirm that my vote for HTTP/3 was tied to the removal
> of pooling. The current Http3Transport draft is more complex than it needs
> to be in order to support pooling, which is a fringe optimization at best.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Jan 2021 11:02:05 +1100

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Jan 2021 21:57:05 -0800

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

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

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Jan 2021 21:23:34 +1100

On Wed, Jan 13, 2021, at 16:57, Bernard Aboba wrote:
> 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.

I am was suggesting something different.  This working group should not express an opinion on these matters.  If implementations are willing to engage with these problems, they should be free to do so without some RFC (or Internet-Draft) saying that they should not.  

If we identify constraints based on the web security model, that might be cause for a browser not to attempt pooling.  Web security is sufficiently intricate that that is a distinct possibility.  However, that would be something the W3C working group deals with (I think that's the division of responsibilities here; though that is unclear).  Either way, that should not have a significant effect on the protocol definition, which should not care about this.

In any case, I'm not aware of any reasons that would actively prevent pooling other than those you list, which just amount to "there are some tricky bits".  But that mostly relates to performance and prioritization. The first issue you mention can't be a problem, because a server has to offer all of the webtransport capabilities at the start because it can't know if this is plain HTTP or webtransport at that point.  So I'm left with "prioritization is hard", which isn't exactly news.  Is there anything else?

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jan 2021 07:31:50 -0800

> I am was suggesting something different.  This working group should not express an opinion on these matters.  If implementations are willing to engage with these problems, they should be free to do…

[BA] I don’t recall a suggestion to prohibit pooling outright. We discussed API changes to allow an application to request that a WebTransport not be pooled, as well as a server indication to say “I do not support pooling”.  Both of these seem achievable.

> If we identify constraints based on the web security model, that might be cause for a browser not to attempt pooling.  

[BA] That is the crux of Issue 128. Investigating the constraints seems useful.

---

From: Ian Swett <[email-masked]>
Date: Wed, 13 Jan 2021 10:44:28 -0500

> I can live with that.  Can I request a brief summary of the reasons?

I asked a question like this during the interim, and I think it'd be worth
clearly documenting the reasons, as I think it'd clarify our direction a
bit.  The one that I clearly recall is that we'd have to re-invent many of
the features that HTTP/3 provides, but I'm not clear why that's the case.

> the connections separate for $reasons, but I am opposed to saying that.

I suspect you're right.

I'd like to call out that there are two things which could be referred to
as 'pooling'.  One is using a single connection for HTTP/3 and WebTransport
at the same time.  The other is support for multiple WebTransport sessions
inside a single connection.  This latter type of 'pooling' is part of what
makes Http3Transport more complex than QuicTransport.  Was there ever an
explicit question about whether multiple sessions on a single connection
are necessary or even useful?  In retrospect, we were picking between two
transports as well as two different feature sets and it might be worth
splitting them apart.

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 13 Jan 2021 16:44:49 +0000

Hi Ian,

> the features that HTTP/3 provides, but I'm not clear why that's the case.

I made a comment along those lines. It was mainly motivated by Victor's PR
"Refactor client indication into a full header exchange" see
https://github.com/vasilvv/webtransport/pull/18. AFAICT this is merged into
the editors copy of draft-vvv-webtransport-quic but there is no published
I-D with this change in. Victor please correct me if I'm wrong.

Not that I'm not questioning whether the motivation behind needing more
flexibility of the client indication. But it highlights that we'll discover
more things that are needed or nice to have and require additions. My
concern is that inventing something that is similar to HTTP headers but not
actually HTTP is duplication and brings risks that we need to mirror the
engineering and design effort that has already gone into HTTP. As an
implementer, it seems better to reuse HTTP semantics (i.e code I have
already, or libraries) than to invent another HTTP-alike.

Cheers,

Lucas

---

From: Alan Frindell <[email-masked]>
Date: Wed, 13 Jan 2021 17:16:25 +0000

> I'd like to call out that there are two things which could be referred to as 'pooling'.  One is using a single connection for HTTP/3 and WebTransport at the same time.  The other is support for multiple WebTransport sessions inside a single connection.

Absolutely.  QuicTransport prevents even the possibility of pooling HTTP and WebTransport on the same connection, as is done with H2 and WebSockets.

> This latter type of 'pooling' is part of what makes Http3Transport more complex than QuicTransport.  Was there ever an explicit question about whether multiple sessions on a single connection are necessary or even useful?

We have use cases for pooling multiple sessions on the same connection which I described during IETF 109.  I don’t want to completely hijack this thread to discuss them, however.  I’d prefer to wait until we finish confirming consensus on questions 1 and 2 before diving deep into pooling.

-Alan

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 13 Jan 2021 11:24:33 -0800

I support the consensus of 1A and 2A.

On Wed, Jan 13, 2021 at 9:16 AM Alan Frindell <afrind=
[email-masked]> wrote:

> > I'd like to call out that there are two things which could be referred
> to as 'pooling'.  One is using a single connection for HTTP/3 and
> WebTransport at the same time.  The other is support for multiple
> WebTransport sessions inside a single connection.
>
>
>
> Absolutely.  QuicTransport prevents even the possibility of pooling HTTP
> and WebTransport on the same connection, as is done with H2 and WebSockets.
>
>
>
> > This latter type of 'pooling' is part of what makes Http3Transport more
> complex than QuicTransport.  Was there ever an explicit question about
> whether multiple sessions on a single connection are necessary or even
> useful?
>
>
>
> We have use cases for pooling multiple sessions on the same connection
> which I described during IETF 109.  I don’t want to completely hijack this
> thread to discuss them, however.  I’d prefer to wait until we finish
> confirming consensus on questions 1 and 2 before diving deep into pooling.
>
>
>
> -Alan
> --

---

From: Victor Vasiliev <[email-masked]>
Date: Thu, 14 Jan 2021 04:01:54 -0500

>From my perspective, it's mostly because QuicTransport has been just an
incremental reinvention of HTTP from scratch.

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

HTTP pooling is an optimization, so I don't believe it is ever actively
required.

Most of the objections to using HTTP as a transport come from a perceived
requirement to support pooling.  Even outside of design complexity related
to flow control and prioritization, there are cases where web developers
actively benefit from not using pooling (using connection-level stats or
congestion control state for things like ABR).  I believe that it should be
possible to enable/disable pooling WebTransport as a part of settings
negotiation, and I am currently trying to figure out the details of how to
do that.

---

From: Yutaka Hirano <[email-masked]>
Date: Thu, 14 Jan 2021 18:15:42 +0900

I support the consensus.

---

From: Ian Swett <[email-masked]>
Date: Thu, 14 Jan 2021 10:34:37 -0500

On Wed, Jan 13, 2021 at 11:45 AM Lucas Pardue <[email-masked]>
wrote:

>> I asked a question like this during the interim, and I think it'd be
>> worth clearly documenting the reasons, as I think it'd clarify our
>> direction a bit.  The one that I clearly recall is that we'd have to
>> re-invent many of the features that HTTP/3 provides, but I'm not clear why
>> that's the case.
>>
>
> https://github.com/vasilvv/webtransport/pull/18. AFAICT this is merged
> into the editors copy of draft-vvv-webtransport-quic but there is no
> published I-D with this change in. Victor please correct me if I'm wrong.
>

Thanks, I hadn't seen that PR.

After re-reading the editors copy of both documents, I'm much happier with
Http3Transport than I was yesterday, because I had some misunderstandings.
It also makes me very happy we allow Type-Value frames with no length in
HTTP/3.

---

From: David Schinazi <[email-masked]>
Date: Wed, 27 Jan 2021 16:16:49 -0800

This consensus is now confirmed: for the foreseeable future,
the WEBTRANS working group will focus on building a single
UDP-based protocol for WebTransport, and that protocol will
run atop HTTP/3.

Our next step is to adopt a document that matches this
description. The only matching proposal that has been
discussed on this list so far is Victor's
"WebTransport over HTTP/3" individual draft:
https://tools.ietf.org/html/draft-vvv-webtransport-http3

We are therefore placing this document in a call for adoption.

Please reply to this email stating whether you support adoption
of draft-vvv-webtransport-http3 by the WEBTRANS WG. Note
that WG adoption does not indicate consensus on the contents
of the document, only that it's a reasonable starting point for
us to start working on. As such, please DO NOT send comments
about the technical details of the draft on this email thread - please
create a separate email thread on <[email-masked]> or open
a GitHub issue at <https://github.com/vasilvv/webtransport/issues>.

As usual, if you believe that we should not adopt this document,
please state why. In our last meeting we've noted some concerns
around pooling for example, and we plan on discussing those as
a working group once the document is adopted.

This adoption call will last for two weeks until 2021-02-10.

Thanks,
David

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 28 Jan 2021 00:25:15 +0000

Hi David

> We are therefore placing this document in a call for adoption.

Can you please confirm the draft version that you are issuing an adoption
call for?

The reason I ask is that a new draft was published on January 27 (just
yesterday), while the group discussed an older draft (and even a bit of an
editors copy) during the interim meeting.

Personally, I don't think there is material difference but I think it
benefits the group to be precise here.

Cheers
Lucas

---

From: David Schinazi <[email-masked]>
Date: Wed, 27 Jan 2021 16:33:31 -0800

Hi Lucas,

The adoption call covers the latest version as of today, which is -03:
https://tools.ietf.org/html/draft-vvv-webtransport-http3-03

David

---

From: Ian Swett <[email-masked]>
Date: Thu, 28 Jan 2021 13:34:12 -0500

I've read the latest version and support adoption.

---

From: Alan Frindell <[email-masked]>
Date: Fri, 29 Jan 2021 00:48:39 +0000

I’ve read the latest version and I support adoption.

From: Webtransport <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Date: Thursday, January 28, 2021 at 10:34 AM
To: David Schinazi <[email-masked]>
Cc: WebTransport <[email-masked]>, Lucas Pardue <[email-masked]>
Subject: Re: [Webtransport] Confirming Consensus on WebTransport protocols

On Wed, Jan 27, 2021 at 7:33 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lucas,

The adoption call covers the latest version as of today, which is -03:
https://tools.ietf.org/html/draft-vvv-webtransport-http3-03<https://tools.ietf.org/html/draft-vvv-webtransport-http3-03>

David

On Wed, Jan 27, 2021 at 4:25 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi David
On Thu, 28 Jan 2021, 00:17 David Schinazi, <[email-masked]<mailto:[email-masked]>> wrote:
Hi WebTransport enthusiasts,

https://tools.ietf.org/html/draft-vvv-webtransport-http3<https://tools.ietf.org/html/draft-vvv-webtransport-http3>

Can you please confirm the draft version that you are issuing an adoption call for?

The reason I ask is that a new draft was published on January 27 (just yesterday), while the group discussed an older draft (and even a bit of an editors copy) during the interim meeting.

Personally, I don't think there is material difference but I think it benefits the group to be precise here.

Cheers
Lucas
--
Webtransport mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webtransport<https://www.ietf.org/mailman/listinfo/webtransport>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Jan 2021 18:31:57 -0800

I support adoption.