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

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