Re: [Webtransport] Measuring the friction of Http3Transport

David Schinazi <dschinazi.ietf@gmail.com> Mon, 16 November 2020 21:00 UTC

Return-Path: <dschinazi.ietf@gmail.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 BF1373A143B for <webtransport@ietfa.amsl.com>; Mon, 16 Nov 2020 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 aT6rZ-yPW8QY for <webtransport@ietfa.amsl.com>; Mon, 16 Nov 2020 13:00:30 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C18AF3A1439 for <webtransport@ietf.org>; Mon, 16 Nov 2020 13:00:29 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id b17so21693070ljf.12 for <webtransport@ietf.org>; Mon, 16 Nov 2020 13:00:29 -0800 (PST)
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=ILSlM2ka85uDajYJZUFP4xcxUwPTVI3eld+aMkQg3QI=; b=HJZDFpe6xL896EpD4axs5RgDN+maOW3Y/suK1XOvUmxIM36vweVx+yy7WCt2snNZ1D KkIjJxYYkrSarh3od2gXA/qGtgAFKZ2beh9ApHAcZC6ffvT/JVci2WUeys/kKIlkGuNe z71e9mY9RL2LmijK622hXscZrf28+n03tk8mJ4/LqPQ0Lr+VDWgsXN4sKWdd7DTxsGjl JbWpp8xXBy+PpSlrsdrYrelXuz/VArY/BbcWSRv60Wg2RyV0taAkSOD7d7q7rSDzlTW0 cZIj4fZEJpSb4b1rF3vvKyeu6K2xdY2sZUqkS+0vTK2G2zShddrYukFYuMGsVVKzuDiw w6Ug==
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=ILSlM2ka85uDajYJZUFP4xcxUwPTVI3eld+aMkQg3QI=; b=UKD7K9yp4YrdXRU4dc4/hhnPIf+4YcjKQTG1k3x8Mh6bOSsNYFOkItNNxjDluGOTgx unKCXBxsyGGx+qjUpncGrOWrLUm24byCWbvPSEUvIn5bNk90IHBxr62tNbJXxG51D+2o kGWzFIRalt1P6rAXrwGSSjpkAyqYqttAUwGBprt53LcDHPlRhFCIU90zkQgkjQwagQ23 oY+TCNOkKVU4h6uWUsJ9ljepP+adCtrtCRjnIW6d0Qv2zywPzkw6SptFgl9RByHdsakF rislYXvHL5ftM+VJ+sEqUZnYFoAMcPunGJ5ndNz8bRil+mfWcxP9ivnJKsyCNpzd+Eii zmQg==
X-Gm-Message-State: AOAM533LEwcBgOCqnxYZpvg/cp5cEkxA94WzllwH1SD7VSt0xhjCSntH oP+tsveY/ehLzIrz/8zWMgnf7vETUrwLhyFlcqQ=
X-Google-Smtp-Source: ABdhPJyuTpar/a/K4KdfOQUCmBiC35WJFyYb0GacOzxbd+m2kuXVYubcmzzhXIKTbWvn1GaipFdju9qxNo+Bk8uRJaY=
X-Received: by 2002:a05:651c:319:: with SMTP id a25mr477487ljp.333.1605560427664; Mon, 16 Nov 2020 13:00:27 -0800 (PST)
MIME-Version: 1.0
References: <CALGR9oZo3rPeSund3Te6NgEhfBq5yCYmvdFFtTZqkoZ_Js9AMw@mail.gmail.com> <CAHVo=Zk-1J55MMqRPGFc86k3ncHq9rdw1Qty_CtE4-ezi=C54A@mail.gmail.com> <CALGR9ob-0DNqnJA4OHQinATuzCn+mN8K7dfGHK+FQia99GGDsQ@mail.gmail.com> <CAHVo=ZnC0o8XGT-jJ6U6oMEd9AJyx00o1wu7HfG5RZTLhdn=2g@mail.gmail.com> <CAPDSy+4NRvMYUeS2qSkuDCHWic=MkrJFL8_e252z=8KvQ+C5Gw@mail.gmail.com> <CAOW+2dsd72duTsHUcimYddi_JFOWQ0k9b5E7JWDeX_AOy5Uw5A@mail.gmail.com>
In-Reply-To: <CAOW+2dsd72duTsHUcimYddi_JFOWQ0k9b5E7JWDeX_AOy5Uw5A@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 16 Nov 2020 13:00:16 -0800
Message-ID: <CAPDSy+7-enTafBePpjLKdq-j6WVo3=bC1EXOZ1s-c4verraRFQ@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
Cc: Luke Curley <kixelated@gmail.com>, WebTransport <webtransport@ietf.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f4dbb205b43faa31"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/hqp1-SR8v2tVRbzZAkONXF-qaFc>
Subject: Re: [Webtransport] Measuring the friction of Http3Transport
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, 16 Nov 2020 21:00:32 -0000

On Mon, Nov 16, 2020 at 12:40 PM Bernard Aboba <bernard.aboba@gmail.com>
wrote:

> Luke said:
>
> "My primary concern is that Http3Transport requires non-generic
> modifications to the HTTP/3 layer mostly to support connection pooling. I'm
> worried that this will limit support for Http3Transport and complicates any
> HTTP/3 implementation that does support it."
>
> [BA] I have also heard this concern from developers. The concerns
> primarily arise from the pooling of HTTP/3 Request/Responses with
> WebTransport. This does enable some interesting use cases, such as a
> Request/Response (e.g. gRPC) that can result in a server sending datagrams
> or initiating bi-directional or uni-directional streams.  So there is
> perceived value, but the question is whether that value will be widely
> supported across the HTTP/3 ecosystem.
>
> At this point, most generic HTTP/3 servers are not expected to support
> HTTP/3 datagrams (not part of the HTTP/3 protocol) or Http3Transport
> (perceived as a niche protocol), so that pooling would only be possible
> when using a framework.  node.js will not have QUIC support for 12-18
> months (held up by OpenSSL) so even framework support is expected to be
> limited.
>

Where does this come from? A lot of QUIC servers are implementing QUIC
datagrams, and once you have those the delta with h3 datagrams is
negligible. Additionally, multiple h3 server implementers have indicated
they want to support WebTransport. It's starting to feel like the pushback
on HTTP3Transport is purely based on a perception of complexity from folks
who haven't tried to implement it? If that's the case, then we should get
some implementation experience to confirm or debunk that theory.


> On Mon, Nov 16, 2020 at 11:37 AM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
>>
>>
>> On Mon, Nov 16, 2020 at 11:34 AM Luke Curley <kixelated@gmail.com> wrote:
>>
>>> We're on the same page that there's code in HTTP/3 that could be
>>> leveraged for QuicTransport in the form of the header parsing. I think
>>> there's a path to merge QuicTransport and Http3Transport by leveraging
>>> HTTP/3 for the handshake and QUIC for stream delivery.
>>>
>>> My primary concern is that Http3Transport requires non-generic
>>> modifications to the HTTP/3 layer mostly to support connection pooling. I'm
>>> worried that this will limit support for Http3Transport and complicates any
>>> HTTP/3 implementation that does support it.
>>>
>>
>> Hi Luke,
>>
>> I'm curious, could you elaborate on what these "non-generic modifications
>> to the HTTP/3 layer" are please?
>>
>> Thanks,
>> David
>>
>>
>>> On Mon, Nov 16, 2020 at 4:49 AM Lucas Pardue <lucaspardue.24.7@gmail.com>
>>> wrote:
>>>
>>>> Hi Luke,
>>>>
>>>> On Mon, 16 Nov 2020, 12:26 Luke Curley, <kixelated@gmail.com> wrote:
>>>>
>>>>> Just to clarify, when I say "QuicTransport is simpler" I really mean
>>>>> "QuicTransport has greater interoperability". You can take any QUIC
>>>>> implementation (+ datagram extension) and add a thin layer to support
>>>>> QuicTransport. It's a nice layering of protocols and it's something that I
>>>>> want to see in general as QUIC replaces TCP.
>>>>>
>>>>
>>>> Thanks for the clarification. I appreciate the sentiment. But given the
>>>> development of QUIC its kind of surprising that people would find it easier
>>>> to identify an implementation that supports QUIC and datagram but does not
>>>> support HTTP/3.
>>>>
>>>> Thr situation for a more clean-room implementation is different, I
>>>> agree. However, by the time you've done all the hard stuff with QUIC, a
>>>> very focused HTTP/3 layer ends up quite thin too. You can ignore dynamic
>>>> compression, server push and extensibility points.
>>>>
>>>> I also see the current design being the thin end of the wedge. The
>>>> proposal I linked talks about HTTP-like header parsing. So its "just" a
>>>> thin layer to do some parsing. Then folks will probably want some want to
>>>> tweak parameter, acontrol channel, a way to do graceful close, a sprinkle
>>>> of GREASE. To extrapolate forward, what would be the delta be between some
>>>> final product QuicTransport and HTTP/3. Too small a delta and we've wasted
>>>> years of effort.
>>>>
>>>> Cheers
>>>> Lucas
>>>>
>>>>
>>>>
>>>>> On Mon, Nov 16, 2020 at 3:16 AM Lucas Pardue <
>>>>> lucaspardue.24.7@gmail.com> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> To follow up on one thread of discussion during IETF 109. To over
>>>>>> simplify what we've heard a few folks say, they prefer QuicTransport
>>>>>> because it simpler and they don't need pooling.
>>>>>>
>>>>>> I'd like to push more on this, what is the measurable complexity of
>>>>>> HTTP/3 over QUIC plus a new application mapping that needs to be defined?
>>>>>> Let's isolate pooling as a variable and ignore it.
>>>>>>
>>>>>> Victor mentioned his proposal for a unified header semantic across
>>>>>> all transports, this is
>>>>>> https://github.com/ietf-wg-webtrans/draft-ietf-webtrans-overview/pull/4/files.
>>>>>> Taking a closer look at it, I have some concerns that I added as comments.
>>>>>> HTTP has semantics for a reason. If QuicTransport is going to start
>>>>>> borrowing HTTP piecemeal, I really wonder how simple people might feel it
>>>>>> is. I think it's important to avoid something that looks like HTTP but
>>>>>> behaves differently. Is it really much of a stretch to just do HTTP/3 but
>>>>>> give it a different ALPN so that we avoid problems related to
>>>>>> cross-protocol pooling?
>>>>>>
>>>>>> Cheers,
>>>>>> Lucas
>>>>>> --
>>>>>> Webtransport mailing list
>>>>>> Webtransport@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>>>>
>>>>> --
>>> Webtransport mailing list
>>> Webtransport@ietf.org
>>> https://www.ietf.org/mailman/listinfo/webtransport
>>>
>> --
>> Webtransport mailing list
>> Webtransport@ietf.org
>> https://www.ietf.org/mailman/listinfo/webtransport
>>
>