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

From: "Ilpo Järvinen" <[email-masked]>
Date: Thu, 15 Apr 2021 13:26:23 +0300 (EEST)

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).

- "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.

- 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, ..."

- 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.

-- 
 i.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 21 Apr 2021 18:41:40 +0100

Ilpo,

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

>    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?

>    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?

>     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.

>    treated wrt. the byte counters.

Done.

Thank you again.

Bob

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