From nobody Wed Aug 14 04:13:46 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F4C1200F8 for ; Wed, 14 Aug 2019 04:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DoLAppBAf14a for ; Wed, 14 Aug 2019 04:13:36 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810491200FF for ; Wed, 14 Aug 2019 04:13:34 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id a30so15976474lfk.12 for ; Wed, 14 Aug 2019 04:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hSwpr3GZueMRorptTd8XOsAQgdkzzbPrmojpL5s2+Qc=; b=LZWmbqVyuC5WggkzieaQiu/wSZ2Y56RAVC9LQUJCeBWgzmVwPkvYHpsMjFEwG0w2Ie A29wS2nfb0g8OYBbl1j8NycZlsL6DErEk73Wonni8O6SQapxURZO3M9wSwUo95lhEL12 FjrT/V/Yh55znqFnScRfwKFEwZqwuqc8OMnS5TlW28lm37jGXjTXdO6LHNmXWy43iAnm nL+LYt9Qm+ewMVtycsx/5W+hkd9ferREHV50iquhANYCskcPPJm986gMShlbuwEC9J3K q9zvwAwXw1jiJlmEccz5yzh+YrTXvAJHraOAdS9xhzKExJXjOeBh+koWqfBONlBjTI67 gA1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hSwpr3GZueMRorptTd8XOsAQgdkzzbPrmojpL5s2+Qc=; b=WbMqlnsBowM4D+/i2wtK/wzfZeXoce1YJniqeYhsvBQTc/kFe7182SqMnW97GdpyVF LzNx0kROuHTQPn4RvW5DZ4cy7KY1LAZ75x2iSocYFT0MZajOnlVrHiqvl/nWbELkmtT8 xLNEA6rC+Xfqc44uSCZutRsrDb1ItyR5BRSbyaQ+9yZQc/LGsR6d8lwICglTBJZIEVyh 5SmhKBHCMRHP1/cWOnE+WyagfMx/j/mPw4paxv5Q/7UhfRFGORvbfHidtFX02JH6SkF7 Uqzt7LuJ2bUV6JTbVlxOXyBh7+p4ZPi4Px5nHFl6X9pgyb0NOL+E+urO75V0uuhcQWq3 JgjA== X-Gm-Message-State: APjAAAV/EVaQK3Kn+RxHfA2rDBX7ekyCA1EpkttZff/CZxNgIbc0a7E+ 26qAy3myObvMh1Wbrx1mdrCu6mbzcaVK/Ta56gmUKw== X-Google-Smtp-Source: APXvYqzcM7gECWAx9GaI0RyieHN2XgqUGYPaWteoIWWXZXZSCfbKfGl3Laua/J5lX02FRuToRwgVn0WAvJ2Jqp8d8ew= X-Received: by 2002:ac2:545b:: with SMTP id d27mr25803716lfn.36.1565781212296; Wed, 14 Aug 2019 04:13:32 -0700 (PDT) MIME-Version: 1.0 References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> In-Reply-To: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> From: Victor Vasiliev Date: Wed, 14 Aug 2019 07:13:20 -0400 Message-ID: To: Andy Green Cc: dispatch@ietf.org, David Schinazi , hybi@ietf.org, IETF QUIC WG , HTTP Working Group , webtransport@ietf.org Content-Type: multipart/alternative; boundary="000000000000f4dd45059011d867" Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 11:13:39 -0000 --000000000000f4dd45059011d867 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: > > > On 7/22/19 1:36 PM, Victor Vasiliev wrote: > > Hello everyone, > > > > Today, at the dispatch working group meeting (18:10), I am going to > > present WebTransport. WebTransport is a protocol framework that allows > > multiplexed and datagram-oriented transport protocols to be used by the > > web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). > > "Historically, web applications that needed bidirectional data stream > between a client and a server could rely on WebSockets [RFC6455], a > message-based protocol compatible with Web security model. However, > since the abstraction it provides is a single ordered stream of > messages, it suffers from head-of-line blocking (HOLB), meaning that > all messages must be sent and received in order even if they are > independent and some of them are no longer needed. This makes it a > poor fit for latency sensitive applications which rely on partial > reliability and stream independence for performance." > > The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary > fragmentation of messages allowing interleaving with control frames. > It allows them to be fragmented, but the fragments have to be in order. The multiplexing extension is mentioned as potential future work in RFC 6455, but I don't believe it ever actually materialized. > ws-over-h2 allows you to can the h2 stream when you want as well. > True, though you can't use them in the same way as pure QUIC streams because QUIC streams are created immediately, whereas a new WS requires a handshake. > > " Each new stream would require a WebSocket handshake to agree on > application protocol used, meaning that it would take at least one > RTT for each new stream before the client can write to it." > > Yes it was knowingly done as a hack to try to encourage uptake from > browser vendors... it's not really integrated into the encapsulating > protocol. > It =3D ws-over-http2 being a thin overlay over existing WSP? > > * WebTransport overview: > > https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 > > * QuicTransport: > > https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 > > * Http3Transport: > > https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 > > There's no h2 transport implementation? > > Not everything that might want to use this will get h3 capability in a > reasonable timeframe. If there's more momentum behind it than RFC8441 > there's probably room for a generic long-lived bidirectional extension > to h2 either reusing DATA or a new frame type. > I think we might adapt an HTTP/2 transport as well (via draft-kinnear-httpbis-http2-transport). > It's a good idea to have it ride on other protocols. Not doing this > really hurt RFC6455 ws since deploying it usually needed extra, > different servers with the attendant difficulties interoperating with > other protocols. > One idea I had is an object called FallbackTransport, that can simulate QUIC semantics on top of WebSocket and be fully polyfillable in browsers. > I really suggest thinking through the effects of not having an RFC6455 > type subprotocol (unless I failed to spot it). It really makes an > implicit assumption about what the stream will carry that doesn't scale > beyond one server carrying one thing. That's not how things tend to pan > out if the protocol is useful. The url path could be hacked to imply > the subprotocol but if that's not standardized it's still a mess. And > the subprotocol binding may be orthogonal to the url layout complicating > things needlessly. > That's definitely an open issue with current proposal (some discussion here ). The current problem is that we basically have to choose between either transmitting the requested protocol in the open, or paying one extra RTT for the protocol selection mechanism. --000000000000f4dd45059011d867 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 22, 2019 at 5:00 PM Andy Gree= n <andy@warmcat.com> wrote:


On 7/22/19 1:36 PM, Victor Vasiliev wrote:
> Hello everyone,
>
> Today, at the dispatch working group meeting (18:10), I am going to > present WebTransport. WebTransport is a protocol framework that allows=
> multiplexed and datagram-oriented transport protocols to be used by th= e
> web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D).

"Historically, web applications that needed bidirectional data stream<= br> =C2=A0 =C2=A0 between a client and a server could rely on WebSockets [RFC64= 55], a
=C2=A0 =C2=A0 message-based protocol compatible with Web security model.=C2= =A0 However,
=C2=A0 =C2=A0 since the abstraction it provides is a single ordered stream = of
=C2=A0 =C2=A0 messages, it suffers from head-of-line blocking (HOLB), meani= ng that
=C2=A0 =C2=A0 all messages must be sent and received in order even if they = are
=C2=A0 =C2=A0 independent and some of them are no longer needed.=C2=A0 This= makes it a
=C2=A0 =C2=A0 poor fit for latency sensitive applications which rely on par= tial
=C2=A0 =C2=A0 reliability and stream independence for performance."
The HOLB isn't really entirely the case... RFC6455 ws allows arbitrary =
fragmentation of messages allowing interleaving with control frames.

It allows them to be fragmented, but the frag= ments have to be in order.=C2=A0 The multiplexing extension is mentioned as= potential future work in RFC 6455, but I don't believe it ever actuall= y materialized.
=C2=A0
ws-over-h2 allows you to can the h2 stream when you want as well.

True, though you can't use them in the same = way as pure QUIC streams because QUIC streams are created immediately, wher= eas a new WS requires a handshake.
=C2=A0

" Each new stream would require a WebSocket handshake to agree on
=C2=A0 =C2=A0 =C2=A0 =C2=A0application protocol used, meaning that it would= take at least one
=C2=A0 =C2=A0 =C2=A0 =C2=A0RTT for each new stream before the client can wr= ite to it."

Yes it was knowingly done as a hack to try to encourage uptake from
browser vendors... it's not really integrated into the encapsulating protocol.

It =3D ws-over-http2=C2=A0bei= ng a thin overlay over existing WSP?
=C2=A0
>=C2=A0 =C2=A0* WebTransport overview:
>=C2=A0 =C2=A0 =C2=A0https://tools.= ietf.org/html/draft-vvv-webtransport-overview-00
>=C2=A0 =C2=A0* QuicTransport:
>=C2=A0 =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-vvv-webtransport-quic-00
>=C2=A0 =C2=A0* Http3Transport:
>=C2=A0 =C2=A0 =C2=A0https://tools.iet= f.org/html/draft-vvv-webtransport-http3-00

There's no h2 transport implementation?

Not everything that might want to use this will get h3 capability in a
reasonable timeframe.=C2=A0 If there's more momentum behind it than RFC= 8441
there's probably room for a generic long-lived bidirectional extension =
to h2 either reusing DATA or a new frame type.

I think we might adapt an HTTP/2 transport as well (via=C2=A0draft-= kinnear-httpbis-http2-transport).
=C2=A0
It's a good idea to have it ride on other protocols.=C2=A0 Not doing th= is
really hurt RFC6455 ws since deploying it usually needed extra,
different servers with the attendant difficulties interoperating with
other protocols.

One idea I had is an o= bject called FallbackTransport, that can simulate QUIC semantics on top of = WebSocket and be fully polyfillable in browsers.
=C2=A0
I really suggest thinking through the effects of not having an RFC6455
type subprotocol (unless I failed to spot it).=C2=A0 It really makes an implicit assumption about what the stream will carry that doesn't scale=
beyond one server carrying one thing.=C2=A0 That's not how things tend = to pan
out if the protocol is useful.=C2=A0 The url path could be hacked to imply =
the subprotocol but if that's not standardized it's still a mess.= =C2=A0 And
the subprotocol binding may be orthogonal to the url layout complicating things needlessly.

That's definitel= y an open issue with current proposal (some discussion here).=C2=A0 =C2=A0The current = problem is that we basically have to choose between either transmitting the= requested protocol in the open, or paying one extra RTT for the protocol s= election mechanism.
--000000000000f4dd45059011d867-- From nobody Wed Aug 14 05:01:40 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD9B12006F; Wed, 14 Aug 2019 05:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPEzxms_9fHc; Wed, 14 Aug 2019 05:01:29 -0700 (PDT) Received: from warmcat.com (warmcat.com [46.105.127.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0088812010F; Wed, 14 Aug 2019 05:01:28 -0700 (PDT) Date: Wed, 14 Aug 2019 13:01:14 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: Victor Vasiliev CC: dispatch@ietf.org, David Schinazi , hybi@ietf.org, IETF QUIC WG , HTTP Working Group , webtransport@ietf.org From: Andy Green Message-ID: <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com> Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 12:01:31 -0000 On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev wrote: >On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: > >> >> >> On 7/22/19 1:36 PM, Victor Vasiliev wrote: >> > Hello everyone, >> > >> > Today, at the dispatch working group meeting (18:10), I am going to >> > present WebTransport=2E WebTransport is a protocol framework that >allows >> > multiplexed and datagram-oriented transport protocols to be used by >the >> > web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D)=2E >> >> "Historically, web applications that needed bidirectional data stream >> between a client and a server could rely on WebSockets [RFC6455], >a >> message-based protocol compatible with Web security model=2E=20 >However, >> since the abstraction it provides is a single ordered stream of >> messages, it suffers from head-of-line blocking (HOLB), meaning >that >> all messages must be sent and received in order even if they are >> independent and some of them are no longer needed=2E This makes it >a >> poor fit for latency sensitive applications which rely on partial >> reliability and stream independence for performance=2E" >> >> The HOLB isn't really entirely the case=2E=2E=2E RFC6455 ws allows >arbitrary >> fragmentation of messages allowing interleaving with control frames=2E >> > >It allows them to be fragmented, but the fragments have to be in order=2E >The multiplexing extension is mentioned as potential future work in RFC >6455, but I don't believe it ever actually materialized=2E Yes, you can only have one message on the go at a time; in that sense larg= e messages block it=2E But it does not block the stream completely because= you can issue control frames inbetween fragments=2E And although you may = not have control over fragment size since intermediaries can mess with it, = as the sender you do have control over message size which puts a ceiling on= both how long other messages are blocked, and the max fragment size=2E Yo= u may choose to split a large logical message into smaller ones so other me= ssage content can get a look-in=2E The mux extension stuff was a thing on hybi for a while and then the main = proponent seemed to lose interest with muxed ws vs h2=2E=2E=2E h2 was clear= ly a better result than he could have gotten from ws=2E >> ws-over-h2 allows you to can the h2 stream when you want as well=2E >> > >True, though you can't use them in the same way as pure QUIC streams >because QUIC streams are created immediately, whereas a new WS requires >a >handshake=2E Sure=2E=2E=2E for clarity I also think h1 ws if not competitive itself wit= h h2 or quic=2E But it is widely implemented and deployed, and h2 doesn't = have a native equivalent=2E So it's still kind of keeping its hand in=2E > >> >> " Each new stream would require a WebSocket handshake to agree on >> application protocol used, meaning that it would take at least >one >> RTT for each new stream before the client can write to it=2E" >> >> Yes it was knowingly done as a hack to try to encourage uptake from >> browser vendors=2E=2E=2E it's not really integrated into the encapsulat= ing >> protocol=2E >> > >It =3D ws-over-http2 being a thin overlay over existing WSP? Yeah=2E It's implemented in ffox and chrome but not turned on by default = last time I looked=2E There are few server implementations which makes it = chicken-and-egg=2E > >> > * WebTransport overview: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-overview-0= 0 >> > * QuicTransport: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-quic-00 >> > * Http3Transport: >> > https://tools=2Eietf=2Eorg/html/draft-vvv-webtransport-http3-00 >> >> There's no h2 transport implementation? >> >> Not everything that might want to use this will get h3 capability in >a >> reasonable timeframe=2E If there's more momentum behind it than >RFC8441 >> there's probably room for a generic long-lived bidirectional >extension >> to h2 either reusing DATA or a new frame type=2E >> > >I think we might adapt an HTTP/2 transport as well >(via draft-kinnear-httpbis-http2-transport)=2E Sounds good=2E >> It's a good idea to have it ride on other protocols=2E Not doing this >> really hurt RFC6455 ws since deploying it usually needed extra, >> different servers with the attendant difficulties interoperating with >> other protocols=2E >> > >One idea I had is an object called FallbackTransport, that can simulate >QUIC semantics on top of WebSocket and be fully polyfillable in >browsers=2E In this space the problem isn't really ideas but implementation buy-in=2E = RFC8441 is educational because it was well positioned politically, the rfc= certainly was exemplary for just saying what it needed to say, it solved a= real problem, got some key implementations yet has still not been able to = reach escape velocity=2E There's some psychological and architectural gap = between ws and http that is much wider than you would expect for many peopl= e (cf h2 addressed every single h1 + html 5 technology except ws -- and it = was not an accidental oversight)=2E RFC8441 went in Chrome=2E=2E=2E it hasn't been enough by itself=2E Maybe = the crossover with quic will help your thing over the hump=2E >> I really suggest thinking through the effects of not having an >RFC6455 >> type subprotocol (unless I failed to spot it)=2E It really makes an >> implicit assumption about what the stream will carry that doesn't >scale >> beyond one server carrying one thing=2E That's not how things tend to >pan >> out if the protocol is useful=2E The url path could be hacked to imply >> the subprotocol but if that's not standardized it's still a mess=2E=20 >And >> the subprotocol binding may be orthogonal to the url layout >complicating >> things needlessly=2E >> > >That's definitely an open issue with current proposal (some discussion >here >)=2E The current >problem >is that we basically have to choose between either transmitting the >requested protocol in the open, or paying one extra RTT for the >protocol >selection mechanism=2E Usually the guy who directed the client to that server does it knowing tha= t the server has the subprotocol he wants, unless something has gone wrong= =2E And it's only client -> server direction pipelining in question; the s= erver can't send anything until he's had the request and he definitively de= cided the negotiated subprotocol by then, or killed the stream=2E A client that had hot data to send could mark his preferred subprotocol as= being non-neogitiable and start issuing data immediately after the stream = open request=2E=2E=2E all being well the server allowed the stream's subpro= tocol, it lives on and takes the data, in the case it rejected the subproto= col it closes the stream and discards the data=2E The client would have to= either fail or retry without the non-neotiable part to recover if so=2E B= ut typically, he's only talking to the server because he's pretty sure it'l= l talk his subprotocol and it'll work the first time=2E -Andy From nobody Wed Aug 14 07:50:11 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FED91208F2; Wed, 14 Aug 2019 07:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdyH_uxxBXnQ; Wed, 14 Aug 2019 07:50:07 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50CE1208ED; Wed, 14 Aug 2019 07:50:06 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x18so8604503ljh.1; Wed, 14 Aug 2019 07:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=KZYHvgbOZ3GYBNqLkdf34d8WdUrMDP9JVl86xAAR3ak=; b=Q38xmbughM2PZ3f4coZNE9bNs8ODw2fjDSkJXTPfYlD6GJDwc5KukDuPBy0eXS9tP3 LEVgsiYKnJNFM8xFkjf0suY8J8gyXPJGINHMYp10RQxHhkHPnFfXS+yR37eCpeYJvz1S rBjCA8tM/h6oJWKbE6+PYhuhwloc3LTaKWTWJr77ggiDDSwaA2jvW4arAaW5f0s4dmdN 4hFj/r6FfMHMX0ReIe3kVBnMMEkU7FSmWAuaV0OPnRF7pxkLC44CG+NI48OI9a1qrLVk eBhcB4EwQu40b9bU3GVhnci5aR0iVjp8mnBhthLZbeWgCfKHObpMKFWvoQf2xa6Uc/X2 NkAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=KZYHvgbOZ3GYBNqLkdf34d8WdUrMDP9JVl86xAAR3ak=; b=QMmB8figmAA+rVXmsHrer2qc+AaBMIQIXgrCnnXf+fPl0Qytvmd9CW2P4mx31T0ufW RkHVyCl0obob94tR6KVAvJbNEybDa56V+cX8voGs/W/DNTNdKOMJw0B6actFTqdNZC5f vJpka7Gvjpuxmoy8elCcRypSiOec6+qgQN+lY83YDO0t2kX3yhFuwZU4rWJmZEV9kPs/ N6iPvvsTQwLRAcbYzONGXkw5j4wTh+Il6ZqOUC7tBBQed6My4vWYni60GVWCEN4xy03s burHE+NGV3B5BOxcn4BQEs67tTJDSYxFCRyThOXWEdYy/eELFRi5wpkaxEoWLpeKiwBO hEgQ== X-Gm-Message-State: APjAAAW/hlRUUIQWI9lNp7LqkDggxLVK5wDCqFUS+vNp42SxBb5ZSbg6 V3j4YXp0u+7ZObkQNF5WP3Ox0QJ7c4Vd//AjLkWbTrnK9Ag= X-Google-Smtp-Source: APXvYqxhub9/QKhy8mmMeCzEs+mNInGgrlGHLCbJNMAnfwLJg7HhG4p77Cp4Ur6GlYFEC2Ohc3RlbtdtTEGliXiv3dE= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr104657ljj.170.1565794204604; Wed, 14 Aug 2019 07:50:04 -0700 (PDT) MIME-Version: 1.0 From: Mary Barnes Date: Wed, 14 Aug 2019 09:49:52 -0500 Message-ID: To: DISPATCH Cc: dispatch chairs , ART ADs Content-Type: multipart/alternative; boundary="0000000000005b5b0c059014dffb" Archived-At: Subject: [dispatch] DISPATCH WG deadlines for IETF-106 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:50:10 -0000 --0000000000005b5b0c059014dffb Content-Type: text/plain; charset="UTF-8" Hi all, While IETF-106 seems a long ways out, it is less than 2 months before the IETF-106 BoF deadline. If you have a potential topic and are not sure if it might require an official BoF as opposed to a DISPATCH WG slot, please contact the ADs and DISPATCH WG chairs (aliases cc'ed above). As a reminder, these dates are always available on the DISPATCH WG wiki: https://trac.ietf.org/trac/dispatch/wiki - Oct 4, 2019. Cutoff date for IETF BoF submissions. - Oct 7, 2019. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal/topic. - Oct 14, 2019. Cutoff for proposals (i.e., problem statement and proposed deliverables) for topics posted to the DISPATCH WG mailing list. - Oct 21, 2019. Announcement of topics that have been dispatched for IETF-105. - Nov 4, 2019. Draft submission deadline. Note, that while these dates are specific to DISPATCH WG, since we share our slot with ART area, it would be helpful to know about potential ART area topics sooner rather than later, so we don't get into the situation like we did at IETF-105 and have to cutoff important ART discussions. Regards, Mary DISPATCH WG co-chair --0000000000005b5b0c059014dffb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

While IETF-106 seems a long way= s out, it is less than 2 months before the IETF-106 BoF deadline.=C2=A0 If = you have a potential topic and are not sure if it might require an official= BoF as opposed to a DISPATCH WG slot, please contact the ADs and DISPATCH = WG chairs (aliases cc'ed above).=C2=A0=C2=A0

A= s a reminder, these dates are always available on the DISPATCH WG wiki:
  • Oct 4, 2019. Cutoff date for IETF BoF submissions.
    • <= /ul>
    • Oct 7, 2019. Cuto= ff date to notify the chairs/DISPATCH WG of plans to submit a proposal/topi= c.
    • Oct 14, 2= 019. Cutoff for proposals (i.e., problem statement and proposed deliverable= s) for topics posted to the DISPATCH WG mailing list.
    • Oct 21, 2019. Announcement of top= ics that have been dispatched for IETF-105.
    • Nov 4, 2019. Draft submission deadline.
Note, that while these dates are specific to DISPATCH WG, = since we share our slot with ART area, it would be helpful to know about po= tential ART area topics sooner rather than later, so we don't get into = the situation like we did at IETF-105 and have to cutoff important ART disc= ussions.=C2=A0=C2=A0

Regards,
Mary
=
DISPATCH WG co-chair
--0000000000005b5b0c059014dffb-- From nobody Wed Aug 14 20:46:31 2019 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB99120025; Wed, 14 Aug 2019 20:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ce4UJBwL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MabGcpPC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myDKwOvRcH9c; Wed, 14 Aug 2019 20:46:25 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89A512001A; Wed, 14 Aug 2019 20:46:25 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9A29957C; Wed, 14 Aug 2019 23:46:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 14 Aug 2019 23:46:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :reply-to:content-transfer-encoding:message-id:references:to; s= fm3; bh=gK1yYyLOi8yvbQB50u7zTCrPk5vpwFH+dtsmAE+4gic=; b=ce4UJBwL lsAogFylkHpqwlTyMyBiFtdxx/zBT9p4FAq412XAUG4I1cFHZGh1Xv7qOKPidTuc 6IL8SZq2u7kP+KtPgIysa4is8jZdAjrKXrwJq07od/z+TBs0MwU24oBE4Si+7lrg l3SRFegWO0goUIhVkrTdYEWH5Fmsj/9ldsPh/j3/POfQ+kvPPrPEf48hb4CHoLxW 46JxHWHCY5euF+A8XdClipVjl91VeVXbauTlzI5mrO41hpLjqS6ZLciqyKFTdFKY 2d1qVviSuhBuWnRAyXBU5dxBc+OhF3kLytNlUKS8DXpNiIag7jha7Nxw3XzaEGeO b6tBqxxC/3nM+w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :reply-to:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=gK1yYyLOi8yvbQB50u7zTCrPk5vpw FH+dtsmAE+4gic=; b=MabGcpPCeEotv4QuMIEypU9BVBizMTIm3wcU7BB6v/zi9 CZYJ4Jw/SMUWM13aY5/gsVcTu7whdX7Ir7XttQHI7JzSaiPLYerkdR3T/SOcmBjK DJ6WBqGkWUlu8qSPQ1uYT4ZizrwjUEGjUH2yMHLX8cu4r3QmwMQEt9bxJtn48ioO sXKI+0BxxAD1Fj1VGpJeH4Wh0vrHQvvZT1zRddiQxCMmWftAqrT3OMvnfLLVolzk h8MU95/JN8l7XdOOXgy0Qfiaqf4FSTrJZkrX8LbqeYubvldjnKWQ+VL5cg83IjLd kJfjKaIelnE5mYhdv6SH3T/NY+GkA7EftB6y7/rfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeftddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffrhfgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphep udeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 12D6A380076; Wed, 14 Aug 2019 23:46:17 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mark Nottingham In-Reply-To: <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com> Date: Thu, 15 Aug 2019 13:46:13 +1000 Cc: Victor Vasiliev , hybi@ietf.org, webtransport@ietf.org, David Schinazi , DISPATCH , HTTP Working Group , IETF QUIC WG Reply-To: webtransport@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CC9DF9E-6A1C-4DD6-9CA3-92EB04AFAE2D@mnot.net> References: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com> To: Andy Green X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dispatch] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 03:46:30 -0000 Folks, Now that webtransport@ has been created, let's continue the discussion = over there, rather than cross-posting to five lists. Cheers, > On 14 Aug 2019, at 10:01 pm, Andy Green wrote: >=20 >=20 >=20 > On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev = wrote: >> On Mon, Jul 22, 2019 at 5:00 PM Andy Green wrote: >>=20 >>>=20 >>>=20 >>> On 7/22/19 1:36 PM, Victor Vasiliev wrote: >>>> Hello everyone, >>>>=20 >>>> Today, at the dispatch working group meeting (18:10), I am going to >>>> present WebTransport. WebTransport is a protocol framework that >> allows >>>> multiplexed and datagram-oriented transport protocols to be used by >> the >>>> web applications (think =E2=80=9CWebSocket for UDP=E2=80=9D). >>>=20 >>> "Historically, web applications that needed bidirectional data = stream >>> between a client and a server could rely on WebSockets [RFC6455], >> a >>> message-based protocol compatible with Web security model.=20 >> However, >>> since the abstraction it provides is a single ordered stream of >>> messages, it suffers from head-of-line blocking (HOLB), meaning >> that >>> all messages must be sent and received in order even if they are >>> independent and some of them are no longer needed. This makes it >> a >>> poor fit for latency sensitive applications which rely on partial >>> reliability and stream independence for performance." >>>=20 >>> The HOLB isn't really entirely the case... RFC6455 ws allows >> arbitrary >>> fragmentation of messages allowing interleaving with control frames. >>>=20 >>=20 >> It allows them to be fragmented, but the fragments have to be in = order. >> The multiplexing extension is mentioned as potential future work in = RFC >> 6455, but I don't believe it ever actually materialized. >=20 > Yes, you can only have one message on the go at a time; in that sense = large messages block it. But it does not block the stream completely = because you can issue control frames inbetween fragments. And although = you may not have control over fragment size since intermediaries can = mess with it, as the sender you do have control over message size which = puts a ceiling on both how long other messages are blocked, and the max = fragment size. You may choose to split a large logical message into = smaller ones so other message content can get a look-in. >=20 > The mux extension stuff was a thing on hybi for a while and then the = main proponent seemed to lose interest with muxed ws vs h2... h2 was = clearly a better result than he could have gotten from ws. >=20 >>> ws-over-h2 allows you to can the h2 stream when you want as well. >>>=20 >>=20 >> True, though you can't use them in the same way as pure QUIC streams >> because QUIC streams are created immediately, whereas a new WS = requires >> a >> handshake. >=20 > Sure... for clarity I also think h1 ws if not competitive itself with = h2 or quic. But it is widely implemented and deployed, and h2 doesn't = have a native equivalent. So it's still kind of keeping its hand in. >=20 >>=20 >>>=20 >>> " Each new stream would require a WebSocket handshake to agree on >>> application protocol used, meaning that it would take at least >> one >>> RTT for each new stream before the client can write to it." >>>=20 >>> Yes it was knowingly done as a hack to try to encourage uptake from >>> browser vendors... it's not really integrated into the encapsulating >>> protocol. >>>=20 >>=20 >> It =3D ws-over-http2 being a thin overlay over existing WSP? >=20 > Yeah. It's implemented in ffox and chrome but not turned on by = default last time I looked. There are few server implementations which = makes it chicken-and-egg. >=20 >>=20 >>>> * WebTransport overview: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 >>>> * QuicTransport: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 >>>> * Http3Transport: >>>> https://tools.ietf.org/html/draft-vvv-webtransport-http3-00 >>>=20 >>> There's no h2 transport implementation? >>>=20 >>> Not everything that might want to use this will get h3 capability in >> a >>> reasonable timeframe. If there's more momentum behind it than >> RFC8441 >>> there's probably room for a generic long-lived bidirectional >> extension >>> to h2 either reusing DATA or a new frame type. >>>=20 >>=20 >> I think we might adapt an HTTP/2 transport as well >> (via draft-kinnear-httpbis-http2-transport). >=20 > Sounds good. >=20 >>> It's a good idea to have it ride on other protocols. Not doing this >>> really hurt RFC6455 ws since deploying it usually needed extra, >>> different servers with the attendant difficulties interoperating = with >>> other protocols. >>>=20 >>=20 >> One idea I had is an object called FallbackTransport, that can = simulate >> QUIC semantics on top of WebSocket and be fully polyfillable in >> browsers. >=20 > In this space the problem isn't really ideas but implementation = buy-in. RFC8441 is educational because it was well positioned = politically, the rfc certainly was exemplary for just saying what it = needed to say, it solved a real problem, got some key implementations = yet has still not been able to reach escape velocity. There's some = psychological and architectural gap between ws and http that is much = wider than you would expect for many people (cf h2 addressed every = single h1 + html 5 technology except ws -- and it was not an accidental = oversight). >=20 > RFC8441 went in Chrome... it hasn't been enough by itself. Maybe the = crossover with quic will help your thing over the hump. >=20 >>> I really suggest thinking through the effects of not having an >> RFC6455 >>> type subprotocol (unless I failed to spot it). It really makes an >>> implicit assumption about what the stream will carry that doesn't >> scale >>> beyond one server carrying one thing. That's not how things tend to >> pan >>> out if the protocol is useful. The url path could be hacked to = imply >>> the subprotocol but if that's not standardized it's still a mess.=20 >> And >>> the subprotocol binding may be orthogonal to the url layout >> complicating >>> things needlessly. >>>=20 >>=20 >> That's definitely an open issue with current proposal (some = discussion >> here >> ). The current >> problem >> is that we basically have to choose between either transmitting the >> requested protocol in the open, or paying one extra RTT for the >> protocol >> selection mechanism. >=20 > Usually the guy who directed the client to that server does it knowing = that the server has the subprotocol he wants, unless something has gone = wrong. And it's only client -> server direction pipelining in question; = the server can't send anything until he's had the request and he = definitively decided the negotiated subprotocol by then, or killed the = stream. >=20 > A client that had hot data to send could mark his preferred = subprotocol as being non-neogitiable and start issuing data immediately = after the stream open request... all being well the server allowed the = stream's subprotocol, it lives on and takes the data, in the case it = rejected the subprotocol it closes the stream and discards the data. = The client would have to either fail or retry without the non-neotiable = part to recover if so. But typically, he's only talking to the server = because he's pretty sure it'll talk his subprotocol and it'll work the = first time. >=20 > -Andy -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 20 05:13:34 2019 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C9962120033; Tue, 20 Aug 2019 05:13:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: aamelnikov@fastmail.fm, mary.ietf.barnes@gmail.com, dispatch@ietf.org, dispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156630321276.338.13800923917127615475.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 05:13:32 -0700 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 106 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 12:13:33 -0000 A new meeting session request has just been submitted by Mary Barnes, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Mary Barnes Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: Chair Conflict: secdispatch acme cfrg extra doh core avtcore ecrit mmusic payload rmcat sipcore stir xrblock dmarc uta jmap Technology Overlap: tram tsvwg tsvarea opsarea People who must be present: Barry Leiba Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. ---------------------------------------------------------