Subject: [Webtransport] Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Fri, 31 Jan 2020 08:39:09 -0800

Magnus Westerlund has entered the following ballot position for
charter-ietf-webtrans-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-webtrans/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

This charter is so open ended on what protocol that is to be developed that it
could define a new IP version as well as transport protocols. I don't think
that is the intention. To my understanding this effort could more clearly be
defined as defining one or two application protocol that fulfills the
WebTransport API and is using QUIC or HTTP/3. If the charter can be clarified
to not include transport protocol work and which existing transport protocols
or other protocols the solution will build on it would be much better and well
defined work. I also think creating mappings to other transport protocols
should require rechartering to enable a wider discussion of such choices.

Secondly:

The group will also coordinate with related working groups within the IETF,
such as QUIC and HTTPBIS, as appropriate.

With the current state of QUIC developement and HTTP/3 mapping definition, i.e.
still working on the initial version, I would like to have a more firm wording
that the WebTrans WG will actually have to take any requests for extensions of
HTTP/3 and QUIC to the relevant WG.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I also would appreciate if someone can clarify what stage of formality the
Web-Transport API has been adopted in W3C and is being worked on. Trying to
find anything about which group it belongs to on the W3C page didn't give me
any information. All I found is that there have been a workshop on game
communication where this was discussed and raised in some discussions.

Having lived through the WebRTC / RTCWeb interactions it would good to know
more how the interaction between the bodies are intended to work. Especially as
changes to the API can have significant impact on what work needs to happen in
the IETF.

The current API draft does not include any discussion of priority. However
draft-vvv-webtrans-overview does mention priorities. As this API appears to
support multiple parallel transmissions and transfers I think at a minimal a
sender transport protocol scheduling or HTTP/3 priority  would be likely to be
part of the work. I also have to ask if this is likely to attempted to be
mapped also towards the network level, for example DSCPs? If any such work is
expected and intended I think that needs to be raised. Otherwise I would assume
that at most what this work will be to use the undefined APIs to HTTP/3 and
QUIC to influence those protocol to perform stream priorities.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 31 Jan 2020 10:37:03 -0800

Howdy Magnus,

One small point, below.

On Fri, Jan 31, 2020 at 8:39 AM Magnus Westerlund via Datatracker <
[email-masked]> wrote:

> part of the work.

HTTP/3 priority is, uh, well, um, here's the draft:
A.2.1.
<https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-a.2.1>Prioritization
Differences
<https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-prioritization-differences>

HTTP/2 specifies priority assignments in PRIORITY frames and (optionally)
in HEADERS frames. HTTP/3 does not provide a means of signaling priority.
Note that while there is no explicit signaling for priority, this does not
mean that prioritization is not important for achieving good performance.

The working group has been up and down that hill and eventually decided not
to die on it, so that the work could go forward more rapidly.  If you'd
like to grab someone for the backstory, Jana or Roberto Peon would be
possible choices.

> I also have to ask if this is likely to attempted to be

regards,

Ted

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jan 2020 19:09:35 -0800

Comments below.

> From: Magnus Westerlund via Datatracker <[email-masked]>
> Date: January 31, 2020 at 08:39:10 PST
> To: The IESG <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: Magnus Westerlund's Block on charter-ietf-webtrans-00-00: (with BLOCK and COMMENT)
> Reply-To: Magnus Westerlund <[email-masked]>
> 
> that is the intention.

[BA] Definitely not the intention .

> To my understanding this effort could more clearly be
> WebTransport API and is using QUIC or HTTP/3.

[BA] Would it be sufficient to add this clarification to the existing sentence? The result would look like this.

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

> If the charter can be clarified
> With the current state of QUIC development and HTTP/3 mapping definition, i.e.

[BA] Would the following work?

“The group will also coordinate with related working groups within the IETF,
such as QUIC and HTTPBIS, as appropriate.  Requests for extensions of HTTP/3 and QUIC will be brought to the relevant WG.”

> Web-Transport API has been adopted in W3C and is being worked on.

[BA] The WebTransport API is currently under development within the W3C WICG: 
https://wicg.github.io/web-transport/

Since the API is maturing, there is interest in moving ahead with the standardization process.  However, the next steps are not yet clear.  My last conversation with W3C management indicated that they were considering the implications of the recently concluded W3C-WHATWG agreement.  See the end of this message for details. 

> Trying to

> changes to the API can have significant impact on what work needs to happen in

[BA] Overall, the information flow seems more likely to go from protocol to API than the other way around.  At least that’s how things have worked so far with the WebTransport API, whose development mirrored the development of the QUIC transport protocol (e.g. Introducing uni-directional streams once this was introduced in the protocol).  Also, please keep in mind that protocols tend to have a longer lifetime than APIs (e.g. there are multiple WebSockets APIs, some message-based, others streams-based). 

> QUIC to influence those protocol to perform stream priorities.

[BA] Priority has not faired well within recent W3C API efforts, including RTCDataChannel and WebRTC.  So not sure how much energy there is. Also see Ted’s message relating to the status of priority in HTTP/3. 

—————————— W3C/WHATWG Observations below ——————————-

The history of W3C and WHATWG appears to be relevant to the prospective standardization path for WebTransport API.

1. A potential analog to the WebTransport API is the WebSockets API.  After its initial development in W3C, the WebSockets API was transitioned over to a Living Standard in the WHATWG: 
https://html.spec.whatwg.org/multipage/web-sockets.html#the-websocket-interface

2. Since the transition of WebSockets API to WHATWG, subsequent work (including the WebSocket-Stream API and WebTransport) has been based on the WHATWG Streams API (now also a Living Standard): 
https://streams.spec.whatwg.org/

FYI, Info on the WebSockets-Stream API is here:
https://docs.google.com/document/d/1XuxEshh5VYBYm1qRVKordTamCOsR-uGQBCYFcHXP4L0/edit#heading=h.4f9946en7wca

While I’m not personally familiar with the history of WebSockets API development in W3C or why that API and subsequent work Is now being handled in WHATWG, the history (and the subsequent agreement between W3C and WHATWG) seems to be a factor in considering whether work of this type belongs in W3C versus WHATWG.

That said, folks interested in WebTransport API seem to favor moving ahead in W3C rather than WHATWG.