Re: WebTransport Side Meeting (Tuesday, 15:20)

David Schinazi <dschinazi.ietf@gmail.com> Tue, 23 July 2019 21:38 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029B6120932 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jul 2019 14:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 TfOdFMQAbJ2s for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Jul 2019 14:38:05 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [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 ietfa.amsl.com (Postfix) with ESMTPS id E493C1202C5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Jul 2019 14:38:04 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hq2Rj-0007v7-RD for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Jul 2019 21:35:43 +0000
Resent-Date: Tue, 23 Jul 2019 21:35:43 +0000
Resent-Message-Id: <E1hq2Rj-0007v7-RD@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <dschinazi.ietf@gmail.com>) id 1hq2Rh-0007tt-OG for ietf-http-wg@listhub.w3.org; Tue, 23 Jul 2019 21:35:41 +0000
Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <dschinazi.ietf@gmail.com>) id 1hq2Rf-0002Te-Nb for ietf-http-wg@w3.org; Tue, 23 Jul 2019 21:35:41 +0000
Received: by mail-lf1-x12b.google.com with SMTP id b17so30415791lff.7 for <ietf-http-wg@w3.org>; Tue, 23 Jul 2019 14:35:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x3A94tRpsxJqiVWbazIcBPq8Ii4pxMTWmsJBEWrrTd4=; b=CTzjgFQwf4Mmc9dhgYhy1aaoOil8ZLCKDdEixgOVOHKG4nB6RSdbwwJiyibj+yaOUf +al/o7SU2kcKePlElGv3GOxVIkOw4HGcyB3wuTebEdfe6egjbCBaknkzPvBQmbdatpSw 3fPNrh3b75zYkOtuc1u1Ky8P4OgG9TKWx2Jpl70bnagB4JDpB+1swgIyTJ2YYJjSoskM ja9JlkILWSjLto8Rw6Ko7Drlt5UBv9hjrF96HaRbCPdKNVFMpQU+liMcvrCPAlbLgG0p 0ZZwIO1/bsYmiqqan5is07FgrLcJ2EmxrV/qJM3hWIr0dL+raSiuZJ76p6YJvBdLwaNi XAbA==
X-Gm-Message-State: APjAAAVQk4Z+UoSEt8HHO+OWlCfT5bI5ZaQlf4g0bfAAB62OfyE07Ic3 z9ILPkknADgyWpLaffyvVfZAe7AerzWOxoXwnT8=
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: <CAAZdMacqbqYVs4MeoE-ahukgLzf0+nNhNip4HTGThobXhqCceQ@mail.gmail.com>
In-Reply-To: <CAAZdMacqbqYVs4MeoE-ahukgLzf0+nNhNip4HTGThobXhqCceQ@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Tue, 23 Jul 2019 17:35:06 -0400
Message-ID: <CAPDSy+7mSX2queAj7SCcNeU-MX-+4qz6YZcxUZG6vgqt9OKq9A@mail.gmail.com>
To: Victor Vasiliev <vasilvv@google.com>
Cc: dispatch@ietf.org, hybi@ietf.org, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000003b8ff058e5ff839"
Received-SPF: pass client-ip=2a00:1450:4864:20::12b; envelope-from=dschinazi.ietf@gmail.com; helo=mail-lf1-x12b.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hq2Rf-0002Te-Nb 10ecf1ecdde2d404bdd572b87db1a805
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebTransport Side Meeting (Tuesday, 15:20)
Archived-At: <https://www.w3.org/mid/CAPDSy+7mSX2queAj7SCcNeU-MX-+4qz6YZcxUZG6vgqt9OKq9A@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36826
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

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
control)
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
on.
TAPS
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
WebTransport.
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
IETF.
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
formed.
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
browser.
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=
40google.com@dmarc.ietf.org>; 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:
>    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
>    - Web API Spec draft: https://wicg.github.io/web-transport/
>    - Discussion on use cases:
>    https://discourse.wicg.io/t/webtransport-proposal/3508
>
> Cheers,
>   Victor.
>