[PANRG] Updated text on ECN: draft-irtf-panrg-what-not-to-do-19 to be ...

[Spencer Dawkins at IETF <[e-mail]>]

Dear All,

I've worked through the discussion from IETF 110 in CoviMD, on the e-mail
list, and in my own notes from our meeting.

I said I would submit a -19 at the end of this week, and I still plan to do
that, but if you want a preview, here's what I've got for the biggest
changes.

   - The new "Lesson Learned" is "Plan for Failure". It's still Invariant,
   in Table 1. The text for it is "If early implementers discover severe
   problems with a new feature, that feature is likely to be disabled, and
   convincing implementers to re-enable that feature can be very difficult,
   and can require years or decades. *In addition to testing, partial
   deployment for a subset of users, implementing instrumentation that will
   detect degraded user experience, and even "failback" to a previous version
   or "failover" to an entirely different implementation are likely to be
   helpful. (See {{ecn}})."*
   - I reflected Bob Briscoe's points about AQM deployment being part of
   the ECN story, and emphasized that the ECN material focused on experiences
   that provided Lessons Learned that were not covered by other contributions.
   - I added material to the Lesson Learned, to bring it up to date. That
   section now continues

*During discussion of ECN at {{PANRG-110}}, we noted that "you get one
chance to get it right" isn't quite correct today, because so operating
systems on so many host systems are frequently updated, which was not at
all true in the early 2000s. We think that these restatements of the ECN
Lessons Learned are more useful for current implementers: *

*- Even if you do everything right, you may trip over implementation bugs
in devices you know nothing about, that will cause severe problems that
prevent successful deployment of your path aware technology. Testing before
deployment isn't enough to ensure successful deployment. It is also
necessary to "deploy gently", which often means deploying for a small
subset of users to gain experience, and implementing feedback mechanisms to
detect that user experience is being degraded. *
*- After implementations disable your Path Aware technology, it may take
years, or even decades, to convince implementers to re-enable it by
default. This might be based on the difficulty of distributing
implementations that enable it by default, but are just as likely to be
based on the "bad taste in the mouth" that implementers have after an
unsuccessful deployment attempt that degraded user experience. *

*With these expansions, the two lessons, taken together, could be more
helpfully summarized as "plan for failure" - anticipate what your next step
will be, if initial deployment is unsuccessful. *

*ECN deployment was also hindered by non-deployment of AQM in many devices,
because of operator interest in QoS features provided in the network,
rather than using the network to assist end systems in providing for
themselves. But that's another story, and the AQM Lessons Learned are
already covered in other contributions in {{Contributions}}.*


Full details are at
https://github.com/panrg/draft-dawkins-panrg-what-not-to-do/pull/7/commits/85ed46f5f7285346672d4d81861b028d9ed09072,
of course, and comments here or in Github are always welcome.

Best,

Spencer

>