Re: [tcpm] AccECN and SACK

[Bob Briscoe <[e-mail]>]

Richard, Michael, tcpm, see [BB]

On 11/11/2023 09:05, [e-mail] wrote:
>
> Similar to the timestamps question, this appears to be a non-issue.
>
> SACK blocks can only ever be sent, when there is data missing in the 
> sequence space. In theory this includes the special TCP header flags 
> of SYN and FIN, but the former won't ever be in a SACK block (as SACK 
> won't have been declared to be supported by both ends prior of the 
> receipt of the SYN-ACK), and for the FIN bit, it is very uncommon to 
> have additional data beyond that (this consitutes a violation of 
> RFC9323).
>
> In short, pure control packets, such as ACKs, will never be covered by 
> SACK block; if a return volley of data packets happens while ACE-ACKs 
> may still be coming back, SACK blocks will be included.
>
> Again, the various SACK-related RFC, starting from RFC2018 onwards, 
> already stipulate all this.
>
> There is nothing here to change any text in any RFC or Draft to do 
> exactly what is described here.
>
> Best regards,
>    Richard
>
>
> Am 10.11.2023 um 21:19 schrieb [e-mail]:
>> Dear list,
>>
>> this e-mail triggers the discussion of the second issue described in 
>> Markku's recent e-mail:
>>
>> 2. AoA Sender:
>>       If SACK is enabled, MUST not include a SACK option when acking a
>>       pure Ack. In addition, the spec must include a description /
>>       explanation that this is an exception (UPDATE) to RFC 2018 rule
>>       in Sec 4 that requires including SACK option in all Acks which do
>>       not ack the highest sequence number that has arrived at the
>>       receiver.
>>
>>     Reasoning:
>>       RFC 2018 only provides rules for acking data segments and the
>>       rules become ambiguous/are in conflict with RFC 2883 when
>>       implementing Acks of Acks because RFC 2018 requires including
>>       the SACK option in most of the cases.

[BB] Markku is correct when he says that ACKs or ACKs have never been 
discussed in any RFCs. So, irrespective of whether anyone thinks there 
is a scenario where a sender would set SACK on an AoA, it would surely 
do no harm for the AccECN spec to require that "These ACKs of ACKs MUST 
NOT include any SACK blocks"? So I've proposed a rearrangement of the 
last para of §3.2.2.5.1 below.


            3.2.2.5.1.
            <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.2.5.1>Data
            Receiver Safety Procedures
            <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#name-data-receiver-safety-proced>

CURRENT:

    ...
    Certain measures are necessary to prevent incoming ACKs of ACKs
    being mistaken for duplicate ACKs in some circumstances. However,
    ACKs of ACKs can only arise if the original ACKs are ECN-capable.
    Therefore, it is not appropriate to define those measures here.
    Instead any spec that allows ECN-capable pure ACKs MUST make
    sending them conditional on measures to distinguish ACKs of ACKs
    from DupACKs (see for example [I-D.ietf-tcpm-generalized-ecn 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-14>]).

PROPOSED:
    ...
    In the above bidirectional scenario, incoming ACKs of ACKs
    could be mistaken for duplicate ACKs. But ACKs of ACKs can be
    distinguished from duplicate ACKs because they do not contain any
    SACK blocks even when SACK has been negotiated. It is outside the
    scope of this AccECN spec to normatively specify this additional
    test for DupACKs, because ACKs of ACKs can only arise if the
    original ACKs are ECN-capable. Instead any spec that allows
    ECN-capable pure ACKs MUST make sending ACKs of ACKs conditional
    on measures to distinguish ACKs of ACKs from DupACKs (see for
    example [I-D.ietf-tcpm-generalized-ecn 
<https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-generalized-ecn-14>]). 
All that is necessary
    here is to require that these ACKs of ACKs MUST NOT contain any
    SACK blocks (which would normally not happen anyway).


Bob


>>
>> Best regards
>> Michael
>>
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

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