ACK-only "frames"

[MikeBishop]

4.4 references "Ack only frames" -- I suspect this should be ACK-only packets, or perhaps more generally, packets which don't contain anything retransmittable.

I'm also a little confused as to why this is, but that could just be my lack of familiarity with the congestion control space.

[martinthomson]

There is more work needed here, but the point is that most congestion controllers depend heavily on feedback and if ACKs are held back by congestion control, the whole system can come crashing down. For that reason, we need a carve-out. If you are congestion-limited, then you can send a packet as long as it ONLY contains ACK frames. (No word about PADDING here or its effect, that's another issue that needs clarification.)

BTW, ACKs should be identified as "retransmittable" (in the sense that the data they contain needs to be sent again somehow). That whole retransmittable concept needs a serious rework.

[ianswett]

Martin is correct about ack only packets not being congestion controlled, because otherwise the whole system can get permanently stuck.

ACKs are really not retransmittable, since there is never a case one should send the exact same ack twice.

[martinthomson]

I'm going to keep harping on about this one: you don't retransmit packets, you don't retransmit frames, you retransmit data. The acknowledgements need to be retransmitted, for which you need to use ACK frames and packets.

[ianswett]

To clarify, by the word acknowledgement, you mean "The information that a packet has been received."? If so, then yes, but I don't think that's what most people think of when you say that, even though it is reasonable.

There are three possible definitions for acknowledgement: 1) A packet only containing and ack(This is most analogous to TCP, so I suspect is a common one) 2) An ack frame 3) Information that a packet has been received.

If we want to use acknowledgement to mean the third, we should be really clear about it.

[martinthomson]

Yes, I think that the most abstract (3) is the right answer here. We can explicitly talk about ACK frames, or packets containing only ACK frames (and PADDING) as necessary.

[mirjak]

But, as Ian said, you should probably also not use the word 'retransmit' here. If you detect that an ack frame was lost, you should make sure that (in a reasonable amount of time) a new ack frame is send that contains at least the information that the lost ack frame was carrying and maybe even have newer information as well. In some cases you may have already send another ack frame that also contains this information in the mean time and you potentially do have to do anything.

[ianswett]

Yes, 'retransmit' has some pretty strong associations from TCP, so we should probably avoid using it whenever possible. Resend might be an alternate option?

[ianswett]

I think we all vehemently agree on how the text should read, even if it doesn't today. I sent out a PR to fix the one case I could find where we talk about retransmitting frames in the transport draft.