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

[Bob Briscoe <[e-mail]>]

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


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/