Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)

Ryan Hamilton <> Tue, 03 December 2019 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 167361200A1 for <>; Tue, 3 Dec 2019 07:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cZx_t5144FXh for <>; Tue, 3 Dec 2019 07:21:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D89A812006B for <>; Tue, 3 Dec 2019 07:21:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 14D2A520DBC for <>; Tue, 3 Dec 2019 07:21:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575386476; bh=3P4CFEGM9eZWuHeX29aZ1GCh94DHA6Qk4KKCHqshZWA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=H0MsS2TW6ghJh+l2rSNzR3PMNdkrQsUhArseN75yMLJ+KbgvrB2nKqgOwhCIbcb6x LKbhS/oXsR/WddvgwaptZ2n8EvrxoHu5r1xmHSjbRHumKl07cqvHVzEGOXLOn5GRD4 W3xt6T9rgbNRuSurtKbERYyQGA5nRaxRBWtKiLl0=
Date: Tue, 03 Dec 2019 07:21:16 -0800
From: Ryan Hamilton <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3275/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5de67d6c5ca8_17df3fd1992cd9682417eb"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: RyanAtGoogle
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2019 15:21:19 -0000

> I am not sure how different they are. As you correctly point out, the benefit you achieve by pushing is limited to one BDP in HTTP/2. As there is the potential of pushing a response that has already been cached by the client, pushing too much has been a bad idea in HTTP/2. IMO, the fact that we are additionally capped by the push stream concurrency in HTTP/3 does not change the big picture.

In HTTP/2, pushing too much is only a problem when you push something that the client already has cached (or otherwise does not need) or if you invert the priorities and push something instead of sending something more important. But in HTTP/2 there is no performance problem with pushing an unlimited number of resources, so long as they are all "required" and "important".

This is not the case with push. Promising more resources than the concurrent stream limit is a performance regression. I think this is non-obvious.

> > * I could almost imagine replacing PUSH_PROMISE completely by a BLOCK_UNTIL_PUSH_RECEIVED frame which specifies a QUIC stream ID and prevents the app from processing the rest of the body until the specified push stream's initial headers are received.
> I presume that's the same as what I originally proposed in this issue? Personally, I think I am fine with either ways. What I'm unhappy with status-quo is that there is two ways of doing one thing, which is causing complexity.

I think this could be what you proposed initially, though I have one point of clarification. I understood the DUPLICATE_PUSH semantics to be that the client would continue to process the body of the stream on which the DUPLICATE_PUSH was sent, but that any requests would be blocked until the associated PUSH_PROMISE was received. I don't like this idea because it blocks all requests, not just those which the server intended to promise. Instead, I'd propose that the frame (whatever we call it) blocks the processing of the stream on which the frame was sent, which prevents the client from discovering the link to the promised resource until the push headers have arrived. (Of course the server should send the push headers on the push stream before it sends the frame on the original stream thus typically the push headers will arrive before the frame).

Is this latter behavior what you were thinking?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: