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

[Bob Briscoe <[e-mail]>]

Richard, Markku, Neal,

In discussion between the co-authors, we've agreed that it should not be 
implied there is only one alternative heuristic to disabling ECN-capable 
pure ACKs, if SACK is being stripped.

So, I've annotated the previously proposed text below with newly 
proposed changes (see [BB2]).
If I don't hear any further suggestions by the end of today (UK time), I 
will post this as a new revision to ECN++.

I believe this will then complete everything Markku suggested for ECN++ 
and therefore no further changes are required to AccECN either.

I haven't seen Markku taking part in the discussion for a while. But, 
once we update the ECN++ draft, it will be clear what is proposed, and 
he can react during the ECN++ WGLC if he wants to.

See [BB2] ...


On 27/11/2023 09:01, [e-mail] wrote:
>
> Hi Bob,
>
> > [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?
>
>
> It is; also, I like that the wording is SHOULD - after all, not doing
> this causes self-inflected problems on this particular session.
>
> I also agree with Neals observation - that when SACK is being used, the
> heuristics to detect DupACKs are all only working in presence of SACK
> blocks. As on-path duplication of packets can happen not only to data
> segement, but ACKs as well...
>
> > [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.
>
>
> For some reason, I feel the text just prior to the delta-ACE >= 3 to be
> too exclusive to other approaches (like validating, that when the TSecr
> value increments between "DupACKs", the latter is NOT a DupACK - with
> the caveat that the time granularity of timestamps may not be sufficient
> to always differentiate this case).
>
> FWIW - I went with the heuristic of delta-ACE >= 3 and no SACK block
> present to exclude any DupACK processing, while other potential DupACKs,
> with or without SACK blocks, are processed normally.
>
> This does not address the very very special case of a true DupACK
> following exactly 2 ACE-ACKs (AoA), but as the stack needs a minimum of
> 3 DupACKs, and the two AoA in Markkus example had been excluded in the
> DupACK processing, a singular DupACK hardly ever elicits a response
> (Early Retransmit), and any subsequent data packet would become a proper
> DupACK right away.
>
> Thanks,
>   Richard
>
>
>
>
>
> Am 25.11.2023 um 12:58 schrieb Bob Briscoe:
>> Richard, Markku, Neal, list and chairs,
>>
>> As promised in the previous email, I've cut out unnecessary verbiage
>> from the proposed new text (green) for the additional DupACK test in the
>> ECN++ draft.
>>
>> I've also cut the example heuristic using timestamps, which solely
>> applied to the special case just within TLP, so it would have required a
>> whole load of explanation of TLP and the special case problem. This
>> leaves just one example alternative heuristic, which applies generally
>> (as it's only an example, an implementer can do something else like
>> timestamps if they choose).
>>
>> So, I believe this contains what Markku proposed, and what I think
>> Richard will agree to, as well as Neal's suggestions:
>> ------------------------------------------------------------------------
>>
>>
>> 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 detect duplicate ACKs
>>     (defined in Section 2 of [RFC5681]):
>>
>>     *  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 known to be 
>> clear of
>>     them), as follows:
>>
>>     *  If an incoming pure ACK appears to be a duplicate, but:
>>
>>        -  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 the implementation can deem that SACK blocks are being
>>        stripped.  In this case, for the rest of the connection, it
>>        SHOULD:
>>
>>        -  either disable the sending of ECN-capable pure ACKs;
>>
>>        -  or use heuristics such as the following in place of the
>>          additional DupACK check in the very first bullet above:
>>
>>           o  If the ACE field [I-D.ietf-tcpm-accurate-ecn] has
>>              incremented by at least 3, an incoming ACK is not counted as
>>              a duplicate ACK. *
>> *

[BB2] NEWLY PROPOSED:
-  or replace *any instance of* the above additional DupACK check
            with heuristics such as the following *examples*:

           o  If the ACE field [I-D.ietf-tcpm-accurate-ecn] has
              incremented by at least 3, an incoming ACK is not counted as
              a duplicate ACK.
*          o if the Timestamp option (TSopt) is available [RFC7323], and
               the echoed timestamp (TSecr) increments relative to the
               previous ACK, an incoming ACK is not counted as a
               Duplicate ACK.*


Bob
>> ------------------------------------------------------------------------
>>
>>
>> Bob
>>
>> On 25/11/2023 11:45, Bob Briscoe wrote:
>>> 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/
>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoehttp://bobbriscoe.net/
>>

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