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

[Ilpo Järvinen <[e-mail]>]

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.