Re: [tcpm] draft-ietf-tcpm-accurate-ecn-24 addressingallWGLCcomments

[Bob Briscoe <[e-mail]>]

Yoshi,

Perhaps slightly better then to modify my text as follows:

BEFORE:
    b) unless the following check has been added to all its duplicate 
detection algorithms:
AFTER:
    b) unless the following check has been added to all its algorithms 
that use duplicate detection:

I've changed the editor's copy, but I won't submit another rev at this 
stage in case there are other changes before WGLC opens.

Bob

On 06/10/2023 09:43, Yoshifumi Nishida wrote:
> Hi Bob,
>
> Thanks for the response. I think your proposed text is better.
> But, just in case, let me clarify what I tried to mention in the 
> previous text.
> The 'duplicate detection' I meant was the algorithms to check false 
> retransmissions such as DSACK, f-rto, or future algorithms for the 
> same purpose. (sorry I've used wrong term)
> These are not loss detection algorithms, but I am presuming if we feed 
> the dupacks created by ACK-on-ACK to this kind of algorithms, it might 
> confuse the logic in some ways.
> Anyways, adding checks to all related logics makes sense to me. But, I 
> also think not feeding the info for dupacks by ACK-on-ACK to them can 
> be another option although they might mean the same things in the 
> implementations.
>
> Thanks,
> --
> Yoshi
>
> On Thu, Oct 5, 2023 at 2:32 PM Bob Briscoe (IC) 
> <[e-mail]> wrote:
>
>     Yoshi,
>
>     I just realised, I should have answered your question below, when
>     I read it… see [BB]
>
>>     On 25 Sep 2023, at 10:02, Yoshifumi Nishida <[e-mail]>
>>     wrote:
>>
>>     Hi folks,
>>
>>     I think that ECN++ draft explicitly mentions that ECN on pure ACK
>>     is prohibited without SACK negotiations. (Section 3.2.3.2)
>>     BTW, I am wondering if we could update the following sentence in
>>     the ECN++ draft
>>         "If there is no SACK option on the incoming pure ACK despite
>>     SACK having been negotiated, it is not a duplicate"¶
>>     <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-12#section-3.3.3.1-2.1>
>>     by something like
>>       "If there is no SACK option on the incoming pure ACK despite
>>     SACK having been negotiated, it is not a duplicated and MUST not
>>     be used for any packet loss or packet duplication detection
>>     algorithms."
>>     Wouldn't it solve the ambiguity on ack on ack at least to some
>>     extents?
>
>     [BB] It would be fine to make it clearer.
>
>     Is your intention to explicitly add 'packet loss’ algorithms? The
>     sentence that introduces the quoted condition already says it
>     applies to tests for whether an incoming pure ACK is a duplicate.
>     I think that would be the place to say it applies to any duplicate
>     detection algorithm (whether for loss detection or any other
>     purpose, such as the ones Markku has highlighted)
>
>     But don’t you think it would be *less* clear to mention loss
>     detection explicitly, given not all loss detection uses duplicate
>     detection, and loss detection isn’t the only use of duplicate
>     detection?
>
>     But I do agree the text could be clearer. How about:
>
>
>     CURRENT:
>
>
>               3.3.3.1.
>               <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#section-3.3.3.1>Additional
>               DupACK Check
>               <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#name-additional-dupack-check>
>
>     A host MUST NOT set ECT on outgoing pure ACKs (Section 3.2.3.2
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#genecn_sec_pure_acks_accecn>)
>     unless it is in AccECN mode and SACK-negotiated mode and it adds
>     the following check when it tests whether an incoming pure ACK
>     (ECN-capable or not) is a duplicate:
>
>       * If there is no SACK option on the incoming pure ACK despite
>         SACK having been negotiated, it is not a duplicate;
>
>
>     PROPOSED:
>
>
>               3.3.3.1.
>               <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#section-3.3.3.1>Additional
>               DupACK Check
>               <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#name-additional-dupack-check>
>
>     A TCP implementation MUST NOT set ECT on outgoing pure ACKs
>     (Section 3.2.3.2
>     <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn#genecn_sec_pure_acks_accecn>)
>
>
>     a) unless it is in both AccECN mode and SACK-negotiated mode; and
>
>     b) unless the following check has been added to all its duplicate
>     detection algorithms:
>
>       * 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.
>
>
>     If I’ve missed your point, pls correct me.
>
>
>     Bob
>
>>
>>     Thanks,
>>     --
>>     Yoshi
>>
[snip]

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