Re: [tcpm] ECN++ on Pure ACKs if SACK stripped

[Bob Briscoe <[e-mail]>]

Neal,

I've brought your last comment to the beginning, as the rest depends on it.

On 25/11/2023 00:06, Neal Cardwell wrote:
> AFAICT a third viable strategy is: when SACK has been negotiated, only 
> consider an ACK a dupack if it includes SACK blocks. This is the 
> approach taken by the Linux TCP stack.
>
> AFAICT if that strategy is used, then the TCP endpoint doesn't need to 
> try to guess if SACK blocks are being stripped, if it is willing to 
> pay the performance penalty if this does happen.

[BB2] This is where we started from in July (the nice simple additional 
DupACK test to distinguish DupACKs from ACKs of ACKs that is in the 
current draft - and black rather than green below - HTML email reader 
required).

But since March, just before each draft submission, Markku has been 
promising to explain his concern, which he finally did the day after the 
recent tcpm meeting. First it was that SACK-negotiated doesn't 
necessarily imply that D-SACK is implemented. We addressed that by 
requiring D-SACK if SACK is negotiated for AccECN. Then the argument 
switched to the possibility that SACK might be stripped, which the 
latest text addresses (in green below - for the ECN++ draft). That might 
not sound much, but it took 8 months and approaching 100 emails to get 
to the consensus we have reached (TBC). Nonetheless, if an implementer 
like you is prepared to take the performance penalty, the added (green) 
text is a 'SHOULD' not a 'MUST'.

On your detailed points - see more [BB2]...
I'll also send another email after this with new proposed text, 'cos 
while making your proposed edits, I noticed a number of ways to make my 
original less wordy.

>
> On Fri, Nov 24, 2023 at 6:20 PM Bob Briscoe 
> <ietf=[e-mail]> wrote:
>
>     Richard,
>
>     I think you are now agreeing with Markku, so we are close to
>     closure! See [BB]...
>
>     On 24/11/2023 17:52, [e-mail] wrote:
>>
>>
>>     Am 24.11.2023 um 16:55 schrieb Bob Briscoe:
>>>             1) Detecting that SACK blocks are being stripped
>>>
>>>     Assuming AccECN & SACK are both negotiated, is Markku's proposed
>>>     test on
>>>     an incoming pure ACK acceptable to everyone?:
>>>          if (no SACK && Δ(ACE)<3)
>>
>>
>>     I believe you want to detect DupACKs? So the generally accepted
>>     test if
>>     this ACK is a DupAck (does not advance snd.una, while there is
>>     outstanding data snd.max != snd.una) would come first?
>
>     [BB] Yes, that's taken as a given, because this test is
>     /additional/ to wherever DupACKs are tested for.
>
>>
>>     And as long as no retransmission (fast or RTO or PTO) has happened,
>>     *every* DupACK is supposed to contain a SACK block; DSACK blocks
>>     are -
>>     with the current wording - also expected on spurious retransmitted
>>     segments - and only them.
>>
>>     (the network pathology of duplicating packets on-path should elicit
>>     DSACK for packets that were never retransmitted).
>>
>>>
>>>     As I said, ACE might have wrapped, but let's treat this as an
>>>     experiment, to see whether that is a significant problem.
>>
>>     The reason why we picked 3 as a very strong suggestion is, that
>>     typical
>>     AoA  would lead to a particular stream of ACEs (e.g. 5, 0, 3, 6,
>>     1, 4,
>>     7, 2, 5) - with two consecutive AoAs need to be lost before a
>>     wrap-around becomes indistiguishable (any other pattern would
>>     need some
>>     data exchange).
>
>     [BB] I think you're agreeing, but please answer, yes or no: is the
>     test proposed above for Detecting that SACK blocks are being
>     stripped acceptable to you?
>
>>
>>
>>     But doing one step back:
>>
>>     While AccECN defines a specific receiver side reaction, which the
>>     other
>>     side can rely upon, and ECN++ specifies that pure ACKs could be
>>     ECT-enabled, as an Implementer, rather than dealing with these
>>     increasingly improbable special cases, I would refrain from
>>     sending the
>>     optional ECT-enabled ACKs in the first place. Only when subsequent
>>     mechanisms are found to be needed (e.g. TARR, NewCWV,
>>     Careful-Resume,
>>     ...) where retaining up-to-date CC state in the reverse direction is
>>     becoming more interesting, it would become interesting to send out
>>     ECT-enabled ACKs.
>
>     [BB] So, I take it from this that you agree that, if SACK
>     stripping has been detected, the spec has to allow both. That is:
>     * either disable ECN-capable pure ACKs,
>     * or replace the test for absence of SACK with a heuristic.
>
>     Here's proposed text for the ECN++ spec. I'm afraid I'm asking you
>     to fill in text for the timestamp test in the final bullet. I
>     can't easily work out what to say that generalizes for any case,
>     not just the TLP case. Pls (anyone) also suggest edits if you
>     disagree with anything else...
>
>
>     3.3.3.1.  Additional DupACK Check
>
>        A TCP implementation that is sending ECN-capable pure ACKs MUST add
>        the following check to all its algorithms that use duplicate
>        detection on incoming pure ACKs:
>
>        *  If there is no SACK option on an incoming pure ACK
>     (ECN-capable or
>           not) despite SACK having been negotiated, it is not counted as a
>           duplicate ACK.
>
>     SACK blocks are known to be stripped on some paths through the public
>        Internet, or some implementations are known to negotiate SACK but
>        never send SACK blocks.  Therefore, if a TCP implementation is
>        sending ECN-capable pure ACKs, it SHOULD check for these
>     pathologies
>        (unless it is intended solely for an environment clear of these
>        pathologies), as follows:
>
>        *  If an incoming pure ACK appears to be a duplicate (it does not
>           advance the cumulative acknowledgement while there is
>     outstanding
>           data), but:
>
>
> That parenthetical definition of a duplicate ACK is incomplete. To 
> avoid bugs, I would suggest referring the reader to the full 
> definition in RFC 5681, Section 2.

[BB2] Thanks for this ref. I'll refer to that definition right from the 
start, and delete the parenthesis.

>
>           -  it does not carry any SACK blocks (despite SACK having been
>              negotiated)
>
>           -  and AccECN [I-D.ietf-tcpm-accurate-ecn] has been
>     negotiated but
>              the ACE field has increased by less than 3 (after
>     allowing for
>              wrap)
>
>
>           then it can be assumed that SACK blocks are being stripped.  In
>           this case the implementation SHOULD take one of the
>     following two
>           actions:
>
>
> Rather than "it can be assumed that SACK blocks are being stripped" I 
> would suggest "then the implementation can estimate that SACK blocks 
> are being stripped".

[BB2] Better. But 'estimate' isn't quite right - it's used more for 
numerical output, so I'll use 'deem' if that's OK.

Thanks



Bob

>
>           -  either disable the sending of ECN-capable pure ACKs;
>
>           -  or in all algorithms that use duplicate detection on incoming
>              pure ACKs, replace the above additional DupACK check with an
>              heuristic such as the following:
>
>              o  If the ACE field [I-D.ietf-tcpm-accurate-ecn] has
>                 incremented by at least 3, an incoming ACK SHOULD NOT be
>                 counted as a Duplicate ACK;
>
>              o  if the echoed timestamp (TSecr) [RFC7323] {ToDo: complete
>                 the bullet}, an incoming ACK SHOULD NOT be counted as a
>                 Duplicate ACK.
>
>
>
>
> best regards,
> neal
>
>
>     Thank you
>
>
>     Bob
>
>
>>
>>     Richard
>
>     -- 
>     ________________________________________________________________
>     Bob Briscoehttp://bobbriscoe.net/
>
>     _______________________________________________
>     tcpm mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tcpm
>

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