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

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 <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, David, 
> 
> On Fri, Feb 14, 2020 at 5:54 PM David Schinazi <dschinazi.ietf@gmail.com> 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 <spencerdawkins.ietf@gmail.com> 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 <spencerdawkins.ietf@gmail.com> 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 <iesg-secretary@ietf.org> 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 (iesg@ietf.org) by 2020-02-24.
> 
> WebTransport (webtrans)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>   Bernard Aboba <bernard.aboba@gmail.com>
>   David Schinazi <dschinazi.ietf@gmail.com>
> 
> Assigned Area Director:
>   Barry Leiba <barryleiba@computer.org>
> 
> Applications and Real-Time Area Directors:
>   Adam Roach <adam@nostrum.com>
>   Alexey Melnikov <aamelnikov@fastmail.fm>
>   Barry Leiba <barryleiba@computer.org>
> 
> Mailing list:
>   Address: webtransport@ietf.org
>   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
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> -- 
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport