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

Victor Vasiliev <vasilvv@google.com> Wed, 14 August 2019 11:13 UTC

Return-Path: <vasilvv@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A611200FD for <hybi@ietfa.amsl.com>; Wed, 14 Aug 2019 04:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 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, 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, 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 2orE_9jSLZqH for <hybi@ietfa.amsl.com>; Wed, 14 Aug 2019 04:13:37 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 8E9B6120103 for <hybi@ietf.org>; Wed, 14 Aug 2019 04:13:34 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id c9so78991514lfh.4 for <hybi@ietf.org>; Wed, 14 Aug 2019 04:13:34 -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=plMKyKmvhq6C8YReyqXXO96w3a8Qc8tqEbZR8FACTLmqC263slIfKVFk5RMGQkVNWn s2ATJML15qBUOKo/GzHCLLHBc5NleL0lx9wG5Nzsuoaf3/PaBJHNz9VTwwfRjbDoRH1R d4+vAJ8Ks9fRb2bACxJ9mNRg+anSSalQfWJDbtmyJQqMwJcV9cgG9e6PTKEUr9uEkYH0 BVRlV44Pq4zx+ORphazDxR9Sh7nz12D91qVMquKsZ+U1edWKcTa/glAn+IY49Ws95Z9T W5zElthZxwufnZB5Vq8wqYLtn0JdnhmAXITCy1EZiViS8L83dBDCk70IYT+d+iMxdaUB IMLA==
X-Gm-Message-State: APjAAAXI7WUnaA8OpHYb8/KRkwc/ip4sxDHXPmNObUGkv1LHqp+lVsif ob2GPX5Tjsd7R9zoGFSd9cLYjo5YuB4C6lSizUGl5Q==
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"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/YuUM65KOD9JOm6FenuY08GIGkV0>
Subject: Re: [hybi] WebTransport Side Meeting (Tuesday, 15:20)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 11:13:39 -0000

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.