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

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 <
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
>>>
>>