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

[Jonathan Morton <[e-mail]>]

> On 23 Mar, 2022, at 3:25 pm, Gorry Fairhurst <[e-mail]> wrote:
> 
>>> 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.

> I'm not saying don't change the spec. - far from it. It's just I don't see the case why this signalling is needed to change the way a receiver works.

I would also note that ARR offers an alternative signalling method (to AccECN) for effectuating Generalised ECN, as applied to pure acks in particular.  I think ARR is conceptually and mechanically simpler for implementers than AccECN is.

 - Jonathan Morton