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

[Bob Briscoe <[e-mail]>]

Jonathan, Carles, [This email was prepared in Mar'22, but apparently I 
never clicked send - mea culpa, mea maxima culpa]

On 25/03/2022 15:42, Jonathan Morton wrote:
>>>> 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.
>> [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.

[BB] Put simply, yes, negotiating TARR during the handshake could allow 
ECT to be used on pure ACKs, then the combination of ECT and TARR could 
be used for ACK congestion control, as well as the other uses of TARR 
(immediate ACK'ing, reducing unnecessary ACK processing).

This is the same as ACK-CC [RFC5690], which allows ECT to be used on 
ACKs as part of ACK congestion control. In fact, TARR as a protocol is 
rapidly becoming nearly identical to RFC5690. Even though it was 
originally motivated by other use-cases. Indeed, I suspect we are close 
to reaching the point where we suggest that RFC5690 would suffice for 
the use-cases that ack-pull and TARR were for (except it contains some 
constraints on the ACK ratio that might need to be updated).

I'm sorry to Carles if he's been given the run-around. I and others 
suggested he generalized his original ACK pull request to an ACK rate 
request, and none of us noticed that there was already RFC5690 at the 
end of that path.

[BTW, the problem with your original posting was that you were trying to 
side-swipe at AccECN and ECN++ to the extent that you omitted to say 
what you *were* talking about: ACK congestion control. So we all had to 
"read something you didn't write," to work this out. The result was just 
confused readers, and a failed side-swipe.
You didn't need to mention AccECN or ECN++ at all. Because "effectuating 
Generalised ECN, as applied to pure acks in particular" was just a 
circuitous way of saying "enabling ECN on pure ACKs." And when you were 
looking for "an alternative signalling method (to AccECN) for 
effectuating...", you just meant a way to negotiate an ACK-CC scheme.  ]

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

[BB] You say you need "The detection of ack-losses or ECN signals". This 
is precisely the "measurement in the other direction" that I say you 
haven't got with TARR alone. Taking each in turn...

1) ACK-losses. The data sender could only detect ACK losses if:

     a)  it can be sure that the data receiver never stretches ACKs 
wider than the requested ACK ratio. In the -03 draft (at my suggestion 
actually) the data receiver only "SHOULD" abide by the ack rate request, 
so if it stretched the ACKs because it had insufficient resources (e.g. 
under attack) the data sender would confuse this to be ACK loss and tell 
it to slow the ACK rate. Although the protocol fails for a while during 
this process, at least it self-heals.

     b) it can be sure that middleboxes (WiFi, CAKE, DOCSIS, satellite 
links, etc) are not thinning ACKs. Unfortunately, if there's ACK 
thinning, the data sender falsely detects ACK-loss, and tells the data 
receiver to slow the ACK rate. That might cause some ACK filters to thin 
fewer ACKs, and eventually self-heal. But that's often not going to be 
true - the degree to which many ACK filters remove ACKs changes all the 
time. For instance many WiFI boxes coalesce ACKs until they get a 
transmit opportunity. At the other extreme, ACK decimation might remove 
a fairly fixed proportion of the ACKs. This would not self-heal.

         I don't think many/all of these ACK filtering behaviours were 
around when the ACK-loss-detection techniques were written in RFC5690.

2) ECN
A data sender cannot detect ECN signals on ACKs unless they are set to 
ECT. It would be possible for a future draft of the TARR spec to allow 
ECT on ACKs once TARR has been negotiated in the handshake. That was why 
I said that TARR would need "the measurement in the other direction". 
TARR *today* doesn't do this.

> In other words, TARR could be tried *today* - even without ECN++, and certainly without AccECN.

[BB] Yes. AFAIK, no-one has ever mentioned ECN++ or AccECN in relation 
to TARR.

> As a signalling mechanism, TARR is, in fact, sufficient on its own to implement Ack CC.

[BB] Yes. No-one was saying otherwise (except, as I said, the TARR draft 
would need to add the measurement channel, by allowing ECT on ACKs once 
TARR is negotiated).
Or, given you are only interested in ACK-CC, just use RFC5690, which 
already does and says all this.

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

[BB] Yes.

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

[BB] Yes. And it assumes that the TARR draft will add that endpoints 
supporting TARR can set ECT on pure ACKs. Or just use RFC5690.


Bob

>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/