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

["Scheffenegger, Richard" <[e-mail]>]

As one of the authors, and also exposed to how the decision process in
corporations is driven by non-technical considerations, I do prefer
making AccECN standards track (PS).

Further, this would alleviate some of the procedural questions of
assigning a TCP header bit for the AccECN feedback, without violating
our (tcpm/ietf) own rules.

This is just to reiterate my preference - if the group consensus is to
have AccECN as Experimental (and a supporting standards-track document
allowing the assingment of the AE bit), I can live with that too - while
it will make deployment harder in certain environments.

Best regards,
   Richard


Am 11.12.2019 um 19:43 schrieb Bob Briscoe:
> 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 Briscoehttp://bobbriscoe.net/
>
>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>