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

Victor Vasiliev <vasilvv@google.com> Wed, 14 August 2019 11:16 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 778F71200F8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 04:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Level:
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: 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 JBJF03-pn-lF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 14 Aug 2019 04:16:52 -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 A47A91200EF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 14 Aug 2019 04:16:52 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hxrE8-0000Va-Tb for ietf-http-wg-dist@listhub.w3.org; Wed, 14 Aug 2019 11:14:00 +0000
Resent-Date: Wed, 14 Aug 2019 11:14:00 +0000
Resent-Message-Id: <E1hxrE8-0000Va-Tb@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 <vasilvv@google.com>) id 1hxrE4-0000Us-PF for ietf-http-wg@listhub.w3.org; Wed, 14 Aug 2019 11:13:56 +0000
Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <vasilvv@google.com>) id 1hxrE2-00060D-Ba for ietf-http-wg@w3.org; Wed, 14 Aug 2019 11:13:56 +0000
Received: by mail-lf1-x12a.google.com with SMTP id b29so71793118lfq.1 for <ietf-http-wg@w3.org>; Wed, 14 Aug 2019 04:13:33 -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=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; d=1e100.net; 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: <CAAZdMacqbqYVs4MeoE-ahukgLzf0+nNhNip4HTGThobXhqCceQ@mail.gmail.com> <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com>
In-Reply-To: <5c631764-25e2-ce37-3f84-8eca5a8378eb@warmcat.com>
From: Victor Vasiliev <vasilvv@google.com>
Date: Wed, 14 Aug 2019 07:13:20 -0400
Message-ID: <CAAZdMaeeOrNMT40dPNaOse04haTB_LB+_94-ydbaq_DvydwgYA@mail.gmail.com>
To: Andy Green <andy@warmcat.com>
Cc: dispatch@ietf.org, David Schinazi <dschinazi@google.com>, hybi@ietf.org, IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, webtransport@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f4dd45059011d867"
Received-SPF: pass client-ip=2a00:1450:4864:20::12a; envelope-from=vasilvv@google.com; helo=mail-lf1-x12a.google.com
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: mimas.w3.org 1hxrE2-00060D-Ba b9c5c2fa1f94f6b1d2b8d9625b92cbbe
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
Archived-At: <https://www.w3.org/mid/CAAZdMaeeOrNMT40dPNaOse04haTB_LB+_94-ydbaq_DvydwgYA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36977
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>

On Mon, Jul 22, 2019 at 5:00 PM Andy Green <andy@warmcat.com>; 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
handshake.


>
> " 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:
> >     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
>
> 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
<https://github.com/WICG/web-transport/issues/26>).   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.