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

Victor Vasiliev <> Wed, 14 August 2019 11:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 778F71200F8 for <>; Wed, 14 Aug 2019 04:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Status: No, score=-10.251 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 JBJF03-pn-lF for <>; Wed, 14 Aug 2019 04:16:52 -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 A47A91200EF for <>; Wed, 14 Aug 2019 04:16:52 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hxrE8-0000Va-Tb for; Wed, 14 Aug 2019 11:14:00 +0000
Resent-Date: Wed, 14 Aug 2019 11:14:00 +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 1hxrE4-0000Us-PF for; Wed, 14 Aug 2019 11:13:56 +0000
Received: from ([2a00:1450:4864:20::12a]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hxrE2-00060D-Ba for; Wed, 14 Aug 2019 11:13:56 +0000
Received: by with SMTP id b29so71793118lfq.1 for <>; Wed, 14 Aug 2019 04:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hSwpr3GZueMRorptTd8XOsAQgdkzzbPrmojpL5s2+Qc=; b=U6n0gLNBEj1Tg57VjygYmWMc/kS8MF+7SwdqdvE2qIujGxGYlCcWoRzmxHWd8N53c7 DcXXgSswKlTRmo8kEMoNzgOwQZ0Le+QDBDJrsHgipuygIz+36vqfAs/OovOoLhJoZ+yW g2E4ZFT486uFG8MwoIQ5RCeWT3U+1yonwDs1wTy2nJPNRo3WljVP+jy7CpNHNOk+el6+ qTWZ5qK+gfGFWNtoVQjQeyRZtoZ1IIDB/7vATVPL7NZ0QOShlplJRUEFmvR6l+bT+Esr Bzl6QvFki++IfRmav53qTGvDq+uC2udDYyRjNKnI1lt2dSZyNXivztf9swuIY482szFz LD1w==
X-Gm-Message-State: APjAAAUBljm56/zoBOd1OgPQpxOpKGVJIxA1xrg7NnEFFxSrKq+eUgPl DraZxDa8i7lxP540N3lK+w32sO/0DSVRha7Z4ii55g==
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: <> <>
In-Reply-To: <>
From: Victor Vasiliev <>
Date: Wed, 14 Aug 2019 07:13:20 -0400
Message-ID: <>
To: Andy Green <>
Cc:, David Schinazi <>,, IETF QUIC WG <>, HTTP Working Group <>,
Content-Type: multipart/alternative; boundary="000000000000f4dd45059011d867"
Received-SPF: pass client-ip=2a00:1450:4864:20::12a;;
X-W3C-Hub-Spam-Status: No, score=-20.8
X-W3C-Hub-Spam-Report: AWL=3.833, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1hxrE2-00060D-Ba b9c5c2fa1f94f6b1d2b8d9625b92cbbe
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
Archived-At: <>
X-Mailing-List: <> archive/latest/36977
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> 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

> " 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?

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

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.