Re: [tcpm] Feedback on draft-ietf-tcpm-accurate-ecn-14

[Bob Briscoe <[e-mail]>]

Ilpo,

Thanks. I've updated the editor's copy as described below.

On 15/04/2021 11:26, Ilpo Järvinen wrote:
> Hi,
>
> I read through the changes since -09. Some recommendations/notes:
>
> - "The server MAY include a test to avoid this case."
>    I'd say: "The server MAY implement a filter in ESTABLISHED state
>    for ACKs with handshake encoding."
>    The problem with the original wording is that "this case" is not
>    that obvious (in fact, the previous sentence talked exactly
>    opposite thing, that is, interpreting the ACE field normally).

[BB] I see the problems. I've reordered and rewritten this with a 
'Reasoning' paragraph afterwards, like the other rules:

       Once the TCP server transitions to ESTABLISHED state, it might
       later receive other pure ACK(s) with the handshake encoding in the
       ACE field.  A server MAY implement a test for such a case, but it
       is not required.  Therefore, once in the ESTABLISHED state, it
       will be sufficient for the server to consider the ACE field to be
       encoded as the normal ACE counter on all packets with SYN=0.

       Reasoning: Such ACKs will be quite unusual, e.g. a SYN/ACK (or ACK
       of the SYN/ACK) that is delayed for longer than the server's
       retransmission timeout; or packet duplication by the network.  And
       the impact of any error in the feedback on such ACKs will only be
       temporary.

Clearer?


>
> - "For each field, it takes the least significant 24 bits of its
>    associated local counter (s.ceb, s.e0b or s.e1b) and subtracts
>    them from the counter in the associated field of the incoming
>    AccECN Option (respectively ECEB, EE0B, EE1B), to work out the
>    minimum positive increment it could apply to s.ceb, s.e0b or
>    s.e1b (assuming the field in the option only wrapped at most
>    once).".
>    When using a heuristic to update the byte counters, "the minimum
>    positive increment" is too restricting as the byte counters may
>    have to be backtracked after heuristic misguessed which of them
>    to increment.
>    Also in appendix, there's the now the same assumption that the
>    byte counter difference will always be non-negative.

[BB] To avoid having to introduce the idea of heuristics at this early 
stage, I've replaced 'MUST decode' with 'normally decodes' (the 'MUST' 
isn't appropriate anyway):

    If the ACK has not
    been superseded, the Data Sender normally decodes the fields in the
    AccECN Option as follows.


Then I added the following to the end of Appendix A.1 that gives a 
decoding example:

    In practice an implementation might use heuristics to guess the
    feedback in missing ACKs, then when it subsequently receives feedback
    it might find that it needs to correct its earlier heuristics as part
    of the decoding process.  The above decoding process does not include
    any such heuristics.


Is that good enough?

>
> - Paragraph seems to appear twice (only 2 words differ in them):
>    "Even though the first bullet is stated as a "SHOULD", it is important
>     for a transition to immediately trigger an ACK if at all possible, ..."

[BB] I've replaced the first occurrence just under the 'SHOULD' with a 
pointer to the second occurrence, which I've described as the only valid 
exception to the SHOULD.

Thanks for pointing this out. I also rationalized all the text around 
the rules on when to trigger immediate sending of ACKs and AccECN 
Options. I've separated out:
a) a name for each rule so it can be referred to unambiguously;
b) the rule itself;
c) rationale for the rule;
c) exception to the rule.

>
> - Compatibility with TCP Experiments and Common TCP Options
>    Should re-state (again) here how SYN and SYN/ACK data is to be
>    treated wrt. the byte counters.
>

Done.

Thank you again.


Bob

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/