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

[Bob Briscoe <[e-mail]>]

tcpm chairs,

At IETF-106 there was believed to be rough consensus in the room that 
AccECN ought to be stds track not expt track.

I pointed out that we would need to check for that consensus on the 
list. We can't really move forward with the draft until that has been 
done. So would it be possible to do a consensus call on the list on that 
question ASAP?

To provide some concrete data for the question, below I've quoted the 
analysis I did of what would have to be altered in the AccECN draft if 
it switched to the stds track. I've also just added one addendum to it.

Thanks in advance



Bob

PS. (Also a consensus call on the list about the question of the process 
for assigning header flags pls.)



On 23/11/2019 11:26, Bob Briscoe wrote:
> 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 Briscoehttp://bobbriscoe.net/

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