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

From: Kazuho Oku <[email-masked]>
Date: Wed, 01 Jan 2020 16:54:05 -0800

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

---

From: ianswett <[email-masked]>
Date: Thu, 02 Jan 2020 12:52:23 -0800

ianswett commented on this pull request.

Some suggestions, this is a hard section to rewrite.

> @@ -3202,27 +3202,32 @@ all subsequent ACK frames containing them could be lost. In this case, the
 loss recovery algorithm could cause spurious retransmits, but the sender will
 continue making forward progress.
 
+

nit: extra line break?

> -contribute to the ACK frame size.  When the receiver is only sending
-non-ack-eliciting packets, it can bundle a PING or other small ack-eliciting
-frame with a fraction of them, such as once per round trip, to enable
-dropping unnecessary ACK ranges and any state for previously sent packets.
-The receiver MUST NOT bundle an ack-eliciting frame, such as a PING, with all
-packets that would otherwise be non-ack-eliciting, in order to avoid an
-infinite feedback loop of acknowledgements.
-
-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

This normative statement could be misleading.  A receiver really needs to limit the number of ranges somehow, otherwise ACK frames will grow in size indefinitely.  If you do keep it, I think its a SHOULD or MUST not a MAY.

This is a good point.  I think the most correct behavior is to prefer newly received packets, but larger packet numbers is simpler.

+causing the sender to unnecessarily retransmit those packets.

I'd drop this sentence, but here's a suggestion if you keep it.

```suggestion
causing the sender to unnecessarily retransmit information.
```

-- 
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-337843904

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Jan 2020 14:49:13 -0800

martinthomson commented on this pull request.

Yeah, this might be better as an axiomatic statement.  How about:

> A receiver limits the number of ACK Ranges ({{ack-ranges}}) it remembers and sends in ACK frames, both to limit the size of ACK frames and to avoid resource exhaustion.  A receiver SHOULD stop tracking ACK Ranges after receiving acknowledgments for ACK frames containing ACK Ranges.
>
> It is possible that retaining many ACK Ranges could cause an ACK frame to become too large.  A receiver can discard unacknowledged ACK Ranges to limit ACK frame size.  This is necessary if an ACK frame would be too large to fit in a packet, however receivers MAY also limit ACK frame size further to preserve space for other frames.
>
> When discarding unacknowledged ACK Ranges, a receiver MUST retain the largest acknowledged packet number.  A receiver SHOULD retain ACK Ranges containing newly received packets or higher-numbered packets.

-- 
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#discussion_r362659147

---

From: Martin Thomson <[email-masked]>
Date: Thu, 02 Jan 2020 14:50:48 -0800

Larger packet numbers should be a very good approximation of that, for sure.

-- 
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#discussion_r362659534

---

From: Martin Thomson <[email-masked]>
Date: Mon, 06 Jan 2020 19:59:15 -0800

One possible addition here, to avoid replay attack:

> A receiver MUST discard packets with packet numbers from ACK Ranges that are not being tracked or they might be exposed to replay attack.  One method for avoiding replay is maintaining a minimum acceptable packet number; see Section 3.4.3 of {{?ESP=RFC4303}} for a sample algorithm.

-- 
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#discussion_r363583149

---

From: ianswett <[email-masked]>
Date: Tue, 07 Jan 2020 06:55:44 -0800

This is a good point, though it might deserve its own PR/Issue?  I thought we had text on dropping packets with packet numbers that had already been processed, but I couldn't find it in transport.

-- 
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#discussion_r363785927

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Jan 2020 15:51:58 -0800

It might be in -tls.

It's in transport already: https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-12.3-11

-- 
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#discussion_r364006831