Re: [tcpm] Why draft-gomez-tcpm-ack-rate-request?

[Jonathan Morton <[e-mail]>]

> On 23 Mar, 2022, at 2:00 pm, Gorry Fairhurst <[e-mail]> wrote:
> 
> Thanks again for raising questions about ACK traffiuc - I'm quite passionate we look again at AcK traffic volume and rate.
> I've just reread and I'm still quite skeptical this is the right solution - look forwrad to the talk.
> 
> Why is this so important to use a TCP option to signal, rather than just specify a better method? 
> 
> 1. An option increases the probability that someone might block/change the option on path.

This sounds like a counterproductive argument to me.  I believe we should be trying to *reduce* the amount of ossification inherent to the interaction of IETF protocols with overzealous middleboxes.  If this option is blocked en route, the transport will fall back to the typical delayed-ack behaviour, so there should be little if any harm.

> 2. Any receiver that sees this option has anyway to decide how to process ACKs - and mkight also need to deal with offload.
> - The use-case for IOT might not need an option:
> For receivers that see one segment/RTT then ACKing each segment immediately seems reasonable. Sending 2 segments would make anyway have this effect.
> When would you not wish to send fewer ACKs?

There are cases where the sender wants to receive more frequent acks in order to infer things about the network path, particularly for advanced congestion control algorithms.  IoT senders would also benefit from the ability to operate efficiently with single-MSS congestion windows, which is most easily achieved by explicitly signalling this intent to the receiver.  Without ARR, the only mechanism for this is the PSH flag, which is not defined with the required on-the-wire meaning, but instead indicates desired behaviour for the receiving socket API.

> 3. The use cases for asymmetry or processinbg load might not need an option:
> I don't understand the motive here, in QUIC some have been using one ACK every ~10 packets 
> in some implementations (wuth whatever caveat to do something differenet for the first ~100 packets). 
> I'd like to argue this is enough "control" for most cases, and not so much "ACK traffic" in many cases where that matters. 

There's about a 25:1 ratio between the size of a data-segment packet and an ack packet in IPv4 - and it's closer for IPv6.  This makes it relatively easy for modern traffic patterns to cause congestion on the smaller direction of an asymmetric-capacity link to limit practically available capacity in the other direction, with today's delayed-ack specifications which effectively require one ack for every two data segments.

Existing solutions to this problem are not at all elegant.  One relies on a side-effect of current NIC hardware releasing batches of received packets, all of which may be acked as a unit.  Another relies on some middlebox actively dropping acks when it decides that too many are passing through it - which is inefficient on several levels simultaneously.  ARR puts some control over this back in the hands of the transport endpoints, and may even result in a reduction of power consumption and shared-medium contention.

 - Jonathan Morton