Re: [quicwg/base-drafts] Remove timing guidance (#3474)

Martin Thomson <notifications@github.com> Sat, 22 February 2020 23:19 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 34F303A0A56 for <quic-issues@ietfa.amsl.com>; Sat, 22 Feb 2020 15:19:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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, 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 oi1rG-6U1oyX for <quic-issues@ietfa.amsl.com>; Sat, 22 Feb 2020 15:19:28 -0800 (PST)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD673A0A54 for <quic-issues@ietf.org>; Sat, 22 Feb 2020 15:19:28 -0800 (PST)
Date: Sat, 22 Feb 2020 15:19:27 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1582413567; bh=SLX3d2zmEo8NkEVgR8Bc8KBvhVWBcmxFg9lHaLKHqg0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jrcPwh71ykaNAT4WlpRFTFGyKmhPqJSxNnMR4ysKZ6VdO7QTxreHz12CDigLyndMs 8vhXUXTwTDxjRZY6cOdyhKMqld4xTDufbbzHqCd+1JUhEfJSuYnn3XawNPH9c4PiRQ LvnK6eGJvppP05BTdA9L3Hez185h134mUvkBn/UQ=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6EQS6XLU4TZFCU2YN4L3UX7EVBNHHCD3AHXI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3474/review/363055994@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3474@github.com>
References: <quicwg/base-drafts/pull/3474@github.com>
Subject: Re: [quicwg/base-drafts] Remove timing guidance (#3474)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e51b6ff7ee7c_50373fd60becd968517261"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/_CHNqwOGMmUmzH_Z3nQkBOzoyuY>
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: Sat, 22 Feb 2020 23:19:30 -0000

martinthomson requested changes on this pull request.

Thanks for doing this.  I think that it's the right general approach, but I have some things that I'd like to see.

> -An endpoint MAY discard a connection ID for which retirement has been requested
-once an interval of no less than 3 PTO has elapsed since an acknowledgement is
-received for the NEW_CONNECTION_ID frame requesting that retirement.  Until
-then, the endpoint SHOULD be prepared to receive packets that contain the
-connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and

pedantic nit: stopping use and sending RETIRE_CONNECTION_ID are two discrete actions.

> -then, the endpoint SHOULD be prepared to receive packets that contain the
-connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and
+then add the newly provided connection ID to the set of active connection IDs.
+Failure to retire the connection IDs promptly can cause failure of the
+connection, either because the endpoint closed the connection or can no longer

"the endpoint" here is ambiguous.

> -connection ID that it has requested be retired.  Subsequent incoming packets
-using that connection ID could elicit a response with the corresponding
-stateless reset token.
+An endpoint might need to stop accepting previously issued connection IDs in
+certain circumstances.  Such an endpoint can cause its peer to retire connection
+IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To
+field.  The endpoint SHOULD continue to accept the previously issued connection
+IDs until they are retired by the peer.  If the endpoint can no longer process
+the indicated connection IDs, it MAY close the connection.
+
+Upon receipt of an increased Retire Prior To field, the peer MUST first stop
+using the corresponding connection IDs using RETIRE_CONNECTION_ID frames and
+then add the newly provided connection ID to the set of active connection IDs.
+Failure to retire the connection IDs promptly can cause failure of the
+connection, either because the endpoint closed the connection or can no longer
+associate these connection IDs with the active connection.

I think that you might want to say "Failure to retire connection IDs promptly when requested can result in connection failures as peer might be unable to continue use of the corresponding connection IDs, resulting in either closing the connection or a stateless reset."  Or similar.

-- 
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/3474#pullrequestreview-363055994