From nobody Wed Aug 14 04:13:38 2019 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350691200FB for ; Wed, 14 Aug 2019 04:13:37 -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=ham 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 VykwPi2daWdx for ; Wed, 14 Aug 2019 04:13:35 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 78BC9120100 for ; Wed, 14 Aug 2019 04:13:34 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id x3so79154110lfc.0 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=S4Ez/K4kaoxx1sUEcEuP0dUIHvZ+YN43FaNhJYBfRbtYgY8qDCDgBmlMioUzdhSc1D 3njGn+D3KuF+p0aW/LOKIeXy5p6Xpmlg73+1OL5vgrQlkt/MG/u9UmkKQdGqgbyTJBHr OKDcOpEz4zJCNgCGPw+VmDgn07kb0tiw4qNxBvWysZDJrcVtTCqu5Jb7U8oppAaGmDCZ UrnM5HNYkRKFlIQM9OkecEpxQf0MMEZ91n6I8Tro/HrTQzo12w8XKxJfeoP6Nxes+UsK VTXDE1BqQrbUt30TEIJnkE7PEEfEkjVOyrvM5U3eevRKi6b4kEkepOj6nwcDEwmFI0EH f1FQ== X-Gm-Message-State: APjAAAW7rP1qmg7+7atX+q3NYqJTqhgpWf/VZxsEhZduyB/C4ddNWPIk i8riuiOJRtR+2LBRPHRYVGau8+XxV766jxjpt8Vtzg== 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: [Webtransport] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 11:13:37 -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 06:15:15 2019 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@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: X-Mailman-Approved-At: Wed, 14 Aug 2019 06:15:14 -0700 Subject: Re: [Webtransport] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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 Thu Aug 15 07:13:18 2019 Return-Path: X-Original-To: webtransport@ietfa.amsl.com Delivered-To: webtransport@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: X-Mailman-Approved-At: Thu, 15 Aug 2019 07:13:16 -0700 Subject: Re: [Webtransport] [hybi] WebTransport Side Meeting (Tuesday, 15:20) X-BeenThere: webtransport@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: 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/