IETF Logo Mail Archive

Re: Lost initial MAX_PUSH_ID is unfortunate

"Martin Thomson" <mt@lowentropy.net> Wed, 28 August 2019 23:49 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022BA1201AA for <quic@ietfa.amsl.com>; Wed, 28 Aug 2019 16:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=K/4IpTT1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lsms2Gr5
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 vFvdEbbI_ghv for <quic@ietfa.amsl.com>; Wed, 28 Aug 2019 16:49:53 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25BD1200B7 for <quic@ietf.org>; Wed, 28 Aug 2019 16:49:53 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id ED1B72205C for <quic@ietf.org>; Wed, 28 Aug 2019 19:49:52 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 28 Aug 2019 19:49:52 -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 :subject:content-type; s=fm3; bh=lNLesna0N4/zUQP/HODxpquBH54Uyxu rEhdsq929qMY=; b=K/4IpTT1r+PSkMW5rcI1NSxTiKoSx4X3Clv52YwOg+x74YO b6LbjMB9RmJYMqISFDtTyGON08IG+jvMEQLmNKSXwECKdCbzICQPRAuUoSexnTSi obbzFhCs5eD9bpSotPATIkuqo3prlF/VEH+vnSqJWxBr9BHMNK1tygov6T1PVBvX XUPy8HCIdVmt090lgtuwTZdZ2RA7lrjGbzr+1PyJt418ciGnXUGkWOtj+C7oZ+G/ RfboYa/ugZt7l5mfqUriVOxWG0EhuMWGuxL3/uvytvdCRV/XkIeWcqGOubcIYGyy H3QtAOujMOJFAUBMXLFJv5q4QNZAJUxOR/RhHdw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=lNLesn a0N4/zUQP/HODxpquBH54UyxurEhdsq929qMY=; b=lsms2Gr5PetCxCOABzMKYh eqEPKbD1sl9nbjSCndVhe3xhq0kC2dkGDZBQVcHxxei+uiGaEM33D1qd1XfLNiyy Uz93po3Q9K08wCtEIKvWEdwm7B5I/hgScRXg2+9o/Jsv/JTextv06Mapdw5NybmI /P1XFb/oJ8ugogMGTzluJjGtX+dkwv0DOKQbUNZwKlt7z0VeQHBZHEzNH9frsMOj O3XBEM0/Cu1wU4myWG8xmj3LnxLHabWV0ixdjpgD/MaiR0iQ2QwfBoDeUz5MdAWh JLuGhnoE0V1FkB4T//TQzKHQLkM4peW1zIFStW/lFUkuxac1UOdWucjUAyTqTlPg ==
X-ME-Sender: <xms:IBNnXRQtxOEEpLoBfh02lZ48f4kn0hOlE413oJ_mqm-KqGJJIqL9NA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeiuddgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehloh ifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:IBNnXSG_nnycnUyNvLFF27ZqdI-k6WXolokKKlciJt0-bqXDik0r_w> <xmx:IBNnXZd2gMnha2UrC0t1a1LnnOo4u6oDZyYInzO3qXy7htNIJsjLxw> <xmx:IBNnXTFNlOMyLHtD_AWmMSe7Uqp18cx27A6Pybbrg0Yg3NWAeM8CPQ> <xmx:IBNnXVcHvtcAhbH-fHsDbGnN1BnGKBAhKyQ54RtiJQazfyBfzJKTJw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 72D00E00A3; Wed, 28 Aug 2019 19:49:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-139-g73fcb67-fmstable-20190826v1
Mime-Version: 1.0
Message-Id: <3db7ef09-36fc-4adf-933c-39d3ae4be5c5@www.fastmail.com>
In-Reply-To: <CACdeXiLM6q0AZWEWAwfBL5J=zAPkFiXfr+_=OU0cS-uuqW9wxQ@mail.gmail.com>
References: <CAJ_4DfSE4_2GR5peGeRuWnixgdc9ucGiXtab=c0fXbqedFHsgA@mail.gmail.com> <1931a6f6-a25f-478e-b150-a200e0c3c69e@www.fastmail.com> <CACdeXiLM6q0AZWEWAwfBL5J=zAPkFiXfr+_=OU0cS-uuqW9wxQ@mail.gmail.com>
Date: Thu, 29 Aug 2019 09:49:32 +1000
From: Martin Thomson <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Lost initial MAX_PUSH_ID is unfortunate
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MkWDxrQxpJcvrzMFbMoY34mJJF8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2019 23:49:56 -0000

On Thu, Aug 29, 2019, at 04:39, Nick Harper wrote:
> Why can't we have the best of both worlds? If we put this signal in the 
> crypto handshake, the application protocol can guarantee that it 
> arrives before any STREAM frames, and we don't introduce any more head 
> of line blocking because the connection is already blocked on the 
> crypto handshake messages to derive 0-RTT or 1-RTT application data 
> keys.

You can already have that.  Coalescing the packet containing SETTINGS/MAX_PUSH_ID with the last Handshake packet is entirely possible and has the same net effect.  And most implementations will be able to manage that (at least on the client side, coalescing 0.5RTT from the server is a little challenging).

But it's not best of both worlds, that would be forcing head of line blocking.  Right now, implementations choose their level of exposure.

v2.23.0 | Report a Bug | By Email