Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)

Mark Nottingham <mnot@mnot.net> Thu, 15 August 2019 03:46 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@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: <xms:jtVUXZM3Jrczfy-icfvXnlTyPjMRpFUyOZjrDgS-4TZbPOGsdw2t-g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeftddggeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffrhfgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgpdhmnhhothdrnhgvthenucfkphep udeggedrudefiedrudejhedrvdeknecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhoth esmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:jtVUXeDBaDMhaXkFytfdeW_Bdh8brqm9mEGkflXZcU7JRNh4t_5HMw> <xmx:jtVUXSUUtW_3Gddz1ko_4c0dMQhLmCrHOqTiooZZN2-UcC3BeKuSYQ> <xmx:jtVUXQa99-2yb-joOGDNyfI3qqoMx1G2VDn3sUFkaua4wMZ7pgPGrg> <xmx:kNVUXd5Z4t3IsZla4y3zmkoq7T7GnY_GMsHEGyZU8FSP_uIuU5-nFw>
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 <mnot@mnot.net>
In-Reply-To: <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com>
Date: Thu, 15 Aug 2019 13:46:13 +1000
Cc: Victor Vasiliev <vasilvv@google.com>, hybi@ietf.org, webtransport@ietf.org, David Schinazi <dschinazi@google.com>, DISPATCH <dispatch@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, IETF QUIC WG <quic@ietf.org>
Reply-To: webtransport@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CC9DF9E-6A1C-4DD6-9CA3-92EB04AFAE2D@mnot.net>
References: <CAAZdMacqbqYVs4MeoE-ahukgLzf0+nNhNip4HTGThobXhqCceQ@mail.gmail.com> <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com> <CAAZdMaeeOrNMT40dPNaOse04haTB_LB+_94-ydbaq_DvydwgYA@mail.gmail.com> <9BF912A7-07AF-4174-99F0-7A8F9ED2A44C@warmcat.com>
To: Andy Green <andy@warmcat.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/8NGyQY-46lGnSwY9_qpnu6FY6Yg>
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=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 <andy@warmcat.com>; wrote:
> 
> 
> 
> On August 14, 2019 12:13:20 PM GMT+01:00, Victor Vasiliev <vasilvv@google.com>; wrote:
>> On Mon, Jul 22, 2019 at 5:00 PM Andy Green <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
>> the
>>>> web applications (think “WebSocket for UDP”).
>>> 
>>> "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.
> 
> 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.
> 
> 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.
> 
>>> 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.
> 
> 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.
> 
>> 
>>> 
>>> " 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 = ws-over-http2 being a thin overlay over existing WSP?
> 
> 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.
> 
>> 
>>>>  * 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).
> 
> Sounds good.
> 
>>> 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.
> 
> 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).
> 
> RFC8441 went in Chrome... it hasn't been enough by itself.  Maybe the crossover with quic will help your thing over the hump.
> 
>>> 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
>> <https://github.com/WICG/web-transport/issues/26>).   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.
> 
> 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.
> 
> 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.
> 
> -Andy

--
Mark Nottingham   https://www.mnot.net/