Re: [tcpm] Summary of diffs in new version: draft-ietf-tcpm-generalized-ecn-13

Bob,

I have a nit with the wording here:

Sec 3.3.3:

    If there is no SACK option on an incoming pure ACK (ECN-capable or
    not) despite SACK having been negotiated, it is not a duplicate.

I believe the 2nd part of the sentence ought to say:

    it must not be considered to be, or counted against duplicate ACKs.

(there may be fringe cases, where the ACK was sent with SACK, but the SACK was stripped subsequently by middlebox interference).

So, technically, there could be true DupACK (arriving without SACK blocks any more) which must be ignored as such (and if this is a persistent pathological network environent, the session would suffer severe performance implications) for the purpose of ECN++.

Also, section 4.4.4:

    Use of ECN-capable pure ACKs by the ECN++ experiment combined with
    congestion at an ECN AQM at the bottleneck of the ACK path can cause
    AccECN to acknowledge ACKs, by the above rule.  This leads to
    repetition of the ACK of a segment, which is an exception to the
    requirement in the last paragraph of Sec 4.2 of [RFC5681].

The first sentence: You are not acknowledging the ACK by itself; you are notify the receipt of 'n' CE marks since the last ACK was sent by the receiver. The 2nd sentence is correct though.

maybe:

    can cause AccECN to notify the sender of the changes in observed CE
    marks, by the above rule.

or

    acknowledge ACKs with updated CE information, by the above rule.

The remainder of the section with the detailed explanation reads good IMHO.

Thanks,

   Richard

Am 24.10.2023 um 00:17 schrieb Bob Briscoe:
> tcpm,
>
> We've just posted a new rev of draft-ietf-tcpm-generalized-ecn-13
> You can find a link to the full diff below. Here's a summary:
>
> Normative:
>
>   * Changed §3.3.1 "Additional DupACK Check" to solely specify the Additional DupACK Check by the *receiver* of an incoming Pure ACK, and only refer to the other conditions for *sending* an outgoing ECN-capable pure ACK in §3.2.3.2 (rather than re-stating them).
>
> Editorial
>
>   * Reversed the rather confusing logical flow of all the sentences which said (paraphrasing) "You can ignore the prohibition in Section abc of RFC3168 against setting ECT on an xyz packet, as per Section 4.3 of RFC8311". Replaced with "Section 4.3 o RFC8311 allows setting ECT on an xyz packet, by updating Section abc of RFC3168".
>   * Considerable edits to the rationale in §4.4.4 "Pure ACKs: DupACK Tests", to explain why an exception to the RFC5681 rule against repeating acknowledgement of a segment is necessary in this case, and adding each step of the example, rather than glossing over some that seemed obvious (to the authors) in the previous version.
>   * Changed the description of the individual draft specifying ECN in SCTP, now that it has been updated (for the first time since Jan 2014).
>   * Updated the ref to CUBIC now it has been published as an RFC.
>
>
>
> Bob
>
> On 23/10/2023 22:46, internet-drafts@ietf.org wrote:
>> A new version of Internet-Draft draft-ietf-tcpm-generalized-ecn-13.txt has
>> been successfully submitted by Bob Briscoe and posted to the
>> IETF repository.
>>
>> Name:     draft-ietf-tcpm-generalized-ecn
>> Revision: 13
>> Title:    ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control Packets
>> Date:     2023-10-23
>> Group:    tcpm
>> Pages:    51
>> URL:https://www.ietf.org/archive/id/draft-ietf-tcpm-generalized-ecn-13.txt
>> Status:https://datatracker.ietf.org/doc/draft-ietf-tcpm-generalized-ecn/
>> HTML:https://www.ietf.org/archive/id/draft-ietf-tcpm-generalized-ecn-13.html
>> HTMLized:https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn
>> Diff:https://author-tools.ietf.org/iddiff?url2=draft-ietf-tcpm-generalized-ecn-13
>>
>> Abstract:
>>
>>     This document specifies an experimental modification to ECN when used
>>     with TCP.  It allows the use of ECN in the IP header of the following
>>     TCP packets: SYNs, SYN/ACKs, pure ACKs, Window probes, FINs, RSTs and
>>     retransmissions.  This specification obsoletes RFC5562, which
>>     described a different way to use ECN on SYN/ACKs alone.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm