Subject: [Webtransport] WEBTRANS objectives and potential work items

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 Jan 2020 17:15:42 -0800

During the WEBTRANS BOF there were some questions relating to objectives as
well as potential work items.

This included some questions relating to "failover transport" (e.g. whether
new work was needed for this or not).  Also, EKR questioned why it was
necessary to define two protocols (one for webtransport over HTTP/3, and
another for direct usage of QUIC streams and datagrams).

I've submitted a PR to clarify the objectives and work items:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5

The modified description and milestones are provided below.  Comments
welcome.

-----------------------------------------------------------------------------------------------
Description of Working Group

The WebTransport working group will define new client-server protocols or
protocol extensions in order to support the development of the W3C
WebTransport API https://wicg.github.io/web-transport.

These protocols will support:

   -

   Reliable bidirectional and unidirectional communication that provides
   greater efficiency than Websockets (e.g. removal of head-of-line blocking).
   -

   Unreliable datagram communication, functionality not available in
   Websockets.
   -

   Origin checks to allow supporting the Web's origin-based security model.

The WebTransport working group will define a protocol or set of protocols
that fits these requirements. Multiple protocols might be required to
support different usage scenarios, such as multiplexing with HTTP/3 or
networks where UDP is blocked.

The group will pay attention to security issues arising from the above
scenarios so as to ensure against creation of new modes of attack, as well
as to ensure that security issues addressed in the design of Websockets
remain addressed in the new work.

To assist in the coordination with W3C, the group will initially develop an
overview document containing use cases and requirements in order to clarify
the goals of the effort. Feedback will also be solicited at various points
along the way in order to ensure the best possible match between the
protocol extensions and the needs of the W3C WebTransport API. The clarity
and interoperability of specifications will be confirmed via test events
and hackathons.

The group will also coordinate with other working groups within the IETF
(e.g. QUIC, HTTPBIS) as appropriate.
Goals and Milestones

   -

   March 2020 - Adopt a WebTransport Overview draft as a WG work item
   -

   March 2020 - Adopt a draft defining a WebTransport protocol as a WG work
   item
   -

   August 2020 - Issue WG last call of the WebTransport Overview document.
   -

   November 2020 - Issue WG last call on the first WebTransport protocol
   document

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 03 Jan 2020 14:28:47 +1100

Hi Bernard,

The way this is written it implies that the bulleted list contains enough detail for requirements, but I don't think that these are in fact clear enough.  On the contrary, I'm finding them to be confusing.

The underlying protocol in WebSockets provides a bidirectional stream of finite sized messages, which are in turn finite length sequences of bytes.  By mentioning WebSockets, this text implies that the requirements for WebSockets apply, but also says that it won't induce head-of-line blocking.  I'm having a hard time reconciling those.  I suspect that what is really in order here is "whatever we decide in the W3C API makes sense to support, based on what QUIC can provide and (maybe) what can be emulated with some arrangement of WebSockets and HTTP where case QUIC isn't available".  The later text on building overview and requirements supports that view, which is what makes the detail confusing.

Like WebSockets, we could decide to build a message-based system with ordering between messages, but how that is implemented could vary greatly.  Even within QUIC, there are many possibilities:

* We might decide to use a single bidirectional QUIC stream that uses message delimiters on that streams to distinguish messages.
* We might use unidirectional streams in much the same way, but then build some mechanism to couple them into pairs as needed.
* We might allow messages to be sent asynchronously without explicit ordering, then use references to those streams from another stream to establish an ordering.
* We might use different streams for each message and indicate ordering in the stream header.

That's not exhaustive, I'm sure.

The possibility that a single connection might allow multiplexing of different "subprotocols" on the same QUIC connection makes some of these options more difficult or even invalid.  I know Victor is prepared to argue that multiplexing is Hard and likely incompatible with some of the things he aspires to do eventually, but I don't think we should decide that question in the charter.  I tend to think that there is value in being able to interact with multiple "resources" on the same connection, even if I think that the "subprotocol" concept is an abject failure.

Maybe the right answer is to reduce this to a simpler statement to replace the paragraphs starting from "These protocols" and ending at "blocked.": 

> The WebTransport working group will define a protocol or suite of protocols that support a range of simple communication methods.  These must include unreliable messages (that might be limited to by the path MTU), reliable messages, and ordered streams of reliable messages.  Attention will be paid to performance of the protocol, in particular protocol overheads and the potential for head-of-line blocking; its ability to be deployed and used reliably under different network conditions; and the ability to integrate protocol use into the Web security model.

I don't want to say that this includes a superset of the capabilities provided by thewebsocketprotocol, because that seems to be an open question, but I'm not opposed to deciding that early in the process if that is where we end up.  I also don't think that you need to worry about HTTP/3 multiplexing at this level either.  That comes with working out how to integrate it.

Cheers,
Martin

On Fri, Jan 3, 2020, at 12:15, Bernard Aboba wrote:
> During the WEBTRANS BOF there were some questions relating to 
> objectives as well as potential work items.
> 
> This included some questions relating to "failover transport" (e.g. 
> whether new work was needed for this or not). Also, EKR questioned why 
> it was necessary to define two protocols (one for webtransport over 
> HTTP/3, and another for direct usage of QUIC streams and datagrams).
> 
> The modified description and milestones are provided below. Comments welcome.
> 
> The WebTransport working group will define new client-server protocols 
> or protocol extensions in order to support the development of the W3C 
>  * Reliable bidirectional and unidirectional communication that 
> provides greater efficiency than Websockets (e.g. removal of 
> head-of-line blocking).
> 
>  * Unreliable datagram communication, functionality not available in Websockets.
> 
>  * Origin checks to allow supporting the Web's origin-based security model.
> 
> The WebTransport working group will define a protocol or set of 
> protocols that fits these requirements. Multiple protocols might be 
> required to support different usage scenarios, such as multiplexing 
> with HTTP/3 or networks where UDP is blocked.
> 
> scenarios so as to ensure against creation of new modes of attack, as 
> well as to ensure that security issues addressed in the design of 
> Websockets remain addressed in the new work.
> 
> To assist in the coordination with W3C, the group will initially 
> develop an overview document containing use cases and requirements in 
> order to clarify the goals of the effort. Feedback will also be 
> solicited at various points along the way in order to ensure the best 
> possible match between the protocol extensions and the needs of the W3C 
> WebTransport API. The clarity and interoperability of specifications 
> will be confirmed via test events and hackathons.
> 
> The group will also coordinate with other working groups within the 
> IETF (e.g. QUIC, HTTPBIS) as appropriate.
> 
> Goals and Milestones
> 
>  * March 2020 - Adopt a WebTransport Overview draft as a WG work item
> 
>  * March 2020 - Adopt a draft defining a WebTransport protocol as a WG work item
> 
>  * August 2020 - Issue WG last call of the WebTransport Overview document.
> 
>  * November 2020 - Issue WG last call on the first WebTransport 
> protocol document
> 
> -- 
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Jan 2020 10:18:06 -0800

Thanks, Martin.

I've incorporated your suggestions into a modified PR:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5

On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson <[email-masked]> wrote:

> Hi Bernard,
>
> The way this is written it implies that the bulleted list contains enough
> detail for requirements, but I don't think that these are in fact clear
> enough.  On the contrary, I'm finding them to be confusing.
>
> The underlying protocol in WebSockets provides a bidirectional stream of
> finite sized messages, which are in turn finite length sequences of bytes.
> By mentioning WebSockets, this text implies that the requirements for
> WebSockets apply, but also says that it won't induce head-of-line
> blocking.  I'm having a hard time reconciling those.  I suspect that what
> is really in order here is "whatever we decide in the W3C API makes sense
> to support, based on what QUIC can provide and (maybe) what can be emulated
> with some arrangement of WebSockets and HTTP where case QUIC isn't
> available".  The later text on building overview and requirements supports
> that view, which is what makes the detail confusing.
>
> Like WebSockets, we could decide to build a message-based system with
> ordering between messages, but how that is implemented could vary greatly.
> Even within QUIC, there are many possibilities:
>
> * We might decide to use a single bidirectional QUIC stream that uses
> message delimiters on that streams to distinguish messages.
> * We might use unidirectional streams in much the same way, but then build
> some mechanism to couple them into pairs as needed.
> * We might allow messages to be sent asynchronously without explicit
> ordering, then use references to those streams from another stream to
> establish an ordering.
> The possibility that a single connection might allow multiplexing of
> different "subprotocols" on the same QUIC connection makes some of these
> options more difficult or even invalid.  I know Victor is prepared to argue
> that multiplexing is Hard and likely incompatible with some of the things
> he aspires to do eventually, but I don't think we should decide that
> question in the charter.  I tend to think that there is value in being able
> to interact with multiple "resources" on the same connection, even if I
> think that the "subprotocol" concept is an abject failure.
>
> Maybe the right answer is to reduce this to a simpler statement to replace
> the paragraphs starting from "These protocols" and ending at "blocked.":
>
> > The WebTransport working group will define a protocol or suite of
> protocols that support a range of simple communication methods.  These must
> include unreliable messages (that might be limited to by the path MTU),
> reliable messages, and ordered streams of reliable messages.  Attention
> will be paid to performance of the protocol, in particular protocol
> overheads and the potential for head-of-line blocking; its ability to be
> deployed and used reliably under different network conditions; and the
> ability to integrate protocol use into the Web security model.
>
> I don't want to say that this includes a superset of the capabilities
> provided by thewebsocketprotocol, because that seems to be an open
> question, but I'm not opposed to deciding that early in the process if that
> is where we end up.  I also don't think that you need to worry about HTTP/3
> multiplexing at this level either.  That comes with working out how to
> integrate it.
>
> Cheers,
> Martin
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 6 Jan 2020 22:08:05 +0100

one question,  is p2p browser to browser connection in the scope of
webtransport?

El lun., 6 ene. 2020 19:18, Bernard Aboba <[email-masked]>
escribió:

>> * We might use unidirectional streams in much the same way, but then
>> build some mechanism to couple them into pairs as needed.
>> Maybe the right answer is to reduce this to a simpler statement to
>> replace the paragraphs starting from "These protocols" and ending at
>> "blocked.":
>>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 6 Jan 2020 14:20:58 -0800

This seems like an improvement. However, perhaps we can skip the stage
where we have science fiction-based milestones? Being done by end of 2020
seems....unlike.y

-Ekr

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 7 Jan 2020 10:47:26 +0100

Hi Bernard,

Thanks for the update.

I have to say I find the term "protocol or suite of protocols” a bit vague (which can make the charter very open-ended). I don’t think that's the intention (given the very concrete and fine milestones). How about saying something concrete like:

"The WebTransport working group will define the WebTransport protocol which supports a suite of simple client-server communication methods that include unreliable messages (that might be limited by the path MTU), reliable messages, and ordered streams of reliable messages. Initially the working group will work on WebTransport directly over QUIC or layered over HTTP/3.”

Further if there is already agreement that this should not be an extension of Websockets or a new version or something, I think that should be added to the charter together with some some reasoning why that is not the appropriate approach. If there is still an open question for discussion how close the WebTransport protocol should be designed to WebSockets, then I think Websockets should be mention in the charter as well.

Mirja

> On 6. Jan 2020, at 19:18, Bernard Aboba <[email-masked]> wrote:
> 
> Thanks, Martin. 
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 8 Jan 2020 10:01:41 -0800

Hi everyone, and thanks for the feedback!

We've made some changes to the PR to incorporate it:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files
Most notably, we've removed all mentions of Websocket to the charter as
that was more confusing than helpful.

Hi Mirja, we use the term "protocol or suite of protocols” to indicate that
the working group might decide to either
- build a single protocol that addresses all known use-cases
- build multiple protocols that suit different use-cases
We don't have consensus between these points yet, and we'll want to discuss
this inside the working group,
so we're wording the charter in such a way that allows both options to be
discussed. We got clear feedback
in Singapore that while there is shared interest in the topic, there is not
yet consensus on the solutions, so
we're intentionally no baking solutions into the charter to let us discuss
options within the working group.

Thanks,
David

On Tue, Jan 7, 2020 at 1:47 AM Mirja Kuehlewind <[email-masked]> wrote:

> Hi Bernard,
>
> Thanks for the update.
>
> I have to say I find the term "protocol or suite of protocols” a bit vague
> (which can make the charter very open-ended). I don’t think that's the
> intention (given the very concrete and fine milestones). How about saying
> something concrete like:
>
> "The WebTransport working group will define the WebTransport protocol
> which supports a suite of simple client-server communication methods that
> include unreliable messages (that might be limited by the path MTU),
> reliable messages, and ordered streams of reliable messages. Initially the
> working group will work on WebTransport directly over QUIC or layered over
> HTTP/3.”
>
> Further if there is already agreement that this should not be an extension
> of Websockets or a new version or something, I think that should be added
> to the charter together with some some reasoning why that is not the
> appropriate approach. If there is still an open question for discussion how
> close the WebTransport protocol should be designed to WebSockets, then I
> think Websockets should be mention in the charter as well.
>
> Mirja
>
>
> > The way this is written it implies that the bulleted list contains
> enough detail for requirements, but I don't think that these are in fact
> clear enough.  On the contrary, I'm finding them to be confusing.
> >

---

From: Victor Vasiliev <[email-masked]>
Date: Fri, 24 Jan 2020 18:48:51 -0500

I've looked at the text of the charter, and it looks great.  Left a small
comment about wording on the GitHub PR.

On Wed, Jan 8, 2020 at 1:02 PM David Schinazi <[email-masked]>
wrote:

> Hi Mirja, we use the term "protocol or suite of protocols” to indicate
> that the working group might decide to either
> We don't have consensus between these points yet, and we'll want to
> discuss this inside the working group,
> in Singapore that while there is shared interest in the topic, there is
> not yet consensus on the solutions, so
>> I have to say I find the term "protocol or suite of protocols” a bit
>> vague (which can make the charter very open-ended). I don’t think that's
>> the intention (given the very concrete and fine milestones). How about
>> saying something concrete like:
>>
>> Further if there is already agreement that this should not be an
>> extension of Websockets or a new version or something, I think that should
>> be added to the charter together with some some reasoning why that is not
>> the appropriate approach. If there is still an open question for discussion
>> how close the WebTransport protocol should be designed to WebSockets, then
>> I think Websockets should be mention in the charter as well.
>>
>> Mirja
>>
>>
>> > The underlying protocol in WebSockets provides a bidirectional stream
>> of finite sized messages, which are in turn finite length sequences of
>> bytes.  By mentioning WebSockets, this text implies that the requirements
>> for WebSockets apply, but also says that it won't induce head-of-line

---

From: Alan Frindell <[email-masked]>
Date: Fri, 24 Jan 2020 23:55:17 +0000

I also left a minor comment on the proposed text but otherwise the charter looks good to me.

-Alan

From: Webtransport <[email-masked]> on behalf of Victor Vasiliev <vasilvv=[email-masked]>
Date: Friday, January 24, 2020 at 3:49 PM
To: David Schinazi <[email-masked]>
Cc: WebTransport <[email-masked]>, Mirja Kuehlewind <[email-masked]>, Bernard Aboba <[email-masked]>
Subject: Re: [Webtransport] WEBTRANS objectives and potential work items

I've looked at the text of the charter, and it looks great.  Left a small comment about wording on the GitHub PR.

On Wed, Jan 8, 2020 at 1:02 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Hi everyone, and thanks for the feedback!

We've made some changes to the PR to incorporate it:
https://github.com/DavidSchinazi/webtrans-wg-materials/pull/5/files
Most notably, we've removed all mentions of Websocket to the charter as that was more confusing than helpful.

Hi Mirja, we use the term "protocol or suite of protocols” to indicate that the working group might decide to either
- build a single protocol that addresses all known use-cases
- build multiple protocols that suit different use-cases
We don't have consensus between these points yet, and we'll want to discuss this inside the working group,
so we're wording the charter in such a way that allows both options to be discussed. We got clear feedback
in Singapore that while there is shared interest in the topic, there is not yet consensus on the solutions, so
we're intentionally no baking solutions into the charter to let us discuss options within the working group.

Thanks,
David

On Tue, Jan 7, 2020 at 1:47 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bernard,

Thanks for the update.

Mirja

> On 6. Jan 2020, at 19:18, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
>
> Thanks, Martin.
>
> On Thu, Jan 2, 2020 at 7:29 PM Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Bernard,
>
> > WebTransport API https://wicg.github.io/web-transport<https://urldefense.proofpoint.com/v2/url?u=https-3A__wicg.github.io_web-2Dtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=DuN7ay5HSNQciqdfcq7ZN1CRsJ7gb7UowANeqLXX_RE&e=>.
> >
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/webtransport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_webtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=wBRhJc_-erusb45ma3lOG-dSnA-TKOQ_qLAOaA80HQs&e=>
> >
>
> --
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/webtransport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_webtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=wBRhJc_-erusb45ma3lOG-dSnA-TKOQ_qLAOaA80HQs&e=>
> --
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/webtransport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_webtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=wBRhJc_-erusb45ma3lOG-dSnA-TKOQ_qLAOaA80HQs&e=>

--
Webtransport mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webtransport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_webtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=wBRhJc_-erusb45ma3lOG-dSnA-TKOQ_qLAOaA80HQs&e=>
--
Webtransport mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/webtransport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_webtransport&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=1ITKsZAeDaw65eyQcdVGcw&m=99pxAjRsplt3UiISdvmKt08jnn6NGWeURwdtxLZOIuo&s=wBRhJc_-erusb45ma3lOG-dSnA-TKOQ_qLAOaA80HQs&e=>