Date: Wed, 01 Jan 2020 16:54:05 -0800
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/-k8CYqcQsFCv7p68AAzjnant_S8>


----==_mimepart_5e0d3f2dbc7d1_38473fe81e4cd95c165934b
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

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
----==_mimepart_5e0d3f2dbc7d1_38473fe81e4cd95c165934b
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@kazuho</b> commented on this pull request.</p>

<p>LGTM modulo one paragraph.</p><hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/3315#discussion_r362353173">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; -
-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
</pre>
<p>I am confused by this sentence due to the following two reasons:</p>
<ul>
<li>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."</li>
<li>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."</li>
</ul>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/3315#discussion_r362353302">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; -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
</pre>
<p>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"?</p>
<p>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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/3315?email_source=notifications&amp;email_token=AFTOJK6DY4YNCHTBTYVRKDLQ3U3K3A5CNFSM4KBZKW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQPASOY#pullrequestreview-337512763">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK333VN32I5425BYJHLQ3U3K3ANCNFSM4KBZKW7Q">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJKZUWDOLSIIQ7L7ZREDQ3U3K3A5CNFSM4KBZKW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQPASOY.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/3315?email_source=notifications\u0026email_token=AFTOJK6DY4YNCHTBTYVRKDLQ3U3K3A5CNFSM4KBZKW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQPASOY#pullrequestreview-337512763",
"url": "https://github.com/quicwg/base-drafts/pull/3315?email_source=notifications\u0026email_token=AFTOJK6DY4YNCHTBTYVRKDLQ3U3K3A5CNFSM4KBZKW72YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQPASOY#pullrequestreview-337512763",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5e0d3f2dbc7d1_38473fe81e4cd95c165934b--