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

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 23 Mar 2022 13:00:26 +0100

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.
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?
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.

I'll look forward to seeing the slides and udnerstanding more,

Gorry

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 23 Mar 2022 15:06:47 +0200

> On 23 Mar, 2022, at 2:00 pm, Gorry Fairhurst <[email-masked]> wrote:
> 

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.

> 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.

> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 23 Mar 2022 14:25:56 +0100

On 23/03/2022 14:06, Jonathan Morton wrote:
> 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?
>   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.
> 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.
>
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

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 23 Mar 2022 15:41:54 +0200

> On 23 Mar, 2022, at 3:25 pm, Gorry Fairhurst <[email-masked]> wrote:
> 

> 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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Mar 2022 16:18:38 +0000

Jonathan

>> 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 mechanicall…

[BB] If I read between the lines, I believe you are categorizing the 
combination of AccECN and generalized-ecn (ECN++) as just one very 
narrow application of them: ACK congestion control. Although the 
combination of AccECN and ECN++ makes ACK-CC possible, that wasn't one 
of the original motivations for either.*

Whatever, if we run with this narrow focus, TARR wouldn't be enough to 
deploy ACK CC. It solely gives the control signal, not the measurement 
in the other direction that would be needed to drive that control.

To be clear, I believe TARR is useful, I'm just saying it's not 
sufficient on its own for ACK CC, which seems to be what you are 
referring to here.

Bob

* Primary motivations:
     AccECN: robust feedback of the extent of ECN marking, not just its 
existence within one round trip, which is all RFC3168 feedback allows.
     ECN++: allowing TCP control packets and retransmissions to benefit 
from being ECN-capable.

>>
>>   - Jonathan Morton
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm

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

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Mar 2022 16:51:20 +0000

Gorry,

On 23/03/2022 13:25, Gorry Fairhurst wrote:
>>> Thanks again for raising questions about ACK traffiuc - I'm quite 
>>> passionate we look again at AcK traffic volume and rate.
>> 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.
>>> For receivers that see one segment/RTT then ACKing each segment 
>>> immediately seems reasonable. Sending 2 segments would make anyway 
>>> have this effect.
>> 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.

[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.

[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.
>>
>>> 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
> see the case why this signalling is needed to change the way a 
> receiver works.
>
> Gorry
>

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 25 Mar 2022 17:42:58 +0200

> [BB] If I read between the lines, I believe you are categorizing the combination of AccECN and generalized-ecn (ECN++) as just one very narrow application of them: ACK congestion control. Although the combination of AccECN and ECN++ makes ACK-CC possible, that wasn't one of the original motivations for either.*

You're reading something that I didn't write.  I don't need to comment on the goals or applicability of AccECN here, only those of ECN++ and TARR.

> Whatever, if we run with this narrow focus, TARR wouldn't be enough to deploy ACK CC. It solely gives the control signal, not the measurement in the other direction that would be needed to drive that control.

Ack CC would be triggered by the detection of ack-losses or ECN signals on the acks.  These acks travel in the opposite direction to data segments, ie. from the "receiver" to the "sender".  TARR allows the sender, which is in a position to observe these losses or ECN markings *and* knows what the data-oriented CC algorithm needs, to inform the receiver what density of acks it is desirable for the receiver to send.

In other words, TARR could be tried *today* - even without ECN++, and certainly without AccECN.  As a signalling mechanism, TARR is, in fact, sufficient on its own to implement Ack CC.

As you note, ECN++ intends to allow the use of ECT on TCP ack and control packets, not just data segments, as well as on retransmitted data segments which are presently sent Not-ECT.  ECT implies, to the network, that the endpoints will use explicit congestion signals (ie. CE marks) to reduce traffic volume on the flow and in the direction that the marks were applied in the network.  Presently, TCP only does that for data segments (as per RFC-3168).

TARR adds a mechanism for an appropriate congestion response for CE marks applied to TCP acks.  This is completely in keeping with ECN++ goals.  Hence, the successful negotiation of TARR could be taken as sufficient to permit setting ECT on pure acks, if not the other cases as well.  This assumes, of course, that an appropriate Ack CC response is either written into TARR, or is explicitly implied by its presence.

 - Jonathan Morton