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

[Bob Briscoe <[e-mail]>]

Gorry,

On 23/03/2022 13:25, Gorry Fairhurst wrote:
> On 23/03/2022 14:06, Jonathan Morton wrote:
>>> 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.
> Which IETF CC needs this?

[BB] Chicken and egg:
* CC is unilaterally deployed at one end.
* Without a 2-ended protocol like TARR, no CC that needs a facility like 
TARR can be implemented.
If we use a chicken and egg criterion like your question, we'll never 
get chickens or eggs.

A Data Point:
     To use paced chirping at the sender, we had to manually disable 
del-ack at the receivers in order to work well during slow start (it 
works with del-ack, just not very well).
Paced chirping was a research project, rather than an IETF CC, precisely 
because there is nothing like TARR out there.
Chicken and egg.


>>   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.
> That's my point - any system using a window of 1 MSS is a special case 
> easily noted, that does not need negotiated.

[BB] The receiver doesn't know the RTT, so 'easily' is overstated. But 
your point has some validity.

More generally, receiver heuristics are not a panacea...

Another data point from paced-chirping:
     The receiver heuristic in Linux that disables delayed acks during 
slow start doesn't work with paced chirping, 'cos it is specific to the 
pattern of slow-start packets, which is precisely what we were trying to 
improve on with paced chirping (i.e. the Linux heuristic has ossified 
slow-start, which is why we need sthg like TARR to override it).


Bob

>> 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
> 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.
>
> Gorry
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/