[tcpm] Impact on AccECN draft of change from EXP to PS

[Bob Briscoe <[e-mail]>]

tcpm-ers,

Here's analysis of the things in draft-ietf-tcpm-accurate-ecn that would 
have to be altered to upgrade it to PS from EXP. This was generally 
favoured in the tcpm meeting today, but it has to be ratified on this 
list, so I thought this info would be helpful.

==Header Block==
Intended Status: Proposed Standard
Updates: 3168

==Throughout==
(substituting intelligently):
s/experimental/standards track/
s/other experiments/experiments/
s/other variants/variants/

==1. Intro==
CURRENT:
  "Until the AccECN experiment succeeds, [RFC3168] will remain as the
    only standards track specification for adding ECN to TCP. "
PROPOSED:
   Instead, summarize here how this doc updates RFC3168, referring to a 
new section XXX (below) that gives detailed updates.

CURRENT:
  "It is completely independent of how TCP might respond to congestion
   feedback, which is out of scope. For that we refer to [RFC3168]..."
PROPOSED
  "It is completely independent of how TCP might respond to congestion
   feedback, which is out of scope. For that we refer to [RFC3168] and 
[RFC8311], excepting the updates to RFC 3168 in Section XXX of the 
present document that generalize the wording to include AccECN."

==1.1 Document Roadmap==
Remove ref to 1.3 & include a ref to the new section XXX detailing the 
updates to 3168.

==1.3 Experiment Goals==
Delete section

FYI, the two experiment goals are:
1. fall-back strategies in the face of path traversal problems
2. interaction of change-triggered ACKs and offloaded processing

The two "MUST" requirements behind #2 have just been relaxed to 
"SHOULD"s as part of the splitting up of change-triggered ACKs between 
ACE and the AccECN TCP Option, as I mentioned in the presentation to the WG.

#1 is more likely to affect implementation than design, given the design 
provides for fall-back in most conceivable circumstances (e.g. it is 
designed for any or all AccECN TCP options to be sent but not received 
{Note 1}) and there's considerable checking of mangling already. 
Nonetheless, we might find byzantine middlebox behaviour, e.g. stripping 
the TCP option from some packets but not others, altering selected 
protocol fields, altering some header bits but not others,... I'd like 
to see some large-scale testing over production networks before the RFC 
is published.

{Note 1}: Altho the latest change has made it necessary to receive the 
first AccECN Option in each direction to be able to correctly understand 
later options.

==XXX. Updates to RFC3168==
New section XXX between sections 3 & 4.
For content, see later in this email.

==3.2.6 The AccECN Option==
The Kind of the option can be assigned a permanent value, rather than a 
2B longer option with Kind=254 and a magic number.

==6. IANA Considerations==
Delete the para about using experimental option 254.



===Section XXX. Updates to RFC3168===

The following sections of RFC3168 would be updated by the AccECN 
specification, if it were stds track:

  * The Introduction to Section "6. Support from the Transport Protocol"
    that summarizes the way TCP feeds back ECN markings
  * the whole of "6.1.1  TCP Initialization"
  * The whole of "6.1.2. The TCP Sender" except the second, third and
    last paras still apply to RFC5681 congestion control, but not
    necessarily to other experimental forms of ECN congestion control
    allowed by RFC8311 (specified by a suitable experimental RFC).
  * The whole of "6.1.3.  The TCP Receiver" except the last two
    sentences till stand (which are incidentally in the wrong section,
    because they relate to TCP sender behaviour):
         "Some care
        is required if the TCP sender is to avoid unnecessary reductions of
        the congestion window when a window of data includes both dropped
        packets and (marked) CE packets.  This is illustrated in
    [Floyd98]. "
  * The following text within "6.1.5. Retransmitted TCP packets" is
    updated as follows:
      o CURRENT:
        "the TCP data receiver SHOULD
        ignore the ECN field on arriving data packets that are outside
        of the
        receiver's current window."
      o UPDATED:
        "The TCP data receiver MUST ignore the CE codepoint on incoming
        segments that fail any validity check.  The validity check in
        section
        5.2 of [RFC5961] is RECOMMENDED."
  * Section "5.2 Dropped or Corrupted Packets" of RFC3168 says '"pure"
    ACK packets MUST NOT indicate ECN-Capability.' The AccECN draft will
    not update this aspect, but it will say what TCP should do if it
    receives an ECN-capable pure ACK.

I'm slightly unsure about this one - any opinions?:

  * Section "23.2 TCP header Flags" within the "IANA Considerations"
    Section:
    If AccECN is going to update 3168, we will need to consider whether
    to update the names ECE and CWR. Even though they don't do anything
    related to those names in AccECN, AccECN has to be able to fall-back
    to 3168, so I suggest we keep these names.


==Opportunities to close loop-holes==

I would also like people to check through RFC3168 to look for 
opportunities to make behaviour for currently unused values in protocol 
fields unambiguous - in order to allow for forward compatibility (or 
remove unnecessary restrictions on forward compatibility) for other 
future protocols derived from RFC3168.

As well as the changes that AccECN already makes to the TCP part of 
3168, making AccECN stds track would give an opportunity to update some 
TCP feedback-related aspects of 3168 that might have been overlooked 
when 8311 was written. I can't think of any, but I'll check and it would 
be good if others did too.




Bob

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