Re: [quicwg/base-drafts] Rewrite section on ack range limiting (#3315)

Kazuho Oku <notifications@github.com> Thu, 02 January 2020 00:54 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 A8E981200B9 for <quic-issues@ietfa.amsl.com>; Wed, 1 Jan 2020 16:54:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 AigVZyE4BJpD for <quic-issues@ietfa.amsl.com>; Wed, 1 Jan 2020 16:54:06 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8506E12009E for <quic-issues@ietf.org>; Wed, 1 Jan 2020 16:54:06 -0800 (PST)
Date: Wed, 01 Jan 2020 16:54:05 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1577926445; bh=KwDXNt4KiW/YBHT9wzAaSf0LQBCe8Es9hM4vY4SUV8k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pYs/Byne8Kdi4XVwxNNR9h0rd4wUgDxYO+0fL8iudSih3MDTV0aGtWMw63NIGzy6s og4c18mM/Q985w2XEdRoUD8UtImB5fVj0CwVj9qLjS+UnWA3TmJ+QZH2QjoLbUlZ0K n6jXss+OyPE4P012CI1bAU/MMjXnlcg1H7lKLeok=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY5T7AZULTD7VIHHZ54DJY23EVBNHHCA4LU5E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3315/review/337512763@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3315@github.com>
References: <quicwg/base-drafts/pull/3315@github.com>
Subject: Re: [quicwg/base-drafts] Rewrite section on ack range limiting (#3315)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e0d3f2dbc7d1_38473fe81e4cd95c165934b"; 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/-k8CYqcQsFCv7p68AAzjnant_S8>
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: Thu, 02 Jan 2020 00:54:09 -0000

kazuho commented on this pull request.

LGTM modulo one paragraph.

> -
-To limit receiver state or the size of ACK frames, a receiver MAY limit the
-number of ACK Ranges it sends.  A receiver can do this even without receiving
-acknowledgment of its ACK frames, with the knowledge this could cause the sender
-to unnecessarily retransmit some data.  Standard QUIC algorithms
-({{QUIC-RECOVERY}}) declare packets lost after sufficiently newer packets are
-acknowledged.  Therefore, the receiver SHOULD repeatedly acknowledge newly
-received packets in preference to packets received in the past.
+A receiver MAY limit the number of ACK Ranges it sends to limit receiver state
+and the size of ACK frames.  A receiver SHOULD track which ACK frames have been
+acknowledged by its peer, so that it can limit ACK Ranges ({{ack-ranges}}) to
+those not yet acknowledged by the sender.
+
+It is possible that the ACK frame is too large, despite limiting ACK Ranges to
+those not yet acknowledged. A receiver can stop repeating unacknowledged ACK
+Ranges to further limit the size of the ACK frame.  When doing so, a receiver

I am confused by this sentence due to the following two reasons:

* It talks about repeating "unacked ranges". But actually, a receiver does not repeatedly transmit the same ranges. For example, when the receiver first transmits an ACK range of 1 to 3, then receives PN 4, the ACK frame transmitted the next time will contain an ACK range of 1 to 4 instead of 1 to 3. Therefore, I think we'd better talk about "packet numbers" rather than "ACK ranges."
* The sentence, due to the use of the term "repeating," might be read to imply that the receiver should emit an acknowledgement of a received packet at least once. But there is not such a requirement - it might be a good idea to drop "repeating."

> -number of ACK Ranges it sends.  A receiver can do this even without receiving
-acknowledgment of its ACK frames, with the knowledge this could cause the sender
-to unnecessarily retransmit some data.  Standard QUIC algorithms
-({{QUIC-RECOVERY}}) declare packets lost after sufficiently newer packets are
-acknowledged.  Therefore, the receiver SHOULD repeatedly acknowledge newly
-received packets in preference to packets received in the past.
+A receiver MAY limit the number of ACK Ranges it sends to limit receiver state
+and the size of ACK frames.  A receiver SHOULD track which ACK frames have been
+acknowledged by its peer, so that it can limit ACK Ranges ({{ack-ranges}}) to
+those not yet acknowledged by the sender.
+
+It is possible that the ACK frame is too large, despite limiting ACK Ranges to
+those not yet acknowledged. A receiver can stop repeating unacknowledged ACK
+Ranges to further limit the size of the ACK frame.  When doing so, a receiver
+SHOULD give preference to acknowledging newly received packets to those received
+earlier.  It is possible that such ACK Ranges are not received by the sender

I understand that this sentence is a copy from existing text, but I am not sure "prefer newly received packets" is the correct advice. Shouldn't we better suggest "prefer greater packet numbers"?

The answer might depend on if we assume an endpoint to emit an acknowledgement for a newly received packet at least once, but as stated above, I do not think it is a good idea to assume that.

-- 
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/3315#pullrequestreview-337512763