MUST NOT bundle, etc.

[ekr]

A receiver MUST NOT bundle an ack-eliciting frame with packets that would
otherwise be non-ack-eliciting, to avoid an infinite feedback loop of
acknowledgements.

This text seems weird. Suppose I have an implementation which tries to send out data packets on a specific clock (e.g., one per second). This isn't totally unrealistic for media. Now suppose my ACK delay timer fires and I want to send an ACK. This text would prohibit my from sending the data packet early to save packets. Surely that's not what's intended.

[huitema]

I think this is in reaction to the practice of bundling a ping with an ack to trigger an ack of ack. Yes, if both peers bundle a ping with every ack you would get an infinite ping pong. But you would have to be crazy to do that. Plus, bundling a ping with every Nth ack for N > 1 is actually a good way to trigger ack of ack.

[martinthomson]

This has always been hard to capture. In short, you can't only send ack-eliciting packets to acknowledge.

An endpoint MUST NOT send packets that are exclusively ack-eliciting as this can result in an infinite feedback loop. It is necessary to send packets that are not ack-eliciting to allow the connection to become idle.

[huitema]

@martinthomson I think part of the issue is the double negation in "MUST NOT send packets that are exclusively ack-eliciting", which makes it kinda hard to grasp by non-natives. Something like "end points MUST NOT force all their packets to elicit an acknowledgement" would be easier.

[martinthomson]

So the above or below is OK?

An endpoint MUST NOT send only ack-eliciting packets as this can result in an infinite feedback loop. It is necessary to send packets that are not ack-eliciting to allow the connection to become idle.

[huitema]

No, I don't think that works. You are speaking of generic ack-eliciting packets, or not, but the problem is much better described and understood if you make a specific statement about ack, ack of ack, and ack loops. You may want to generalize after that to other non ack eliciting frames, but the only such in the main spec are path challenges, so that's not a very high priority.

[ianswett]

It's not really the bundling that's the issue, but the idea that one shouldn't send extra ack-eliciting frames when sending an ack.

This isn't shorter, but how about:
"A receiver MUST NOT generate and bundle an ack-eliciting frame with packets that would
otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements."

[ekr]

On Wed, Jul 8, 2020 at 2:04 PM ianswett ***@***.***> wrote: It's not really the bundling that's the issue, but the idea that one shouldn't send extra ack-eliciting frames when sending an ack. This isn't shorter, but how about: "A receiver MUST NOT generate and bundle an ack-eliciting frame with packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements." You are receiving this because you authored the thread.

I feel like this has the same problem as before. I would suggest that part of the issue here is that we are trying to make something really crisp. Looking at the rest of the graf, where we actually endorse this practice, I suggest we do: A receiver that sends only non-ack-eliciting packets, such as ACK frames, might not receive an acknowledgement for a long period of time. This could cause the receiver to maintain state for a large number of ACK frames for a long period of time, and ACK frames it sends could be unnecessarily large. In such a case, a receiver could bundle a PING or other small ack-eliciting frame to elicit an ACK from the peer. Caution: If receivers add additional ack-eliciting frames to every ACK, this would create an infinite feedback loop of acknowledgements. Therefore, receivers SHOULD only do this occasionally, such as once per round trip.

[huitema]

Alomost there. I like EKR's text, except for the once per round trip part. Don't do that, because it leads to a loop of round trip period.

[ekr]

On Wed, Jul 8, 2020 at 5:00 PM Christian Huitema ***@***.***> wrote: Alomost there. I like EKR's text, except for the once per round trip part. Don't do that, because it leads to a loop of round trip period

That 1-RTT thing came from the previous text, so I was just retaining it. I have no personal opinion.

[MikeBishop]

I also touched this text in #3805; there was previously an "all" that dramatically changes the meaning of the restriction that got dropped somewhere, so I put it back.

A receiver MUST NOT send an ack-eliciting frame in all packets that would otherwise be non-ack-eliciting, to avoid an infinite feedback loop of acknowledgements.

The point is that it's okay to toss a PING in to your ACK-only packets once in a while so you can clear out old ACK ranges, but you shouldn't do that every time you send an ACK.

[martinthomson]

For some reason, this text is already in the draft. I note that @huitema's concern about 1-RTT looping remains. I'm going to close this and let those who want to deal with the looping do so (that smells a little design-y, unfortunately).