Subject: [quicwg/base-drafts] Allow repeat ACK's (#1234)

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Mar 2018 12:07:14 +0000 (UTC)

It is an unfortunate that requirement that "SHOULD NOT be ack'ed again":

You want to ack packets again because you collapse gaps into larger blocks. Only the oldest ACK'ed block should not be acked again. It also leads to unnecessary bookkeeping.

-- 
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/issues/1234

---

From: Marten Seemann <[email-masked]>
Date: Mon, 19 Mar 2018 12:19:38 +0000 (UTC)

At the point where you received an ACK for an ACK, 1 RTT has passed, and there's no need to include any packet lower than the largest acked in new ACK frames, even if you received a heavily reordered packet. By that time, this packet will have been retransmitted anyway.

-- 
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/issues/1234#issuecomment-374193053

---

From: MikkelFJ <[email-masked]>
Date: Mon, 19 Mar 2018 13:00:22 +0000 (UTC)

Does this hold for ultra low latency networks? The retransmission logic may not necessarily follow guidance, and why require tracking this. An ACK'might not be ACK'ed for quite a while anyway.

It is a lot simpler to state that an ACK frame should not transmit more than one RTT worth of packets, or what is deemed suitable for the current network conditions.

-- 
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/issues/1234#issuecomment-374203003