Re: [PANRG] On the new text on ECN: draft-irtf-panrg-what-not-to-do-16

Thanks for continuing this discussion on the mailing list. If I might add
this ...

On Thu, Mar 11, 2021 at 11:13 AM Bob Briscoe <ietf@bobbriscoe.net> wrote:

> Gorry, and panrg,
>
> I'd agree with Gorry, about one chance per generation.
>

My understanding (and we're talking about this to understand it better) is
that there are two things in play with the early ECN deployment experiment.

Yes, routers crashing when they say non-zero ECN bits was in a device which
(at the time) wasn't likely to be updated or replaced for a number of years
(see "equipment generation"), but the second point (and I think it was
Kireeti who said this well) was that once you've updated or replaced all of
the problematic equipment, the people who turned ECN off didn't immediately
turn ECN back on (I remember the phrase "a bad taste in their mouths"
mentioned multiple times.

So, as Kireeti and others observed, generations between updates are getting
shorter, but it's not clear that the ability of people to forgive and
forget past experiences is getting shorter in the same way. I'm remembering
the quote from Oscar Wilde, "Second marriage is the triumph of hope over
experience" - I think we're talking about the same thing as "second
marriage".

Best,

Spencer

> I'd also say that there are two main prongs to the ECN story. Not just
> the "one chance" point.
> The other is "Outperforming End-to-end Protocol Mechanisms"
>
> When I was asked to write the business case for deploying ECN in BT, my
> colleagues in the tech strategy team pushed me on this point of
> outperforming e2e mechanisms. Jamal Salim's performance evaluation
> [RFC2884] showed ECN gave no performance benefit, except for short
> flows. I had to admit that e2e FEC for short flows would be more likely
> to win out. And at the time, I'd just found Damon Wischik paper about
> how little the extra percentage of traffic volume would be, if every
> sender just duplicated the first few packets of each flow [Wischik08].
>
> So the business case flat-lined. End systems had long since worked out
> tonnes of loss-hiding tricks. There was far too great a risk that, by
> the time the 3-part deployment had got anywhere (sender, receiver and
> network), the problem would have been solved e2e, and the high-risk
> high-cost investment would all have been wasted.
>
> This was actually the start of my journey to realize that the "ECN =
> drop" rule was the problem, 'cos it disallowed the real benefit of ECN -
> to cut queuing delay, by providing a finer-grained signal than loss. I
> did some calculations to work out that the noise in the delay signal was
> too great to get queue delay down as low as would be achievable with ECN
> (which could use virtual queues once ISPs realized that bandwidth had
> become plentiful enough). That was actually when I started working on
> chirping (bringing in Mirja as a research fellow) and came to the
> conclusion that we could only get a better delay signal out of the noise
> by creating more noise with the chirps. That's when I realized the
> chirps should only be used at start-up, and ECN was the only way to keep
> queueing extremely low under load. Today you can see the limits of using
> e2e delay to reduce queuing in BBR, although of course BBR is unlikely
> to be the last word in e2e delay reduction.
>
> I know it's unlikely that every ISP went through such a rigorous
> exercise, but still none deployed it - probably intuitively reaching the
> same conclusion. The main reason being the deployment pain wasn't worth
> the small performance gain. Which is a TL;DR summary of all the above.
>
> The issue with Linksys home routers crashing wasn't a biggie in that
> assessment of ECN - there were few enough of that model around by then
> that it could be worked round with pre-deployment validation testing
> from the OS. This supports Gorry's "one chance per generation" point.
>
> Reference
> [Wischik08] Wischik, D. "Short Messages" Philosophical Transactions of
> the Royal Society A, 2008, 366, 1941-1953
>
>
> Bob
>
> On 11/03/2021 16:17, Gorry Fairhurst wrote:
> > Resend: On 11/03/2021 15:06, Gorry Fairhurst wrote:
> >> HI,
> >>
> >> Two observations on ECN in what may have been learned?
> >>
> >> * I think the "one chance" is per one /Generation/ of equipment for
> >> hardware, possibly less time for software updates - but hard to
> >> eliminate deployed critical bugs completely.
> >>
> >> * "Measure widely before, but important also gently test during
> >> initial deployment", to avoid the pain when there are issues and
> >> therefore to provide a chance to refine the design if there is a
> >> problem, and reduce the pain of trying.
> >>
> >> I like the additional thought from Eric (in the RG meeting) on
> >> mitigating user pain by using fallback techniques, so they do not
> >> share your pain when something happens to go wong.
> >>
> >> ————
> >>
> >> Is this a typo?: /Cannot be recovered at TCP layer/
> >> - it seems like a partial sentence, does need a /This.../
> >>
> >> Gorry
> >>
> >> _______________________________________________
> >> Panrg mailing list
> >> Panrg@irtf.org
> >> https://www.irtf.org/mailman/listinfo/panrg
> >
> >
> > _______________________________________________
> > Panrg mailing list
> > Panrg@irtf.org
> > https://www.irtf.org/mailman/listinfo/panrg
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> Panrg mailing list
> Panrg@irtf.org
> https://www.irtf.org/mailman/listinfo/panrg
>