Re: [tcpm] AccECN and SACK

[Bob Briscoe <[e-mail]>]

Markku,

We can all ignore your two responses to RS, because in one you continue 
arguing a point that RS conceded long ago, and in the other you admit 
yourself that the argument you're continuing is irrelevant.

Then, we can all ignore the long tract (5015 bytes) about the 
possibility that a newbie will misunderstand the SACK & D-SACK specs, 
because the logic of your argument argues against itself, as explained 
if readers jump to my first inline comment (tagged [BB2])...


On 01/12/2023 20:46, Markku Kojo wrote:
> Bob, Richard, all,
>
> pls see inline below (tagged [MK]).
>
> On Mon, 13 Nov 2023, Bob Briscoe wrote:
>
>> 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
>
> [MK] Unfortunately this is an incorrect claim. SACK blocks are also 
> sent when dupilicate data segments arrive even if there is no data 
> missing in the sequence space.
>
>>       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).
>
> [MK] Sorry, but I don't quite understand this claim for the FIN flag. 
> A segment with FIN flag set may carry a SACK option and an ACK 
> triggered by an arriving FIN segment may carry a SACK option as well 
> (and the ACK may have also FIN flag set). And the sequence number that 
> FIN eats may be covered by the SACK block in the ACK acking the FIN. 
> Maybe I am missing something you intended to say? But I think this is 
> somewhat irrelevant for the discussion at hand.
>
>>       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.
>
> [MK] I do not disagree but this has not been clearly specified 
> anywhere. Pls see below.
>
>>       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.
>
> [MK] So, we agree with adding this MUST NOT. Just at the time of 
> writing down the text below I realized that by not including any SACK 
> option in ACKs of ACKs is not necessarily the best option. I've 
> suggested some modifications to the proposed text around this MUST 
> NOT. Please see below under Bob's proposed text and to understand the 
> better alternative for "MUST NOT" please see the explanation starting 
> right below.
>
> [MK] First, I'd just like to clarify why acking ACKs makes RFC 2018 
> text ambiguous and I think someone may get confused and set SACK 
> block(s) on an AoA when reading RFC 2018 (remembering that not all 
> implementers are necessarily experienced TCP experts).
> I agree that it should become quite clear to me and you as a some sort 
> of TCP expert that when reading RFC 2018 it does not make much sense 
> to set any SACK blocks on an AoA DupAck (at least as a first thought). 
> However, a non-expert may not notice this because acking ACKs is not 
> specifically defined and AoAs make the RFC 2018 rules ambiguous and 
> they become contradictory to each other.
>
> RFC 2018 (Sec 4) states the following rules for generating SACK 
> options (numbering is added by me):
>
>  #1:
>   "If the data receiver generates SACK options under any circumstance,
>    it SHOULD generate them under all permitted circumstances."
>
>  and continues #2:
>   "If sent at all, SACK options SHOULD be included in all ACKs which do
>    not ACK the highest sequence number in the data receiver's queue."
>
>  and adds also:
>
>   "If the data receiver chooses to send a SACK option, the following
>    rules apply:
>
>  #3:
>   "* The first SACK block (i.e., the one immediately following the
>    kind and length fields in the option) MUST specify the contiguous
>    block of data containing the segment which triggered this ACK,
>    unless that segment advanced the Acknowledgment Number field in
>    the header."
>
>     ...
>
> #4:
>  "* The SACK option SHOULD be filled out by repeating the most
>   recently reported SACK blocks (based on first SACK blocks in
>   previous SACK options)
>
> In addition, RFC 2883 complements the above RFC 2018 rules by stating 
> that an arriving duplicate data segment triggers an ACK with DSACK 
> even if the cumulative ack no acks the highest sequence number.
>
> When acking ACKS the rules #1, #2, and #4 basically still make full 
> sense while the rule #3 becomes ambiguous and it is also to some 
> extent in conflict with the other rules. What we need to remember is 
> that there are a multitude of TCP stacks other than the major stacks 
> which are implemented and developped by people who work more or less 
> full time on solving these issues and have a very good understanding 
> what the intended TCP behavior is and what are the potential 
> implications between different implementation options they have to 
> choose from. We should not worry much about the major stack 
> implementers when writing the specs. Instead, the developpers of the 
> other stacks may often be in a quite different position; it may be 
> that sometime later a skilled enough programmer is assigned a task to 
> implement AccECN on a stack that she/he has not been involved in 
> earlier and that the task is her/his first programming task on any 
> network stack (i.e, she/he is not expert in networking). Yes, AFAIK 
> there are more and more such stacks being developped like this. When 
> such a programmer gets the task, the only information she/he has is 
> what reads in the AccECN spec and in any other relevant RFC and the 
> existing code in the target stack. So, she/he learns from the AccECN 
> draft the rules when an ACK should be send as a reply to an arriving 
> pure ACK. Then she/he reads RFC 2018 and possibly also RFC 2883 and 
> finds the rules in RFC 2018 I copied above.
>
> The rules #1 and #2 explicitly tell to the implementer that SACK 
> option should be generated for all AoA DupAcks when there is a hole in 
> the sequence space (and RFC 2883 extends this to apply to all 
> DupACKs). So, the programmer follows RFC 2018 and adds code to include 
> the necessary SACK blocks. Only reading the rule #3 creates a dilemma. 
> It is quite possible that the implementer does not decide not to 
> include any SACK blocks. She/he may just decide to borrow the piece of 
> existing code that generates the correct sequence numbers from the 
> arriving packet in the first SACK block (the start seq no from the TCP 
> segment hdr and the code that subtracts the hdr bytes from the IP pkt 
> size + seg_no). In this way the first SACK block would "correctly" 
> indicate the empty data bytes in the arriving ACK. AFAIK, including an 
> "empty" SACK block is not forbidden in any RFC and while acking an ACK 
> is something odd anyway, it does not sound like that stupid idea to 
> implement it like this, particularly when this quite inherently and 
> correctly indicates the "empty" data segment (pure ACK) for which 
> there is no specific rule for SACKing and what is a very special case 
> anyway. Moreover, (almost) all stacks in the other end would quite 
> likely just silently ignore such an empty SACK block, or at least are 
> unlikely to indicate anything to the other end that would reveal the 
> problem. A non-expert programmer may also decide not to include such 
> an empty SACK block but just continues to rule #4 and includes the 
> most recently reported SACK blocks (if not acking the highest seq no) 
> as required. Being non-expert, she/he does not necessarily understand 
> that in this way she/he actually includes a random DSACK block as I 
> have explained already earlier.

[BB2] I don't know whether you were writing this late at night, but we 
can ignore everything you've written so far, because the logic is broken...

 1. Your argument in a nut shell:
      * a newbie might include SACK blocks on AoAs,
      * because they might only read AccECN (and misunderstand SACK &
        D-SACK).
 2. But the AccECN spec says that SACK blocks MUST NOT be included on AoAs
      * you even acknowledge above that this is now in the AccECN spec,
        at your own suggestion.

Moving on...

> [MK] So, IMHO RFCs should be specified for completeness in order to 
> give useful advise also for non-expert developpers. This said, it only 
> dawned on me just when writing this email that the idea of acking an 
> ACK with an empty DSACK block is much better than not including any 
> SACK option. It would unambiguosly solve the problem of distinguishing 
> AoAs from genuine DupACKs and it would also unambiguosly solve even 
> the case when SACK blocks are stripped as well as provide additional 
> useful information for the other end for various other purposes. I add 
> also an alternative proposed text for this option below.
>
>>         3.2.2.5.1. Data Receiver Safety Procedures
>>
>> 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]).
>>
>> 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]). 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).
>
> [MK] I'd like to modify the proposed text to be more informative 
> because I find the above text somewhat misleading/speculative 
> (particularly "would normally not happen" is a bit problematic because 
> actual specification for acking ACKs is missing and what the draft is 
> specifying here is not something that would normally happen ;)

[BB2] You're now arguing that a newbie following the SACK spec might 
write code that includes a 'null' SACK block (with the same start and 
end) on an AoA. This stretches credibility to the extreme.


> I also include an alternative that would be robust in distinguishing 
> AoAs in all cases, including the case when SACK option is stripped 
> (unless I have missed something). In this alternative AoAs always 
> include a specific SACK option that allows distinguishing AoAs from 
> genuine DupACKs as well as allows immediately detecting when SACk 
> option is stripped.
>
>
> PROPOSED:
>
>  ...
>  In the above bidirectional scenario and various other
>  scenarios, incoming ACKs of ACKs could be mistaken for
>  duplicate ACKs. But ACKs of ACKs can be distinguished from
>  duplicate ACKs because *if* they do not contain a SACK option even
>  when SACK has been negotiated. *The rules in RFC 2018 (Sec. 4)
>  for generating SACK options have been written considering
>  only the acknowledgements triggered by arriving data
>  segments. Applying these rules when acknowledging ACKs
>  becomes somewhat ambiguous. For clarity, it is necessary
>  to update RFC 2018 to cover also acking of ACKs by requiring
>  that these ACKs of ACKs MUST NOT contain a SACK option. *
>  It is outside the scope of this AccECN spec to normatively
>  specify the additional test for distinguishing ACKs of ACKs
>  from 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]).

[BB2] I've coloured your proposal to see more clearly what you've changed.

I'm afraid we're not going to say that the SACK spec is ambiguous, on 
the grounds of your argument that it might lead a newbie to write code 
that accidentally creates a null SACK block on an AoA. I think you're 
now clutching at straws and you need to let this argument go.

>
> PROPOSED (alternative that acknowledges AoAs with an empty SACK block):
>
>  ...
>  In the above bidirectional scenario and various other
>  scenarios, incoming ACKs of ACKs could be mistaken for
>  duplicate ACKs. But ACKs of ACKs can be distinguished from
>  duplicate ACKs if they contain a specific SACK option
>  indicating an empty sequence of data. The rules in RFC 2018
>  (Sec. 4) for generating SACK options have been written
>  considering only the acknowledgements triggered by arriving
>  data  segments. Applying these rules when acknowledging ACKs
>  becomes somewhat ambiguous and it is necessary to update
>  RFC 2018 to cover also acking of ACKs. In order to distinguish
>  ACKs of ACKs from genuine DupACKs these ACKs of ACKs MUST
>  contain a SACK option where the first and only SACK block
>  indicates an empty data sequence such that the left and right
>  edge of the block both contain the sequence number of the
>  arriving pure ACK segment. It is outside the scope ...

[BB2] Now you are arguing that the AccECN spec should mandate a 'null' 
SACK block on an AoA. This is interesting for a few seconds of thought, 
but then it falls over:

 1.   If SACK blocks are stripped, an ECN++ host receiving one of these
    AoAs no longer has nothing to distinguish AoAs from DupACKs again
      * so its no better than we've already got - still needs
        alternative tests / heuristics
 2. The outcome is uncertain when these null SACK blocks are received by
    existing implementations:
      * You yourself admit that the possibility of just ignoring them is
        only "quite likely" - that's not good enough
      * Some implementations might discard SACK packets with left ≥
        right, or consider it an attack and RST the connection;
      * Other implementations might test right and left separately
        without checking whether they are the same, and conclude that
        the SACK block overlaps previously acknowledged data, so it's a
        D-SACK and therefore a DupACK.
 3. The proposal would require AccECN to mandate the use of SACK


The reckoning:
#1 = no better. #2 & #3 = worse.
So, let's set your proposal aside and move on.

Regards


Bob


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

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