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

Martin Thomson <> Wed, 27 November 2019 22:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B072F1209A8 for <>; Wed, 27 Nov 2019 14:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, 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 Giwl_EbXRgsv for <>; Wed, 27 Nov 2019 14:47:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D0521200D6 for <>; Wed, 27 Nov 2019 14:47:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B4D6166039E for <>; Wed, 27 Nov 2019 14:47:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1574894831; bh=W3DX/fCNLKs1DjbyFNqAkStFpeAc5Fde8cgCzscFwzk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JSw1RtaF2+gIMI57r6aEm/Oe8aMk7BL3uLPCF+3b/VQHe+BdjTcXgKkSNVkxFq0E2 cmqja+OfOydN0ez9hdeQEN0NWQAtYfDO2XXyfXlNGc4sgJdcwazvuCnKkP+8gdTdF9 lwtqktIkDEhNUifgSJZZXOzBCZW7zkCk9x2rYA+I=
Date: Wed, 27 Nov 2019 14:47:11 -0800
From: Martin Thomson <>
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_5ddefcefa4dbf_79f23fe5dd4cd96829112c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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: Wed, 27 Nov 2019 22:47:14 -0000

I don't see any new information here.  The design we have is the result of balancing the need to have certain information in order with responses (as @RyanAtGoogle points out) and the desire to avoid the complexity and costs of duplication.

One advantage of the current design is the ability to exercise flexibility.  There is nothing preventing someone from pushing the same thing twice in this design, thereby avoiding DUPLICATE_PUSH.

Having implemented this, both at the server and the client, I can say that it is awkward, but not terribly so.  DUPLICATE_PUSH is a little tricky to thread on the server side, primarily due to it being hard to find something that is worth duplicating.  The client has no real problem with it other than the obvious ordering issue.  In that case, the simplest course is to proceed as though no push were promised until the PUSH_PROMISE arrives.

The possibility of priority inversion exists, but as pushes are discretionary, I don't see a significant downside.  Like QPACK, it's a discretionary feature and the server can make its own decisions about the risks.

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