Re: Stream limits draft posted
David Benjamin <davidben@chromium.org> Tue, 14 November 2023 21:32 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@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 43EC3C151086 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Nov 2023 13:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level:
X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HQRSe8ujpLm for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Nov 2023 13:32:55 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99EAC14CF15 for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 14 Nov 2023 13:32:54 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1r30zS-000uu0-7t for ietf-http-wg-dist@listhub.w3.org; Tue, 14 Nov 2023 21:30:34 +0000
Resent-Date: Tue, 14 Nov 2023 21:30:34 +0000
Resent-Message-Id: <E1r30zS-000uu0-7t@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <davidben@google.com>) id 1r30zP-000usj-W4 for ietf-http-wg@listhub.w3.org; Tue, 14 Nov 2023 21:30:32 +0000
Received: from mail-yb1-xb2b.google.com ([2607:f8b0:4864:20::b2b]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <davidben@google.com>) id 1r30zN-00GzkL-TR for ietf-http-wg@w3.org; Tue, 14 Nov 2023 21:30:31 +0000
Received: by mail-yb1-xb2b.google.com with SMTP id 3f1490d57ef6-d9ac3b4f42cso217423276.0 for <ietf-http-wg@w3.org>; Tue, 14 Nov 2023 13:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1699997426; x=1700602226; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0V5E38Noz/IdAnkk677CjjkR0DfRy21EmCPjK/7jQ7A=; b=fUW8PL/2tBJ001aDzSaDn6opUj65q+wXEDQccP8A6/Bx4VhZ0vUgXQMG60aYbvBsVt f5HqnMb57bzEurlG9AmD0h2Iy2ejg2s77WDas9vSGstilfVI7e9jiRUO4TBN6nEGwTWf XLjRs8qjbH/iYsmuAGypaqC1WXQmxtfgFOvo4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699997426; x=1700602226; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0V5E38Noz/IdAnkk677CjjkR0DfRy21EmCPjK/7jQ7A=; b=wRNmaLi6Y2ct3ARwHhzHCAb5bFon9gDF4Ty6nAiVX+shXJyvQ2bkbYou+eEp2v9cTn fTw1cM46dU6RbDNMY5Wshk2/3t1PUPytYyPQGLnKLDbOU1ijH/hoxqQznVqPGFCvOp0/ /EXvtf2sZA//fqZRirZ7iRLmce0EzBqYA4F8tlZ2YaBC4c35b8BjXzmU9F+nUgtYnwzK 9zQmiff0olfudPHFDz6aOCff+mDiebrxatQHe/p8BV/TNwL3W3SoxxcX122bAXp/e2zr 0RBUxu0QiB0yB9Q9Hb0wfvKxP4Rf2OYF6uHO4sZ30Wt9Q7jhj05OKnOE5Dc7zNrUh0te STdQ==
X-Gm-Message-State: AOJu0Yye+Yu7NBocDwc/tVNhSYjMlSdKgnMIGvULU/EyZmTNK7A3aKFI h0LbogmTi5NiizdxRZLrCHFJfZH2iu4MTq3NQPgBVUTLjdlls2t2IA==
X-Google-Smtp-Source: AGHT+IGIj/h4VBmXdGypmMvCKC78LmNsgMU7Aq5jUR4BInx+KODO6KC5WG8WsaqVGtrh92B6U205aSHkaQGAOff6auY=
X-Received: by 2002:a25:d8e:0:b0:da0:6876:c20f with SMTP id 136-20020a250d8e000000b00da06876c20fmr3346481ybn.20.1699997425785; Tue, 14 Nov 2023 13:30:25 -0800 (PST)
MIME-Version: 1.0
References: <14d520c2-8c07-4c30-bd54-faa4ad964a6a@app.fastmail.com> <CANatvzwQ3hD9-+5rUo8Fi_zaHSmDBWv8HaJGPHOihT4qf8xs1Q@mail.gmail.com> <0DE80F27-85C7-4F5C-B04D-316F9C8B7DF5@eissing.org> <dad05307-306a-4d15-9c54-899f3f778c0a@app.fastmail.com> <ZU88Y3q3zQNEku_G@LK-Perkele-VII2.locald> <CAF8qwaDK5y0=d3q7_V0R+Nv3buSoxH0-wGTt=PTpbcQ-snM=cA@mail.gmail.com> <BN8PR15MB3281A9315859245030BDFE0FB3B3A@BN8PR15MB3281.namprd15.prod.outlook.com>
In-Reply-To: <BN8PR15MB3281A9315859245030BDFE0FB3B3A@BN8PR15MB3281.namprd15.prod.outlook.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 14 Nov 2023 16:30:09 -0500
Message-ID: <CAF8qwaBg8d_QP+kdRFz=-qMW7MSLqXcrF2LHTKy3kXt=MbCC3g@mail.gmail.com>
To: Ben Schwartz <bemasc@meta.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000af2ec2060a237e4b"
Received-SPF: pass client-ip=2607:f8b0:4864:20::b2b; envelope-from=davidben@google.com; helo=mail-yb1-xb2b.google.com
X-W3C-Hub-DKIM-Status: validation passed: (address=davidben@google.com domain=chromium.org), signature is good
X-W3C-Hub-Spam-Status: No, score=-11.3
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1r30zN-00GzkL-TR 1d09931dc78f891aec1bd6b58f7dc172
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stream limits draft posted
Archived-At: <https://www.w3.org/mid/CAF8qwaBg8d_QP+kdRFz=-qMW7MSLqXcrF2LHTKy3kXt=MbCC3g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51597
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/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Can you elaborate on the compatibility and configuration issues? h2.1-only clients is a good example of why the weird implicit ALPS thing isn't ideal. It allows a server to say "I'm willing to do fixed-h2 but not broken-h2", but it doesn't allow a client to say this. Less of a serious concern than the server, but it's something we give up by losing the orthogonality. I also think this allergy towards minting ALPNs is bad for the evolvability of our protocols. There are plenty of problems where minting a new ALPN is the right solution. If we have systems that cannot handle it, that's a problem and we should exercise them better and fix this. Otherwise we'll have ossified yet another extension point. On Mon, Nov 13, 2023 at 11:30 AM Ben Schwartz <bemasc@meta.com> wrote: > If ALPS is in use, I think a new ALPN ID is unnecessary. ALPS implicitly > defines a new profile of each offered ALPN. We can define a > SETTINGS_USE_MAX_STREAMS setting for H2, and note that client support for > this setting (and any other settings that we believe should be in a > "modern" client baseline) is mandatory when offering ALPS for "h2". > > This does move toward ALPS influencing the server's ALPN selection. > Perhaps that is less elegant than perfect orthogonality, but I think it's > better than minting new ALPN IDs. In particular, a new ALPN ID creates > various compatibility and configuration headaches related to "h2.1-only" > clients and servers, and HTTPS records. > > --Ben Schwartz > ------------------------------ > *From:* David Benjamin <davidben@chromium.org> > *Sent:* Sunday, November 12, 2023 6:55 PM > *To:* Ilari Liusvaara <ilariliusvaara@welho.com> > *Cc:* ietf-http-wg@w3.org <ietf-http-wg@w3.org> > *Subject:* Re: Stream limits draft posted > > Even over TLS 1. 3, I would expect the vast, vast majority of HTTP/2 > servers do not send SETTINGS at half-RTT. When I probed some list of top > sites in 2020, I could not find a single one. This should not be surprising > once you dig into it. Half-RTT > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > > ZjQcmQRYFpfptBannerEnd > Even over TLS 1.3, I would expect the vast, vast majority of HTTP/2 > servers do *not* send SETTINGS at half-RTT. When I probed some list of > top sites in 2020, I could not find a *single* one. > > This should not be surprising once you dig into it. Half-RTT data on a > 1-RTT handshake is semantically weird, in a way that half-RTT on a 0-RTT > handshake is not. It really does not fit well into TLS-over-TCP's existing > interfaces at all.On the client side, taking a 1-RTT hit against > practically all existing HTTP/2 servers seems clearly an unreasonable > performance cost. Ultimately, it is a change in protocol semantics to go > from "sending SETTINGS at 1-RTT is just fine" to "SETTINGS must be sent at > half-RTT to avoid latency problems". On the server side, I don't believe > it's possible to send it with OpenSSL servers. BoringSSL too, which was an > intentional choice on our part. > > I wrote this a couple years ago, which discusses this and other problems > with trying to solve this shape of problem with half-RTT: > https://www.ietf.org/archive/id/draft-davidben-tls-alps-half-rtt-00.html > > I haven't been following this issue as closely, but skimming the draft, it > seems to me three questions here: > 1. How to ensure clients know to trigger the new mode early enough. > 2. How to allow clients to open streams in the new mode without waiting > for an RTT, in both 1-RTT and 0-RTT handshakes. > 3. How to distinguish clients that do and don't implement the new scheme > so that, either under load or perhaps unconditionally in the future, > servers can avoid negotiating h2 with older clients. > > I suspect any solution for (2) will either look like early server->client > communication (be it ALPS or a Rube Goldberg of half-RTT, 0-RTT session > ticket state, and applications injecting themselves into the 0-RTT > accept/reject decision), or, as Kazuho suggested, just some hard-coded > initial default value. Both the ALPS and half-RTT plans will require TLS > software changes, so I suspect the hard-coded initial value is most viable, > provided we can find a small enough default to satisfy DoS concerns, but > large enough to admit one RTT worth of stream creations. > > But then we don't solve (1) for free. For that, I think the new ALPN is > the way to go. As this is essentially a protocol bugfix, rather than an > optional extension, a version bump to "h2.1" seems appropriate. ALPN > happens early enough, and is already correctly integrated with 0-RTT, so > the client will know, before sending data, to use the new mode. Moreover, > the server knows whether the client will behave *before* picking the > protocol, so we get (3) as well, which the half-RTT and ALPS options would > not give us. (ALPS puts the client message in the second client flight so > that it is encrypted. That means the server only knows "client supports > ALPS" at protocol selection time. It also was designed assuming it > *wouldn't* impact protocol selection.) > > The hardcoded default is a little unsatisfying compared to early > server->client, but we could do both: if we get a server->client initial > value in ALPS, use that. Otherwise, use the hard-coded default. (This isn't > an option with half-RTT because the client needs to know when to stop > waiting, when talking to a server that can't send it.) > > (To fully explore the problem space, a new ALPN *does* resolve the client > performance problems of the half-RTT approach: with a new ALPN we can say > "you *must* send SETTINGS in half-RTT in h2.1". But all the other > problems, such as those in the link and requiring TLS library changes, > remain. I do not think half-RTT is viable here.) > > On Sat, Nov 11, 2023 at 3:37 AM Ilari Liusvaara <ilariliusvaara@welho.com> > wrote: > > On Sat, Nov 11, 2023 at 08:50:51AM +0100, Martin Thomson wrote: > > On Fri, Nov 10, 2023, at 14:16, Stefan Eissing wrote: > > > +1 > > > > > > I think clients will not wait for the MAX_STREAMS from the server. I > > > assume they want to send right away instead of waiting for a while. > The > > > server might support it or not. How long are they willing to wait for > > > this? > > > > In the meeting, it was suggested that we require clients to wait for > > SETTINGS before opening streams. I think that is a good idea and > > entirely possible, without significant performance penalties. > > > > In TLS 1.3, the server can send SETTINGS immediately, which means that > > the client only needs to read a few more bytes before it can start > > sending. > > > > The minor pain here, as David Benjamin will likely remind us, is that > > it is a little awkward sending data from the server before seeing the > > client Finished. So we'd probably want to experiment here. > > I have written a HTTP reverse proxy, which used to send SETTINGS > immediately in TLS 1.3[1]. Unfortunately, that caused some clients to > break[2], manifesting as fatal unexpected_message TLS alert immediately > after handshake completed. So I changed the code to always wait for > finished from client[3]. > > > [1] If there was no client certificate request, for shortcomings of > the interface between TLS and HTTP layers. > > [2] No information about what clients broke. However, mentions by > one user might indicate that some "anti-virus" products were > involved. > > [3] There might still be option to re-enable the old behavior. > > > > > -Ilari > >
- Stream limits draft posted Martin Thomson
- Re: Stream limits draft posted Glenn Strauss
- Re: Stream limits draft posted Martin Thomson
- Re: Stream limits draft posted Kazuho Oku
- Re: Stream limits draft posted Glenn Strauss
- Re: Stream limits draft posted Glenn Strauss
- Re: Stream limits draft posted Stefan Eissing
- Re: Stream limits draft posted Martin Thomson
- Re: Stream limits draft posted Ilari Liusvaara
- Re: Stream limits draft posted David Benjamin
- Re: Stream limits draft posted Ben Schwartz
- Re: Stream limits draft posted Rory Hewitt
- Re: Stream limits draft posted David Benjamin
- Re: Stream limits draft posted David Benjamin
- Re: Stream limits draft posted Martin Thomson
- Re: Stream limits draft posted Ben Schwartz