Re: [quicwg/base-drafts] Rework flow of Push ID (#3925)

Bence Béky <notifications@github.com> Tue, 21 July 2020 20:35 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881D23A09C5 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jul 2020 13:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Level:
X-Spam-Status: No, score=-3.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 LPO6k6AH_nO8 for <quic-issues@ietfa.amsl.com>; Tue, 21 Jul 2020 13:35:32 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A4A83A09C4 for <quic-issues@ietf.org>; Tue, 21 Jul 2020 13:35:32 -0700 (PDT)
Received: from github-lowworker-f045d1f.ac4-iad.github.net (github-lowworker-f045d1f.ac4-iad.github.net [10.52.19.54]) by smtp.github.com (Postfix) with ESMTP id 5A886660834 for <quic-issues@ietf.org>; Tue, 21 Jul 2020 13:35:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1595363731; bh=q3JS4F+i12Vy0ZntsVlSGfkmloLSwROfwBRPHINubRk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=nzmzVffSGvTI8L3vj5GlC9PKi7DShY3KScwdZFhaseD4BzuCLR1Ns9Y/qqd8jPQRX MZ8wmG6ApJQzTHSo+u41PlrMaZ+wJu0JGitwU6ynouEHUzfQs0AbN9/mFIG2T4iIA6 qYHRBeVJ8J/PkMUX/RR/0TW5QwVT0WKVMZ2zlqJ8=
Date: Tue, 21 Jul 2020 13:35:31 -0700
From: Bence Béky <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6S5KPLKZPI753P6OF5EMZJHEVBNHHCPBRDMY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3925/review/452808712@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3925@github.com>
References: <quicwg/base-drafts/pull/3925@github.com>
Subject: Re: [quicwg/base-drafts] Rework flow of Push ID (#3925)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f1751934c645_5ad53f9493ecd968538d3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: bencebeky
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/a9TNiAOHJrMxMl2deJkWtgTDlWU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 20:35:34 -0000

@bencebeky commented on this pull request.



> -
-Server push is only enabled on a connection when a client sends a MAX_PUSH_ID
-frame; see {{frame-max-push-id}}. A server cannot use server push until it
-receives a MAX_PUSH_ID frame. A client sends additional MAX_PUSH_ID frames to
-control the number of pushes that a server can promise. A server SHOULD use Push
-IDs sequentially, starting at 0. A client MUST treat receipt of a push stream
-with a Push ID that is greater than the maximum Push ID as a connection error of
-type H3_ID_ERROR.
+Each server push is identified by a unique Push ID, which is used to refer to
+the push in various contexts throughout the lifetime of the connection.
+
+The Push ID space begins at zero, and ends at a maximum value set by the
+MAX_PUSH_ID frame; see {{frame-max-push-id}}.  Server push is only enabled on a
+connection when a client sends a MAX_PUSH_ID frame.  A client sends additional
+MAX_PUSH_ID frames to control the number of pushes that a server can promise.  A
+server SHOULD use Push IDs sequentially.  A client MUST treat receipt of a push

I agree that this would be an interoperability issue.  However, I think SHOULD is just fine here.  In my mind MUST is something that the peer should be able to enforce, and since streams can arrive out of order, in this case the client cannot detect if the server starts push IDs from a positive integer or if the promise with push ID 0 is delayed.

I think the statement that push is only enabled when MAX_PUSH_ID is sent is still valid.  If no MAX_PUSH_ID is sent, push is not enabled.  If a MAX_PUSH_ID is sent by the client with any value, server push is technically enabled, even if a server that insists on starting push IDs from a larger integer would be not willing to push.  Am I misunderstanding your statement?

That being said, this sentence might flow better if rephrased as "In particular, a server is not allowed to push until it receives a MAX_PUSH_ID frame.".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3925#discussion_r458371555