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

[Yoshifumi Nishida <[e-mail]>]

Hi Bob,

Thanks for the comments. I am fine with the updated texts.
If other folks have thoughts on this, please share!
--
Yoshi

On Fri, Oct 6, 2023 at 7:42 AM Bob Briscoe <[e-mail]> wrote:

> 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 Briscoe                               http://bobbriscoe.net/
>
>