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

["Scheffenegger, Richard" <[e-mail]>]

I want to point out, that RFC5690 is NOT a finalized document which
would be ready for implementation.

Among other aspects, no TCP option has been assigned at the time, and
some things would be done differently today (no separate SYN option ID,
maybe as an advisory not even require a SYN option at all...)

So if this is the direction this functionality takes, to revive the
RFC5690 work, those details still need to be fleshed out. Thus the
discussions were not in vain, and ultimately a document replacing
RFC5690 is still needed.

Richard


Am 29.07.2022 um 17:59 schrieb Bob Briscoe:
> 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
>