Re: [Webtransport] Choosing the Transport

Yutaka Hirano <yhirano@google.com> Mon, 27 July 2020 07:58 UTC

Return-Path: <yhirano@google.com>
X-Original-To: webtransport@ietfa.amsl.com
Delivered-To: webtransport@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597E3A1790 for <webtransport@ietfa.amsl.com>; Mon, 27 Jul 2020 00:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 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, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 MUvrGitTeUa8 for <webtransport@ietfa.amsl.com>; Mon, 27 Jul 2020 00:58:06 -0700 (PDT)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB70C3A178C for <webtransport@ietf.org>; Mon, 27 Jul 2020 00:58:05 -0700 (PDT)
Received: by mail-lj1-x233.google.com with SMTP id g6so3545301ljn.11 for <webtransport@ietf.org>; Mon, 27 Jul 2020 00:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cCBsoUI3dnSAqfBMfGg9CNCNIc380+fPzT0kQ2pLUtE=; b=mmpUol2MXXeoFz/MB15iS8Kld43fdbnU/KEkfnyaKgNnLriM4in3BzAjoySZYo7CJg /SuisYwXPvRsjsEkQiptxbKZ2VdGOK0Uftjmj0k5euazw6yAFKHEPjd9jqOACukw1JVu EY9nQVY6QIzWjiP6hgfLv+LBUe0/BstLsSmGDbDkqc+IWHJ1n/4l/oYId+ZpcQNybybP XPZoGIdHwO8qg+4nneW/mbFPOX6Lxy1kBfUvW0uNNJcuL0OwqbCAKGzkI0udpjjItOI7 5/w9LbVs/tNkf7tSjaiY10cmnHXKM93DF40T5Nns/bcZlTHGyrQMcj2v4gzJNn1Fox7V VPpg==
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=cCBsoUI3dnSAqfBMfGg9CNCNIc380+fPzT0kQ2pLUtE=; b=N8HBIqWqWtZ3gBwupvPmdBhcxWBi2m45HZUKGBeST0as0ga+1+KAeXDX1/Qw04cVYA /fNl5zszJ9pZkvbWXIT3FXDpt3YRG1MNMaCw9v/Hnp+nTV13I3rPxd9G0wZNjZLFTeCE t05Ulx9h4vVVMhXZx2eOZaVXCFEsErOixurKzUKRmADPczUqXy7fiRuRQ9e6U13fZQrM d2BGu2VjoTjqt5lIsV6s1qgO5N13lEnE4nf7VrH82iFjRnC+RVb1h/SRBmeqisdJQKVi IdHkkTwulLnFDOZgZFyN0BDJI83pWm2rgxxRYnchADjeCUt+H2zUlkcB077vSIbOy4Vw 7ecg==
X-Gm-Message-State: AOAM533O1VVkRGA6il3BXqkhECd0BFGkzYzpca/VdoOgt38qbSB6UFTC JQ8CVLRH6VxpGFUw8FBIYYqO9yShBaQpm/lNgVpZTSxBGTvnWA==
X-Google-Smtp-Source: ABdhPJyocgYQDORXCiX9iALYyqaMVWIqQANyeGm7iFw4pJe82mpO2/+8HfgTHy93L7V4wqe5pmyn4Lvkiy0Z+FrKAqs=
X-Received: by 2002:a2e:9e89:: with SMTP id f9mr8721684ljk.212.1595836683592; Mon, 27 Jul 2020 00:58:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAAZdMafWeaZhCVbObPgvYm5gxZu6ksV5VkSoF=8Mx9OJBDA5rA@mail.gmail.com>
In-Reply-To: <CAAZdMafWeaZhCVbObPgvYm5gxZu6ksV5VkSoF=8Mx9OJBDA5rA@mail.gmail.com>
From: Yutaka Hirano <yhirano@google.com>
Date: Mon, 27 Jul 2020 16:57:50 +0900
Message-ID: <CABihn6GEewr2KjLYK0hG7oa1Z9cyiOyQd9PX6GxuXA+Lu06XeA@mail.gmail.com>
To: Victor Vasiliev <vasilvv=40google.com@dmarc.ietf.org>
Cc: WebTransport <webtransport@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a59c8005ab67ae45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/B_debBoiwxNpPbUPKR5UbAKEZ4k>
Subject: Re: [Webtransport] Choosing the Transport
X-BeenThere: webtransport@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <webtransport.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webtransport>, <mailto:webtransport-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webtransport/>
List-Post: <mailto:webtransport@ietf.org>
List-Help: <mailto:webtransport-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webtransport>, <mailto:webtransport-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 07:58:10 -0000

> If we decide that QuicTransport is a way to go, we’d have to add more
features into its handshake, since I suspect most people won’t be happy
with what’s in there right now (HTTP headers like Location or Forwarded
would be a good example of what people would end up needing in practice,
together with an ability to tag along arbitrary key-value metadata for
debugging purposes).  If we decide that HttpTransport is a way to go, we
would have to ensure that the result is easy for Web developers to use, and
that we understand the differences between it and regular HTTP.

Is this for web developers or non-web users?
WebSocket uses the Upgrade mechanism and uses HTTP headers, but doesn't
expose most of the information. For example, we don't expose the HTTP
status code to web developers. The only information it exposes to web
developers is
 - whether the connection is established
 - protocol (sec-websocket-protocol)
 - extensions (sec-websocket-extensions)
.

I'm a bit concerned about confusion we would see with having yet another
HTTP-like protocol. To what extent it is similar to HTTP is difficult, and
people would have diverse expectations I think, given the experience in
WebSocket.

On Thu, Jul 23, 2020 at 6:23 AM Victor Vasiliev <vasilvv=
40google.com@dmarc.ietf.org> wrote:

> Hello everyone,
>
> We recently adopted the overview draft
> <https://tools.ietf.org/html/draft-ietf-webtrans-overview-00> that
> describes the general requirements for and the model of WebTransport.
> However, we haven't yet adopted any specific wire protocol proposals.
> There are currently three of those presented to the working group:
>
>    - QuicTransport
>    <https://tools.ietf.org/html/draft-vvv-webtransport-quic-02>
>    - Http2Transport
>    <https://tools.ietf.org/html/draft-kinnear-webtransport-http2-01>
>    - Http3Transport
>    <https://tools.ietf.org/html/draft-vvv-webtransport-http3-02>
>    - [hypothetical WebTransport over WebSocket]
>
> Back when the original idea of WebTransport was forming, the hope was to
> implement and ship all four of those, since they all fit different use
> cases better.  After talking more to the people at IETF, it sounds like
> four transports is a bit too much, and we should settle on two (one over
> QUIC, and one over TCP).  The natural picks would be either Http3Transport
> with Http2Transport as fallback (HttpTransport for short), or QuicTransport
> with… *something* as a fallback.  Let’s look at the differences between
> those two options.
>
> *Differences*
>
> The most substantial wire format difference between those two proposals is
> the handshake.  QuicTransport originally did not have any handshake; we had
> to add a bespoke handshake later in order to implement the Origin header,
> and we also added a Path header later on.  We currently don’t have any form
> of response headers, so if the server is unhappy with the origin or path
> received, it has to close the connection with CONNECTION_CLOSE..  In
> HttpTransport, we have regular HTTP header fields for both request and
> response, meaning that the server can do things like return a 4xx/5xx for
> an error.
>
> During the connection itself, the difference is minimal: QuicTransport
> uses streams and datagrams as-is, while Http3Transport prefixes everything
> with an ID, since it is multiplexed with other HTTP traffic.  There might
> be a question of whether prefixing can impose undesirable framing overhead;
> I think if that ever becomes a serious problem, we can come up with some
> extension to work this around.
>
> If we decide that QuicTransport is a way to go, we’d have to add more
> features into its handshake, since I suspect most people won’t be happy
> with what’s in there right now (HTTP headers like Location or Forwarded
> would be a good example of what people would end up needing in practice,
> together with an ability to tag along arbitrary key-value metadata for
> debugging purposes).  If we decide that HttpTransport is a way to go, we
> would have to ensure that the result is easy for Web developers to use, and
> that we understand the differences between it and regular HTTP.
>
> From the server complexity standpoint, I am not particularly worried about
> either.  We’ve implemented QuicTransport in Chrome, and I wrote two servers
> for it, in C++ and in Python; the Python one took about 100 lines of code.
> Http2Transport has been implemented, in somewhat different forms, by both
> Apple and Facebook, so we have practical experience with it too..  I was
> previously concerned that having to implement HPACK/QPACK would be a burden
> to the Web developers since those are more complex than what you’d
> typically find in a WebSocket implementation, but now that we have a
> draft to turn compression off
> <https://tools.ietf.org/html/draft-vvv-httpbis-alps-00>, I’m less worried
> about this.
>
> There is a question of how much of the HTTP ecosystem we would be actually
> getting by adopting HTTP.  It is true that basing WebTransport on HTTP does
> not mean HTTP middleware would automatically implement it.  That said, we
> do get a lot of useful features from HTTP, notably message routing and a
> well-understood metadata format.  Everyone knows what a code 200 or 404 is,
> and a lot of people have built their internal debugging/tracing tools based
> on adding HTTP headers to things, and being able to easily port those to
> WebTransport would be an asset.  I’ve seen some arguments that content
> negotiation and caching might be applicable to certain classes of
> WebTransport resources too (e.g. a live stream can be cached in the sense
> that requesting a live stream is joining it), though those kinds of cases
> would have to be content-specific and they do not generalize as nicely as
> caching for regular HTTP resources.  An interesting point to note is that
> WebTransport is always included programmatically (as opposed to being
> navigated to or sourced via URL from HTML), thus alleviating the need for a
> lot of otherwise useful HTTP headers.
>
> *Questions*
>
> While on the surface the question here is “which drafts should we adopt?”,
> I would like to break this question down into two layers:
>
>    1. Do we want to use the wire format in which we try to build
>    minimally on top of QUIC (QuicTransport), or do we base it on HTTP?
>    2. To what extent WebTransport connections act like HTTP connections?
>    Do they have https URLs or a dedicated schema?  Which HTTP headers do and
>    don’t work?
>
>
> Regarding the first issue, I am increasingly leaning towards keeping only
> the HTTP-based option. QuicTransport’s most appealing feature is its
> simplicity; however, ever since we’ve had to add a header to communicate
> the Web origin, there has been increasingly more and more reasons to add
> new features to it, so even if we go that way, we’re probably going to end
> up with something that’s a lot like HTTP.  Also, we know exactly how to do
> TCP fallback in this case, so this removes a lot of design problems from
> consideration.  Fixing complexity and other problems with HTTP is probably
> more viable.
>
> Regarding the second issue, I am not sure how much of it is in scope for
> this working group.  While we do need to define a URL schema, and the
> choice of schema will give us a lot of answer (by making WebTransport same
> or different origin as HTTP), a lot of those questions have been
> traditionally answered somewhere in Fetch spec, or simply not addressed in
> the standards at all.  I am not quite sure what to do with those.
>
> What do people think?
> --
> Webtransport mailing list
> Webtransport@ietf.org
> https://www.ietf.org/mailman/listinfo/webtransport
>