Subject: [quicwg/base-drafts] Send a few immediate ACKs (#2025)

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 18:52:53 +0000 (UTC)

Attempt to address #1968
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2025

-- Commit Summary --

  * Send a few immediate ACKs

-- File Changes --

    M draft-ietf-quic-recovery.md (8)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2025.patch
https://github.com/quicwg/base-drafts/pull/2025.diff

-- 
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/2025

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 10:53:36 -0800

@ianswett pushed 1 commit.

099dedd  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2025/files/249f152bbc66e6c16046d054357bdeca8b830d8b..099dedd0f2cdaedf94ba34ced4f46b0edfce06ed

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 10:55:06 -0800

mikkelfj commented on this pull request.

> @@ -483,11 +483,15 @@ the peer spurious timeouts.  The maximum ack delay is communicated in the
 An acknowledgement SHOULD be sent immediately upon receipt of a second
 packet but the delay SHOULD NOT exceed the maximum ack delay. QUIC recovery
 algorithms do not assume the peer generates an acknowledgement immediately when

does immediately mean ASAP or any convenient time before ACK delay ?

-- 
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/2025#pullrequestreview-176923314

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 11:24:19 -0800

ianswett commented on this pull request.

The intent is when you're done processing this set of packets, as clarified in the last paragraph.

-- 
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/2025#discussion_r235137951

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Nov 2018 12:23:39 -0800

janaiyengar commented on this pull request.

 Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate
 loss recovery.  The receiver SHOULD send an immediate ACK when it receives a new
-packet which is not one greater than the largest received packet number.
+packet which is not one greater than the largest received packet number.  The

Suggestion: "The receiver SHOULD send an immediate ACK when it receives a new packet which is not the next expected one.  That is, its packet number is not one greater than the largest received packet number."

 Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate
 loss recovery.  The receiver SHOULD send an immediate ACK when it receives a new
-packet which is not one greater than the largest received packet number.
+packet which is not one greater than the largest received packet number.  The
+receiver MAY send an immediate ACK when a missing packet begins exceeding the
+peer's reordering threshold in packets to accelerate fast retransmit.  Time

This is a problem, since the receiver does not know the peer's reordering threshold. Also, this sentence does not make sense "a missing packet begins exceeding ... threshold in packets"

 Out-of-order packets SHOULD be acknowledged more quickly, in order to accelerate
 loss recovery.  The receiver SHOULD send an immediate ACK when it receives a new
-packet which is not one greater than the largest received packet number.
+packet which is not one greater than the largest received packet number.  The
+receiver MAY send an immediate ACK when a missing packet begins exceeding the
+peer's reordering threshold in packets to accelerate fast retransmit.  Time
+threshold loss detection does not require any special ACK generation to
+accelerate fast retransmit, because it uses a timer.

I think this text should be purely prescriptive, and only from the receiver's point of view, since the sender's is basically not known at the receiver. This also does not say when a receiver should stop immediate acking, which is important IMO.

Suggested replacement for text from "The receiver MAY" : "A receiver SHOULD immediately ack at least three subsequent packets after first receiving a packet out of order, after which it SHOULD resume delaying acknowledgements."

-- 
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/2025#pullrequestreview-176956517