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

David Schinazi <> Tue, 23 July 2019 21:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA7C41209A4; Tue, 23 Jul 2019 14:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sh2GnKW_UmCA; Tue, 23 Jul 2019 14:35:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FDD61209A8; Tue, 23 Jul 2019 14:35:19 -0700 (PDT)
Received: by with SMTP id b29so23160277lfq.1; Tue, 23 Jul 2019 14:35:19 -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=x3A94tRpsxJqiVWbazIcBPq8Ii4pxMTWmsJBEWrrTd4=; b=IXYTAEA+gJhGti7FYN84p4MKxZRtMfP/dsMXZlG4YTz0YEEKvdmoY0VswHUs7T5OoE hPQrplt7wzCl7yTPyfckN4IKHN5pbRUZC/mAuzOPGsxaWH9veNB1GKZ5pqa8lsnxPfJN QF6EHMNfUUXJTUhdCcAnd394xhW9UMWnxkamgb9X6e3Ki2T+BDKt4KyO/MzTzfjKZv0/ eZVe/Wt+pO/s/SLEKE8uC9WNOMTXl53YlRV73RG9o6IIw6YMBnxqLQEQKsL5oOcp8pqo 7jcD8Mu9c3Eul/7QdC17fUSbHCMWdPrS/Llrw8JrlMftvOEr1fXCMLCnYD6L8WgCIVA2 NuGA==
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=x3A94tRpsxJqiVWbazIcBPq8Ii4pxMTWmsJBEWrrTd4=; b=GEr4xo8pA3w25cruHNRV5IR4VJ6IxOjujjVSsUj4Ule6mLmTrhaBssn4R7vjNz0sk9 Fy81gAGsXb9ADdlJUXQEnxuh2KmYp4njnfRi1HQXIfaE/SPToITHnMhYxLkgyZPRrCws 4hbbDiaIo69EWlmzsum3K6Rdk/lequCUpEyrvWhEc9Ti72Y1kTyV7P00MkSjNe7e9/tF iT60HqQxpa9+VEkbBYIXJ8PUXN6EWfLu9S+q/Hx2YBrA6m9V34bR4bDeVmYBTmM19BEq EJzI2ZdvB85h8Rdgo/oxdEVr7oV7E4ZFu2afJgaHZOCHBmwpduwJc5Q01bWTI8U/WDMX WgtA==
X-Gm-Message-State: APjAAAXXj+bxkj3gDQR5TDaW+6+Dni4grxCA1OZZ6uERQ9JtXeJnWwQu rMuvtII6Dj56kVg2S0JXVjfKWCeeFTytZbWYDNk=
X-Google-Smtp-Source: APXvYqzItvzfMFoYnVjcLV9pHsCmzz4yQHNV03TCNsbLMddmcQeg8frISmrbm+1KdE1a56QZSWVK8OwpJeph0b3rL74=
X-Received: by 2002:a05:6512:51c:: with SMTP id o28mr37606034lfb.67.1563917717582; Tue, 23 Jul 2019 14:35:17 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: David Schinazi <>
Date: Tue, 23 Jul 2019 17:35:06 -0400
Message-ID: <>
To: Victor Vasiliev <>
Cc:,, IETF QUIC WG <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000003b8ff058e5ff839"
Archived-At: <>
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jul 2019 21:35:33 -0000

Thanks to everyone who came to the side-meeting today. We had 27 people in
the room and strong interest in the topic.

In terms of next steps: this work will proceed in parallel at the W3C, and
we will seek to open an IETF mailing list to discuss WebTransport (we'll
report the list here when it exists).

Thanks in particular to Steve Anton for recording the following minutes:

Roberto Peon: best to share connection even for data with different
congestion controllers
Seth Blank: many games open many TCP connections for reliable data, in
addition to UDP
Seth: others will layer a reliable layer on top of UDP
Jana Iyengar: having all types of data under the same cc is very useful,
but needs a way to prioritize traffic. Another issue with existing
approaches: some connections (if multiple TCP/UDP/etc) may fail which is
awkward (e.g., TCP may work but UDP not).
Is connection setup latency important?
Yes, RTC use cases find call setup very important
QUIC should help a lot here
Use case: for legacy apps, map UDP sockets to QUIC datagrams, TCP sockets
to QUIC streams
Brian Trammell: but these legacy apps want to interop with things that
speak TCP and UDP, not QUIC
Solution: host a shim proxy
Roberto: a L7 proxy wants very low level APIs to forward data avoid
compounding delays.
Partial reliability models
Jana: agree that datagrams are too low level for from-scratch applications.
SCTP made this mistake. What is the API for sending application-sized
messages? (streams?)
Roberto: QUIC is missing the concept of “session” (bundling streams
together to the same endpoint). Use case: L7 proxies that route at the
session level.
Roberto: protocol needs to know about framing and ordering (for flow
Martin Thomson: don’t invent partial reliability here, or else it could be
the hill to die on.
Victor Vasiliev: want to just expose APIs for QUIC primitives that are
already defined (imagine streams are a useful abstraction, datagrams are
the most minimal abstraction)
Target application: real-time client-server streaming
Not going to solve this in WebTransport, instead offer primitives to build
Brian: Underlying transport depends on application and deployment. Will
likely need a transport selection algorithm.
Victor: want to do transport selection as a higher level layer, not in
Victor: some of the data API will use Web primitives (like WHATWG Streams).
Don’t want to over abstract.
Brian: take a close look at the TAPS architecture document.
QuicTransport vs. Http3Transport
Roberto: things we implement in HTTP: redirection, shut down state,
caching, multiplexing. These are very valuable, let’s not forget.
Important to ship an API which performs and is what people want to use.
Eric Kinnear: HTTP has a few downsides, e.g. bidirectionality. There’s a
use case for just a QUIC transport.
Peter Thatcher: HTTP doesn’t make sense for P2P.
Martin: How does this spec handle fallback if e.g. QUIC can’t connect?
There should be a transparent fallback.
Victor: WebSocket fallback (can even implement as a polyfill).
Jana: may need to break down spec into pieces before bringing it into the
Victor: wire format changes are clearly IETF. API design is clearly W3C.
Framework definition could go either way, not sure which venue right now.
Martin: kind of weird but seems to work to have the same people wear IETF
and W3C hats
David Schinazi: seems to be interest: in terms of process, should a new
IETF mailing list be formed?
Martin: get an AD to form a mailing list. IETF should do work for W3C, not
the other way around.
Roberto: implementations of WebTransport could be useful without it
necessarily being a Web API.
Mark Nottingham/Martin/Peter: W3C work is in WICG right now. Needs to be a
working group before IETF would form a working group.
Can still make a mailing list, have a BOF before the working group was
Jana: Other way of doing it: W3C driving requirements for IETF protocol,
creates API.
Roberto: some use cases for L7 proxies even if this doesn’t end up in the
Jana: Is the RTCDataChannel a first application for WebTransport?
Harald Alvestrand: desire in WebRTC to redesign the RTCDataChannel API.
Roberto: a major application that wants this is low latency broadcast video.
Bandwidth prediction APIs
Roberto: value for this, very complicated though. Today the server which
has lower level control can send the browser cc info.
Harald: started with receiver cc, went back to sender cc later
Brian: should take this out of scope for a BOF
Roberto: defer this or else it will fail (e.g., HTTP2 started without QUIC
even though they knew QUIC was needed).
Jana: don’t bring bandwidth prediction up or else it will be front and
center and kill the effort

On Mon, Jul 22, 2019 at 4:36 PM Victor Vasiliev <vasilvv=> 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”).
> Since it’s quite likely we will run out of time during dispatch, I
> scheduled a side-meeting to discuss this in more depth. Below are the side
> meeting details.
> *Time:* Tuesday, 15:20 ~ 16:50
> *Place:* Room C2 (21st floor)
> *Organizers:* Victor Vasiliev, David Schinazi
> *Agenda:*
>    1. A more in-depth overview of WebTransport.
>    2. Discussion of the overall design and the use cases.
>    3. As time permits, some of the major outstanding design issues in Web
>    transport, e.g.:
>       - What fallback protocol to use?
>       - How to multiplex streams and datagrams within a single connection?
>       - Can we let web applications do their own congestion control?
>       - Should WebTransport sessions have URLs associated with them?
> As usual, here are some helpful links:
>    - WebTransport overview:
>    - QuicTransport:
>    - Http3Transport:
>    - Web API Spec draft:
>    - Discussion on use cases:
> Cheers,
>   Victor.