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

Hi, David,

On Mon, Feb 17, 2020 at 8:09 AM Mirja Kuehlewind <ietf@kuehlewind.net>
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

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