Re: [Webtransport] Confirming consensus calls from today's WebTransport interim

Martin Thomson <mt@lowentropy.net> Mon, 24 May 2021 01:48 UTC

Return-Path: <mt@lowentropy.net>
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 43A9E3A1034 for <webtransport@ietfa.amsl.com>; Sun, 23 May 2021 18:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=lowentropy.net header.b=HK+y+qcQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jru/MCNu
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 1mhPCKUo8-By for <webtransport@ietfa.amsl.com>; Sun, 23 May 2021 18:48:09 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B8E3A102C for <webtransport@ietf.org>; Sun, 23 May 2021 18:48:08 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0A19C5C00B0; Sun, 23 May 2021 21:48:04 -0400 (EDT)
Received: from imap10 ([10.202.2.60]) by compute4.internal (MEProxy); Sun, 23 May 2021 21:48:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=8uA9X5lRIKbhXXlozEZEBdPT6hH7 xKYsJwvioFIyyB4=; b=HK+y+qcQafxby+YqlXGKFvXwHtHDQAW2gRftJlQ1eZd8 nHmDXKYsIa76kBDzRFTFoINf1ynftL8Xg1xlE8d+H115i0KMMxKcpBk7qchEIDLc FYPHRVLPovfmyGqF/RTe9BKh1tvPK1VYnKTxvvfKfw5RiUkrs8nV7pNY7ib5Fox5 X6ex5XERo6xszAxCmlzVoZ99WfS77M3c3LORO/uIQbnajrueIzy2P4uRHIS2oBf+ hoTu5FUL2AFRLm0YJB4biBiWb7B2+Rhec8xZcvVcixx+CflXUFu5mKQBGcXcpuIK FLbF7IEF30OHxgqvK5x74GjFulV050kLkUErwqKfQA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8uA9X5 lRIKbhXXlozEZEBdPT6hH7xKYsJwvioFIyyB4=; b=jru/MCNuQUcZNsyGTqKkvE nd4PIPpfd4Vs3zkyBZhEqfVnatWU35MPMPVXeKCN6+dysFbODW1/IA3et094KHhp Xw4IVYSF5vWnxw+yp8qFw1zX4ufFQGHdDiJA4Ual9asTqPAnjjooFAR2qlASrML6 KQJsOhKKrLM9hQVpewtsyBgo025ejB8u00ZZK0z5d/GalPI+B7tBfrpudeoBe+fz OCDCBA1hKjVam+1HQLsfnVIXLuCmM2Q6sFuJWqRM4GnD6veljEWFb5CF9FpJ8y6Y 0GXIhUa+PYWzdk8P/ZcFJAcUJacPL6yscDhgb3/w0Wmu8x+McdNC3vSMF05y6rYQ ==
X-ME-Sender: <xms:0wWrYA5OKKOtVbLe6SObyCYdLC2mKugbdCrD9bzpCD3kMNBtPzSaow> <xme:0wWrYB7sJw_nYt-rp5rr-6CChpyWM4MjLTd3Za1kyEozm9fbZaUjnejsG9XS8T-Bz qIC2cIb-M0-40Ho9IQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejkedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepgedufeeiuefhkeffheefleekteevtdehfffhjeehjeekgeejueff hfehjeehieehnecuffhomhgrihhnpehhthhtphdvughovghsnhhtmhgrkhgvshgvnhhsvg hunhhlvghsshhthhgvtghhrghnghgvshgrrhgvmhhinhhimhgrlhdrihhmnecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnth hrohhphidrnhgvth
X-ME-Proxy: <xmx:0wWrYPfUKvlS_6JBqbSrvIbpeqCBxFRRSITE_7LZExNNoMbav0j17A> <xmx:0wWrYFIDKl1Ato5tPQtU959ADg_MzwGqHLRsn0s7SWFR3faiExy7Uw> <xmx:0wWrYELautEcVxJZYrCz7fFV4Lzg8V6cMov8fHeS8cRQbxdLg39wXA> <xmx:1AWrYLlE5vFGbfQko5W2Uuoxi-J53iKJtv1PU_YxMsT0NlO3XgysfA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7309F4E0091; Sun, 23 May 2021 21:48:03 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-Id: <69e2d8c9-b532-4ce3-b558-9fdd11e5fb1a@www.fastmail.com>
In-Reply-To: <CAAZdMad9hZMutYAWQOO=T+UtV9tuMreHy707JO6qN40k2SVmMQ@mail.gmail.com>
References: <CAPDSy+5s-D7v3jxFmWKD5N-=sVcM_v8ZmB1iVNjZ1ZuHN5n=OQ@mail.gmail.com> <cce29e58-da55-4cc1-b760-4ee1c849c035@www.fastmail.com> <CAAZdMad9hZMutYAWQOO=T+UtV9tuMreHy707JO6qN40k2SVmMQ@mail.gmail.com>
Date: Mon, 24 May 2021 11:47:42 +1000
From: Martin Thomson <mt@lowentropy.net>
To: Victor Vasiliev <vasilvv@google.com>
Cc: WebTransport <webtransport@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/webtransport/dNLzE_y9gLVCPzgXrZqCee3jlcM>
Subject: Re: [Webtransport] Confirming consensus calls from today's WebTransport interim
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, 24 May 2021 01:48:15 -0000

On Sat, May 22, 2021, at 02:06, Victor Vasiliev wrote:
> On Thu, May 20, 2021 at 9:37 PM Martin Thomson <mt@lowentropy.net> wrote:
> > I'm opposed to adoption of this document.  I don't believe that it can be made so due to some fundamental differences in how HTTP/2 and QUIC stream states.
> > 
> > If this problem was acknowledged, then I have every confidence that the people listed as authors are able to find a solution.  But generally adoption is about the document more than the people.  Adoption means agreeing that the document contains approximately the right shape for a solution.  I can't agree with that in this case.
> 
> Hi Martin,
> 
> Could you elaborate on the specific differences between HTTP/2 and QUIC 
> stream state machines that you are concerned about?  The only one I am 
> aware of is unidirectional versus bidirectional reset, and last time we 
> discussed this, the easiest solution was to make HTTP/3 behave like 
> HTTP/2, which would mean there's nothing HTTP/2 draft would do to 
> address that.

That's the one I'm most concerned about, but there is also the whole mess around inventing semantics for unidirectional streams that needs to be worked into the state machines.

For reset, sure, you could make the HTTP/3 draft worse to deal with the problem.  Why would you want that?  QUIC has a much better set of semantics here than HTTP/2.

There is also the stream state management disconnect for server-initiated streams, which currently is only used for server push.  The draft currently doesn't say anywhere near as much as it would need to in order to specify that part.

And managing allocation of stream limits is a little scant on detail in the same way.  I thought we wanted independent limits, which means defining new accounting systems.  (Yes, this is a criticism of the HTTP/3 draft also, but the additional effort required to use QUIC streams is entirely justified in that case, because you are getting something in exchange.)

Why bother with all of that when you can just import QUIC frame semantics and then serialize them on the same stream?

Yes, this all boils down to a fairly central question: do we build the same thing for HTTP/2 and HTTP/3?  I'm not sure that we want that.  We need to do a whole bunch of stuff to use QUIC (BTW, Roberto gets to say "told you so" again here), but doing that same work for HTTP/2 doesn't make sense unless the changes are minimal.  I'm suggesting that the changes aren't as minimal as the rough sketches of protocols we have might imply.

If you conclude that there are more functions needed, as I have done, then you might also conclude that building those same functions into two different protocols is not desirable, especially when there are no benefits to doing so for one of those protocols.