Subject: [Webtransport] WG Review: WebTransport (webtrans)

From: The IESG <[email-masked]>
Date: Fri, 14 Feb 2020 07:20:04 -0800

A new IETF WG has been proposed in the Applications and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send your
comments to the IESG mailing list ([email-masked]) by 2020-02-24.

WebTransport (webtrans)
-----------------------------------------------------------------------
Current status: Proposed WG

Chairs:
  Bernard Aboba <[email-masked]>
  David Schinazi <[email-masked]>

Assigned Area Director:
  Barry Leiba <[email-masked]>

Applications and Real-Time Area Directors:
  Adam Roach <[email-masked]>
  Alexey Melnikov <[email-masked]>
  Barry Leiba <[email-masked]>

Mailing list:
  Address: [email-masked]
  To subscribe: https://www.ietf.org/mailman/listinfo/webtransport
  Archive: https://mailarchive.ietf.org/arch/browse/webtransport/

Group page: https://datatracker.ietf.org/group/webtrans/

Charter: https://datatracker.ietf.org/doc/charter-ietf-webtrans/

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 WebTransport
API https://wicg.github.io/web-transport.

The WebTransport working group will define an application-layer protocol
or suite of application-layer protocols that support a range of simple
communication methods. These must include unreliable messages (that might
be limited by the path MTU), reliable messages, and ordered streams of
reliable messages. Attention will be paid to the performance of the
protocol, with particular attention to the protocol’s overhead and the
potential for head-of-line blocking; its ability to be deployed and used
reliably under different network conditions; and its ability to integrate
into the Web security model. The working group will not define new
transport protocols but will instead use existing protocols such as QUIC
and TLS/TCP.

The group will pay attention to security issues arising from the above
scenarios so as to protect against creation of new modes of attack.

To assist in the coordination with owners of the WebTransport API, the
group will initially develop an overview document containing use cases
and requirements in order to clarify the goals of the effort. The
requirements will include those arising from the WebTransport API.
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 WebTransport API.

The group will also coordinate with related working groups within the IETF,
such as QUIC and HTTPBIS, as appropriate.  In particular, if the working
group needs any changes to or extensions of the core protocols, those
issues will be raised with the relevant working groups for decisions on how
best to handle them.  If those decisions result in work in WebTrans, the
working group last calls for that work will again be sent to the relevant
working groups.

Milestones:

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

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

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

  Jan 2021 - Issue WG last call on the first WebTransport protocol document

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Feb 2020 14:14:37 -0600

As usual, I'm reading this, and not just looking at the words (as
previously).

Most of it looks fine, except for the part where I fell off the edge of the
cliff.

> comments to the IESG mailing list ([email-masked]) by 2020-02-24.

Speaking of "head of line blocking" ...

> transport protocols but will instead use existing protocols such as QUIC

 Is the intention here to allow applications using WebTransport to do
something like what applications using HTTP/3-QUIC do today, and failover
to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited?

If "Yes", that might be said more clearly.

If "No" - how badly does the world need WebTransport for TLS/TCP?

I ask this especially because the charter raises head of line blocking as a
consideration - as it should, in 2020 - but TLS/TCP hasn't changed about
that since QUIC was chartered in 2016, with avoiding TCP head of line
blocking as a key goal. So listing QUIC and TLS/TCP as apparently equally
legit existing protocols seems odd.

Could someone clue me in about this?

Best,

Spencer, who is also curious about possible coordination between
WebTransport and TAPS, but let's ignore that for now.

> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: David Schinazi <[email-masked]>
Date: Fri, 14 Feb 2020 12:50:36 -0800

Hi Spencer,

The main goal is for WebTransport to use QUIC and benefit
from QUIC features such as reduced head-of-line blocking.
However, on networks where QUIC is blocked, the WG will
most likely define a fallback version over TLS/TCP. That
version will obviously not see QUIC features. I think this fits
into the proposed charter, as it requires paying attention to
these concerns.

We explicitly chose not to specify which exact protocols
WebTransport will be built on in the charter, because we
have not reached consensus on that yet, and this will be
discussed in the newly formed WG.

Thanks,
David

On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

> Most of it looks fine, except for the part where I fell off the edge of
> the cliff.
>
> I ask this especially because the charter raises head of line blocking as
> a consideration - as it should, in 2020 - but TLS/TCP hasn't changed about
> --
> Webtransport mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webtransport
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Feb 2020 17:41:42 -0600

Hi, David,

> discussed in the newly formed WG.

That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, if
you're deferring the decision to the working group. Just saying "The
working group will not define new
transport protocols but will instead use existing protocols." would have
avoided my confusion.

Best, and enjoy your working group.

Spencer

---

From: David Schinazi <[email-masked]>
Date: Fri, 14 Feb 2020 15:54:33 -0800

Thanks Spencer! We added those specific protocols
at the request of the transport ADs, so I think we'll
leave them in for now if that's OK.

David

On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF <
[email-masked]> wrote:

>>> I ask this especially because the charter raises head of line blocking
>>> as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed
>>> about that since QUIC was chartered in 2016, with avoiding TCP head of line

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Feb 2020 17:57:00 -0600

Hi, David,

> leave them in for now if that's OK.

Of course. Do the right thing :-)

Best,

Spencer

>> That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples,
>> if you're deferring the decision to the working group. Just saying "The

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Feb 2020 11:08:55 +0000

Hi,

I am fine with dropping the specifics now that the charter is explicit about
using existing transport protocols. However, note that I am not considering UDP
as transprot protocol that WebTrans can just use. 

Cheers

Magnus

On Fri, 2020-02-14 at 17:57 -0600, Spencer Dawkins at IETF wrote:
> > > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi <dschinazi.ietf@gmail..com>
> > > wrote:
> > > > Hi Spencer,
> > > > 
> > > > > Most of it looks fine, except for the part where I fell off the edge
> > > > > of the cliff.
> > > > > 
> > > > > something like what applications using HTTP/3-QUIC do today, and
> > > > > failover to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-
> > > > > limited?
> > > > > 
> > > > > as a consideration - as it should, in 2020 - but TLS/TCP hasn't
> > > > > changed about that since QUIC was chartered in 2016, with avoiding TCP
> > > > > head of line blocking as a key goal. So listing QUIC and TLS/TCP as
> > > > > apparently equally legit existing protocols seems odd.
> > > > > 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 17 Feb 2020 15:09:04 +0100

I would prefer to have the protocol in. If the intention is to “only” use TLS/TCP as a fallback, it could be even good to make this explicit in the charter.

Mirja

> On 15. Feb 2020, at 00:57, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, David, 
> 
> On Fri, Feb 14, 2020 at 5:54 PM David Schinazi <[email-masked]> wrote:
> On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF <[email-masked]> wrote:
> Hi, David, 
> 
> On Fri, Feb 14, 2020 at 2:50 PM David Schinazi <dschinazi.ietf@gmail..com> wrote:
> Hi Spencer,
> 
> That's all fine, but I'd suggest dropping QUIC and TLS/TCP as examples, if you're deferring the decision to the working group. Just saying "The working group will not define new
> transport protocols but will instead use existing protocols." would have avoided my confusion.
> 
> On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF <[email-masked]> wrote:
> As usual, I'm reading this, and not just looking at the words (as previously).
> 
> Most of it looks fine, except for the part where I fell off the edge of the cliff.
> 
>  Is the intention here to allow applications using WebTransport to do something like what applications using HTTP/3-QUIC do today, and failover to HTTP/2-TLS-TCP if QUIC is blocked or significantly rate-limited?
> 
> I ask this especially because the charter raises head of line blocking as a consideration - as it should, in 2020 - but TLS/TCP hasn't changed about that since QUIC was chartered in 2016, with avoiding TCP head of line blocking as a key goal. So listing QUIC and TLS/TCP as apparently equally legit existing protocols seems odd.
> 
> Spencer, who is also curious about possible coordination between WebTransport and TAPS, but let's ignore that for now. 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 26 Feb 2020 08:57:12 -0600

Hi, David,

On Mon, Feb 17, 2020 at 8:09 AM Mirja Kuehlewind <[email-masked]>
wrote:

> I would prefer to have the protocol in. If the intention is to “only” use
> TLS/TCP as a fallback, it could be even good to make this explicit in the
> charter.
>

FWIW. Mirja's suggestion would have also improved my understanding of the
charter. Clarity is good.

Do the right thing, of course :-)

Best,

Spencer