Re: [quicwg/base-drafts] Better duplicate detection (#3696)

Kazuho Oku <notifications@github.com> Tue, 26 May 2020 05:16 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 E86D83A0A3E for <quic-issues@ietfa.amsl.com>; Mon, 25 May 2020 22:16:20 -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 EDDBQKH39NE6 for <quic-issues@ietfa.amsl.com>; Mon, 25 May 2020 22:16:18 -0700 (PDT)
Received: from out-28.smtp.github.com (out-28.smtp.github.com [192.30.252.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5280A3A0A3B for <quic-issues@ietf.org>; Mon, 25 May 2020 22:16:18 -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 537AC8C0211 for <quic-issues@ietf.org>; Mon, 25 May 2020 22:16:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1590470176; bh=6+VMt7/PpDQSYMviv0o/7oICFM1Nr0N8GbqW2wdNwyk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HDIBlRzr/LSbbrrUi85jBbmZfEmXSUOy4qSb4NqW09y8ykNLnC0x3tTUbRbDBbufx Vc0hL/1eWok2J/xB9Ybo0KeizW6rTAeH2tJfa3EbBUAgcI+K0J4k6ha1p5qLwwne1U LRAT5a3dbTFo0d/A//7h/lHFes6WzwN3GpgbPqIg=
Date: Mon, 25 May 2020 22:16:16 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK772FWEAZNBSR46LLN43CDSBEVBNHHCKOUZLM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3696/review/417972533@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3696@github.com>
References: <quicwg/base-drafts/pull/3696@github.com>
Subject: Re: [quicwg/base-drafts] Better duplicate detection (#3696)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ecca62042ac7_20d63fb6494cd96837549b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/IaUIBpC4GPvq1alNTnNJhUnqcpI>
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, 26 May 2020 05:16:22 -0000

@kazuho commented on this pull request.

Thank you for the PR. Looks mostly good, though I have some comments.

> @@ -3204,9 +3204,15 @@ response to further packets that it receives.
 A receiver MUST discard a newly unprotected packet unless it is certain that it
 has not processed another packet with the same packet number from the same
 packet number space. Duplicate suppression MUST happen after removing packet
-protection for the reasons described in Section 9.3 of {{QUIC-TLS}}. An
-efficient algorithm for duplicate suppression can be found in Section 3.4.3 of
-{{?RFC4303}}.
+protection for the reasons described in Section 9.3 of {{QUIC-TLS}}.
+
+Endpoints that track individual packets for the purposes of detecting duplicates
+might accumulate excessive state.  The data required for detecting duplicates

Would it be possible for us to recommend tracking ranges? For example, it might be a good idea to state like: _For the purposes of detecting duplicates, endpoints might track individual packets or ranges of consecutive packet numbers, though tracking individual packets might accumulate excessive state._

> @@ -3204,9 +3204,15 @@ response to further packets that it receives.
 A receiver MUST discard a newly unprotected packet unless it is certain that it
 has not processed another packet with the same packet number from the same
 packet number space. Duplicate suppression MUST happen after removing packet
-protection for the reasons described in Section 9.3 of {{QUIC-TLS}}. An
-efficient algorithm for duplicate suppression can be found in Section 3.4.3 of
-{{?RFC4303}}.
+protection for the reasons described in Section 9.3 of {{QUIC-TLS}}.
+
+Endpoints that track individual packets for the purposes of detecting duplicates
+might accumulate excessive state.  The data required for detecting duplicates
+can be limited by maintaining a minimum packet number below which all packets
+are immediately dropped.  In setting a minimum packet number endpoints might
+need to account for large variations in round trip time that could significantly
+delay packets, especially if a peer migrates to or probes a different network
+path; see {{migration}}.

I think it might be a good idea to change this sentence to something like: _In setting a minimum packet number endpoints **have** to account for large variations in round trip time that could significantly delay packets, especially if a peer probes a different network path; see {migration}}._

The changes are use of "have to" rather than "might," and omitting the mention of migration.

Migration is not an issue, because when the peer migrates to a path with higher latency there would be no loss, and because when the peer migrates to a path with lower latency, the loss would be a one-time effect that can be recovered.

In contrast to that, for path migration to work, endpoints have to be capable of deduplicating packets with significant reordering. Without that, the peer cannot reliably probe a path while sending data.

I think this is essentially a requirement regardless of how we phrase it.

-- 
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/3696#pullrequestreview-417972533