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

[Magnus Westerlund <[e-mail]>]

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:
> Hi, David, 
> 
> On Fri, Feb 14, 2020 at 5:54 PM David Schinazi <[e-mail]>
> wrote:
> > 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.
> > 
> 
> Of course. Do the right thing :-)
> 
> Best,
> 
> Spencer
>  
> > David
> > 
> > On Fri, Feb 14, 2020 at 3:42 PM Spencer Dawkins at IETF <
> > [e-mail]> wrote:
> > > Hi, David, 
> > > 
> > > On Fri, Feb 14, 2020 at 2:50 PM David Schinazi <dschinazi.ietf@gmail..com>
> > > wrote:
> > > > 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.
> > > > 
> > > 
> > > 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
> > >  
> > > > Thanks,
> > > > David
> > > > 
> > > > On Fri, Feb 14, 2020 at 12:15 PM Spencer Dawkins at IETF <
> > > > [e-mail]> 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.
> > > > > 
> > > > > On Fri, Feb 14, 2020 at 9:20 AM The IESG <[e-mail]>
> > > > > wrote:
> > > > > > 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 ([e-mail]) by 2020-02-24.
> > > > > > 
> > > > > > WebTransport (webtrans)
> > > > > > --------------------------------------------------------------------
> > > > > > ---
> > > > > > Current status: Proposed WG
> > > > > > 
> > > > > > Chairs:
> > > > > >   Bernard Aboba <[e-mail]>
> > > > > >   David Schinazi <[e-mail]>
> > > > > > 
> > > > > > Assigned Area Director:
> > > > > >   Barry Leiba <[e-mail]>
> > > > > > 
> > > > > > Applications and Real-Time Area Directors:
> > > > > >   Adam Roach <[e-mail]>
> > > > > >   Alexey Melnikov <[e-mail]>
> > > > > >   Barry Leiba <[e-mail]>
> > > > > > 
> > > > > > Mailing list:
> > > > > >   Address: [e-mail]
> > > > > >   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
> > > > > 
> > > > > Speaking of "head of line blocking" ... 
> > > > >  
> > > > > > 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.
> > > > > 
> > > > >  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. 
> > > > > 
> > > > > > 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
> > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > IETF-Announce mailing list
> > > > > > [e-mail]
> > > > > > https://www.ietf.org/mailman/listinfo/ietf-announce
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------