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

Ryan Hamilton <> Tue, 03 December 2019 05:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA1E112008C for <>; Mon, 2 Dec 2019 21:22:28 -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 E0rLeBbkrmsK for <>; Mon, 2 Dec 2019 21:22:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BCC7120033 for <>; Mon, 2 Dec 2019 21:22:27 -0800 (PST)
Date: Mon, 02 Dec 2019 21:22:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1575350546; bh=1+CtT7pvUI75Sv526vorR2LlF/K6ZcieYs0ja4w6Blc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=npLTtRHvZtVyTPS05OFq9tRV8m4TB3lA2MSecdWBFfyI8elPqTWo6VtvHc7T8XsDy kAqH3U+3iPhQ6xgYIyZ/EjRcvq3PpYxlhIBvPIEdNGhh/KRP3VGtv4mG/WLxymGCoW QQGj7y/FZ62KSyLbZZLYMpC0M0JUNU5CH+SN+Gx0=
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_5de5f11258c1c_36813f9a866cd9681407d7"; 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 05:22:29 -0000

This is likely the wrong place for this observation, but I'll mention it here. Ian and I were chatting about this issue and realized a couple of things about HTTP/3 push which were quite surprising.

Recall that in HTTP/2, the motivating use case for PUSH_PROMISE was the ability to promise more resources than the open stream limit would allow to be pushed. (Consider an image search in which the server wants to push a grid of 100 thumbnails when the open stream limit is 10). 

The server would be able to push all 100 of these thumbnails in a single RTT (assuming sufficient BDP) because in HTTP/2 the sever can open a new stream as soon as the previous stream is closed.

However, in HTTP/3 this is not the case. The server will be unable to open a new push stream until it receives a new MAX_STREAMS from the client increasing the limit. But that burns an RTT. In which case, there's no point in pushing at all. So to avoid this, a client could increase the MAX_STREAMS to some sort of enormous value. But that does not behave like the HTTP/2 open stream limit. 

As such I'm not sure the original motivation for PUSH_PROMISE makes sense in HTTP/3. On the other hand, PUSH_PROMISE does something totally different in HTTP/3. It provides an ordering guarantee between the promised headers and the the reference to the resource in the main response body.

What's the conclusion of all this? I'm not sure. But it raises a few points:
* HTTP/3 server push works incredibly differently than HTTP/2
* At a minimum we should probably provide advice about how the client should manage MAX_STREAMS and MAX_PUSH_ID
* 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.

Thoughts? Does this resonate with anyone?

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