ACK retransmission

[martinthomson]

We have rules about retransmission of STREAM frames. ACK has similar properties in terms of what needs to be retransmitted. Once an ACK has been acked, what should a sender do when constructing future ACK messages?

[ianswett]

ACKs are cumulative, therefore you would never retransmit them. This is similar to TCP.

Or possibly you're asking a different question?

[MikeBishop]

This seems bound to the possible removal of STOP_WAITING (#66). STOP_WAITING effectively ACKs the ACK, informing the receiver that the sender has all the loss/arrival information needed about those packets. Hypothetically, you could infer something equivalent with ACKs of packets containing ACKs.

[martinduke]

sack blocks aren't really cumulative under some interpretations; hence my confusion. For instance I might ack packet 1 and SACK 3,4,5. Do I continue to send this information in subsequent ACK frames, leading to potentially very long ones? Or do I just send it once and leave it out of ACK frames that report, say SACK 7,8,9?

If I leave them out, then by extension I should keep track of what acks/sacks went out in each packet, so that if the packet containing the ack is itself acknowledged I never have to report them again.

I am unclear as to how the logic of a protocol without STOP_WAITING would work, so it's clear that either I missed something in the draft or it's just not written.

[ianswett]

The guideline is to continue to ack packets until a stop waiting frame says to not ack them anymore. However, a receiver can also stop acking packets due to memory constraints, running out of ranges, or potentially other reasons. Section 6.2 of the transport doc does go into this, but it could be a bit clearer, and a clarifying example may be helpful.
https://tools.ietf.org/html/draft-ietf-quic-transport-00#section-6.2

In terms of how the logic would work without STOP_WAITING, it's completely non-obvious in the current specs, which is why I need to write it up.

[martinduke]

Ah. OK. My first hack at implementing this did what you describe, then I realized that the alternate approach would save lot of bytes, though with more bookkeeping. I see now that the words are there in Section 6.2 but it would be nice to have a more explicit requirement, e.g. "A receiver SHOULD repeat SACK blocks until those packets are covered by a STOP_WAITING".

To be honest, I think tracking which of my acks have been acked would reduce the control overhead of the protocol without requiring any wire format changes. But this might all be moot if STOP_WAITING dies.

[ianswett]

Tracking acks of acks is how STOP_WAITING dies.

[martinduke]

I always thought the main purpose of STOP_WAITING was to stop acking lost packet numbers, which of course will never be retransmitted. Will the receiver somehow infer this instead?

[MikeBishop]

And it is -- but the reason you can stop ACKing them is that the original sender has enough information to know they're lost. They can tell you this explicitly (STOP_WAITING), or you can infer it by knowing which of your ACKs made it through.

[martinduke]

OK, so because we know the loss detection algorithm we can infer what the sender has given up on. That sounds like it might be problematic when the loss detection is timer-based. Moreover, it turns loss detection into something that must be carefully negotiated between endpoints, rather than simply innovating on one end.

Perhaps I should give you a chance to write it up before trying to poke holes in it. :-)

[mnot]

See #66 for what @ianswett will do

[martinthomson]

@janaiyengar I think that we can close this. There were lots of improvements to this text and I think that we captured the spirit of this well enough.

[martinthomson]

OK, so I am going ahead and closing this anyway. I probably missed this in the change log, but that's not a big deal.