Clarify ACK sending text in transport

[ianswett]

The end of #3451 strayed into whether you could expect ACKs for non-ack-eliciting packets and why it was a SHOULD not a MUST to ACK every ACK-only packet at least once.

I'm filing this to add some text about cases when you definitely would not expect to receive an ACK of an ACK-only packet(ie: connection close and dropping PN space) and clarify that a sender cannot rely on receiving an acknowledgement of every packet, whether it's ack-eliciting or not, because ACKs get lost.

It's also possible there needs to be more clarity around "An endpoint MUST NOT send a non-ack-eliciting packet in response to a non-ack-eliciting packet, even if there are packet gaps which precede the received packet." since I intended to disallow Igor's suggestion when I wrote that.

[igorlord]

a sender cannot rely on receiving an acknowledgement of every packet, whether it's ack-eliciting or not, because ACKs get lost.

I do not understand this statement. Yes, packets with ACKs can get lost. But the mechanics of QUIC is that until an ACK-of-the-ACK is received, the sender will continue to acknowledge all packet ranges from the original ACK in every subsequent ACK. So if at least some ACK gets through, everything will get ACKed, despite of some losses of ACKs.

[ianswett]

The ACK-of-the-ACK algorithm is a recommendation, not a requirement.

[martinthomson]

@ianswett, it sounds like you have a plan here. I'm going to assign this to you. I don't think that this is critical, but it would be nice to have some of this written down (especially the bit about not being able to rely on getting an ACK for every packet that was processed by a peer).

[ianswett]

SG, happy to work on this.