Re: [quicwg/base-drafts] PUSH_ID as a frame (#2526)

Lucas Pardue <> Mon, 18 March 2019 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 714451311B3 for <>; Mon, 18 Mar 2019 13:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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_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 xX2XtwWLOPGz for <>; Mon, 18 Mar 2019 13:29:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31D101311B4 for <>; Mon, 18 Mar 2019 13:29:21 -0700 (PDT)
Date: Mon, 18 Mar 2019 13:29:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1552940960; bh=fgcMOqUd9K5tEF9P7qh6189iOQg+v7MA+dh1ppsz/Lw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TencYtdWZll3u/5iriTduQdf1PAeivq2FytmOAqiDwlj7vRc5d1lecV4Io1FVw23v tWi2KtSFhNGnc+unyEGit8u8KdVS4Wr8U6Cs+E2pm2Fkw1qidz51GPW6BWwLIF8XSZ 35AqggAfXEw33LPBJX7wnZc8/R4e+TVg/60UNp5s=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2526/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] PUSH_ID as a frame (#2526)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c8fffa035e69_43983fe2070d45c0523b7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
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: Mon, 18 Mar 2019 20:29:24 -0000

+1 to levelling up, I'll take acknowledge my guilt here. But before I move on:

> push_id then yes you would read 0x1 which is conveniently a server initiated bidirectional stream which is not allowed anyway, so you could reject it immediately

If your at the stage of parsing QUIC STREAM frame payload, you should already know exactly what the stream ID is.

Some historic points I remember:

In Paris MT presented some ideas for unidirecitonal streams. This relates to issue and PR

Push and control streams were identified then. And we were happy with reserving specific stream IDs for certain things. All non-reserved streams were server push streams. Subsequent data on the stream only makes logical sense to handle if you know what push it relates to, so those bytes go first. 

Roll forward some, QPACK design requires additional streams so those get reserved to. Around Kista, the topic of unidirectional stream types comes up. Without types, we make uncoordinated unidirecitonal stream extensions quite a difficult thing. So add more bytes at the start of stream and remove reservations.

> For example, one could make a counter argument: why are we framing SETTINGS at all given that it is the first message on the control stream ?

The SETTINGS frame can contain a set of parameters, indeed it SHOULD contain at least one GREASE setting. A single SETTINGS frame that describes the length of all parameters is quite useful, you know when the peer has finished sending all of them. I don't see as much value for PUSH_PROMISE because you're just framing a single integer that describes its own length already. 

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