Subject: [quicwg/base-drafts] ACK of ACK are useful (#2546)

From: Christian Huitema <[email-masked]>
Date: Sat, 23 Mar 2019 07:16:17 -0700

The transport spec says in section 13.1.1:  "An endpoint MUST NOT send a packet containing only an ACK frame in response to a packet containing only ACK or PADDING frames, even if there are packet gaps which precede the received packet. This prevents an indefinite feedback loop of ACKs."

I argue that this MUST NOT should be changed to SHOULD NOT. Fist, the infinite feedback can be prevented if, for example, an implementation only sends an ACK for N packets received, so there is really no need to be that strict. Second, ACK of ACK are generally useful. They enable trimming the grow of ACK lists in a controlled way.

In fact, I found that problem in interop tests. Some implementations would send thousands of data packets without sending a single ACK of ACK. That means the sender is stuck with a large ACK dashboard. Yes, it could be trimmed with timers, but that's hardly a controlled process. I fixed this by sending an ACK + PING packet whenever there the unacked ACK list is too long, but that's a hack.

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

---

From: ianswett <[email-masked]>
Date: Sat, 23 Mar 2019 16:45:13 -0700

I'd argue that ACK+PING isn't a hack, but instead a simple way for the sender, whose state we're trying to limit, to balance the amount of state it stores vs the extra ACKs being received.

Getting the peer to implement the correct ACK behavior by sending a single extra byte is much simpler and more robust in my experience than relying on the receiver to implement an "ACK every 10/20/etc ACKs" policy in a way that every sender is happy with.

This could likely use more text and there's still an outstanding editorial issue to move most of the ACK sending text that's in recovery into transport, so it's all in one place, since I believe there are currently a few subtle inconsistencies.

-- 
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/2546#issuecomment-475914488

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 23 Mar 2019 19:40:52 -0700

Completely agree. Ian hits on the key point here. In the case of an
endpoint that would like to limit the amount of state it stores, it's
highly desirable for THAT endpoint to be in control. ACK+PING, satisfies
that. Relying on ACKs of ACKs from the peer does not, sadly.

On Sat, Mar 23, 2019 at 4:45 PM ianswett <[email-masked]> wrote:

> I'd argue that ACK+PING isn't a hack, but instead a simple way for the
> sender, whose state we're trying to limit, to balance the amount of state
> it stores vs the extra ACKs being received.
>
> Getting the peer to implement the correct ACK behavior by sending a single
> extra byte is much simpler and more robust in my experience than relying on
> the receiver to implement an "ACK every 10/20/etc ACKs" policy in a way
> that every sender is happy with.
>
> This could likely use more text and there's still an outstanding editorial
> issue to move most of the ACK sending text that's in recovery into
> transport, so it's all in one place, since I believe there are currently a
> few subtle inconsistencies.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/2546#issuecomment-475914488>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6ylBWKH5j6-TBeb21ZPBIzGuBNMnZks5vZryJgaJpZM4cE7-W>
> .
>

-- 
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/2546#issuecomment-475922869