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

Eric Kinnear <> Mon, 22 July 2019 21:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55AD31200A3 for <>; Mon, 22 Jul 2019 14:32:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.752
X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hKNGbwqkq68k for <>; Mon, 22 Jul 2019 14:32:05 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B241312001B for <>; Mon, 22 Jul 2019 14:32:05 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hpfsQ-0001Dw-TE for; Mon, 22 Jul 2019 21:29:46 +0000
Resent-Date: Mon, 22 Jul 2019 21:29:46 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hpfsO-0001DB-Ee for; Mon, 22 Jul 2019 21:29:44 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hpfsJ-0003ja-Gl for; Mon, 22 Jul 2019 21:29:43 +0000
Received: from pps.filterd ( []) by ( with SMTP id x6MLM69N062761; Mon, 22 Jul 2019 14:29:13 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=Mjp+2BlrZ2RjXqmOsoC9wmr6feKbPVzKF5onqcpmZqQ=; b=SSUjTpiePl98fdqT/fXYJCj9LCZJVpF+JZAATCtw6the8n9jJ2S7b455Rb81pAffVeZP oT6nWsN/4TWUcf+OflhbsgVbt0gCZchayfItP748m/KRgewtMxEo8jOlQgdx3ysWNLc3 qtvddUQ/QJIUr1xRGA1Zeo0chKUs5Ftn4Z9P0NeM7R1f0B+vYlNiAIWsyCD7FIts0ngl Pi5TF+xjouvrEhx/KFpLpWdydtvuuiX//ayo6ftd2K3WWIjFprPIBG1dMBFq3sdKBT8/ VngibxOhAM1RUNVlgkdYZOd+ntnXLxsxgKySV2H5sfzapk0dzb6IOwf+OfL19zLNgR/r OQ==
Received: from ( []) by with ESMTP id 2tv1xymqf4-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jul 2019 14:29:13 -0700
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <>; Mon, 22 Jul 2019 14:29:13 -0700 (PDT)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Mon, 22 Jul 2019 14:29:12 -0700 (PDT)
X-Va-T-CD: 68f2109845201c7217a51c1ddd85d479
X-Va-E-CD: 0d3c3e2cca636b8155b399dd19473f9c
X-Va-R-CD: 8aa891bccd01e26013fb581b8aa95994
X-Va-CD: 0
X-Va-ID: 4910b7c8-b14a-406b-9e46-9a1e7d5a72cc
X-V-T-CD: 68f2109845201c7217a51c1ddd85d479
X-V-E-CD: 0d3c3e2cca636b8155b399dd19473f9c
X-V-R-CD: 8aa891bccd01e26013fb581b8aa95994
X-V-CD: 0
X-V-ID: be48a199-b79c-4fa2-96ab-7383782d1cc7
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-22_15:,, signatures=0
Received: from [] (unknown []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Mon, 22 Jul 2019 14:29:12 -0700 (PDT)
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Eric Kinnear <>
In-reply-to: <>
Date: Mon, 22 Jul 2019 17:29:09 -0400
Cc: Victor Vasiliev <>,, David Schinazi <>,, IETF QUIC WG <>, HTTP Working Group <>
Content-transfer-encoding: quoted-printable
Message-id: <>
References: <> <>
To: Andy Green <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-22_15:, , signatures=0
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=0.339, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hpfsJ-0003ja-Gl 1c0ba5fd311c87920aee1802f686ee64
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
Archived-At: <>
X-Mailing-List: <> archive/latest/36819
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Jul 22, 2019, at 4:59 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 “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.
> ws-over-h2 allows you to can the h2 stream when you want as well.
> " 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.
>>  * WebTransport overview:
>>  * QuicTransport:
>>  * Http3Transport:
> 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.

Definitely agree! I know that we’ve been chatting a bit with Victor about which aims to provide this, and I think it would be worth making sure that this works nicely with WebTransport. 
-00 for that document covers effectively what you’d get with a new frame type, and -01 extends 8441 to cover more than just WebSockets with the extended CONNECT handshake.
I don’t have a particularly strong preference for the mechanism used, but rather care more about the outcome — very much agree that this is a useful component.


> 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.
> 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.
> -Andy
>>  * Web API Spec draft:
>>  * Discussion on use cases:
>> Cheers,
>>   Victor.
>> _______________________________________________
>> hybi mailing list