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

Andy Green <> Mon, 22 July 2019 21:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0101E1200A3 for <>; Mon, 22 Jul 2019 14:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JE02vpHOy5LE for <>; Mon, 22 Jul 2019 14:02:34 -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 4081712008C for <>; Mon, 22 Jul 2019 14:02:34 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hpfQA-0004C4-IB for; Mon, 22 Jul 2019 21:00:34 +0000
Resent-Date: Mon, 22 Jul 2019 21:00:34 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hpfQ7-00045h-7G for; Mon, 22 Jul 2019 21:00:31 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hpfQ5-0008I1-PC for; Mon, 22 Jul 2019 21:00:31 +0000
To: Victor Vasiliev <>,, David Schinazi <>
Cc:, IETF QUIC WG <>, HTTP Working Group <>
References: <>
From: Andy Green <>
Message-ID: <>
Date: Mon, 22 Jul 2019 13:59:57 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.9
X-W3C-Hub-Spam-Report: AWL=1.002, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hpfQ5-0008I1-PC f90c76ea557aab200cc5e5ec90840f0c
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
Archived-At: <>
X-Mailing-List: <> archive/latest/36818
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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 

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

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.


>   * Web API Spec draft:
>   * Discussion on use cases:
> Cheers,
>    Victor.
> _______________________________________________
> hybi mailing list