Subject: [PANRG] Would we learn anything from ECN, that we haven't already learned from other path-aware networking solutions?

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 2 Feb 2021 10:53:37 -0600

Dear PANRG,

The IETF conflict review for draft-irtf-panrg-what-not-to-do is sailing
along smoothly (details at
https://datatracker.ietf.org/doc/conflict-review-irtf-panrg-what-not-to-do/ballot/),
but Martin Duke, the AD who is responsible for the conflict review, asked
me privately if there was a reason we hadn't included ECN as one of the
path-aware networking solutions in the draft.

N.B. Martin asked me this privately, so it's not part of the IESG conflict
review for the draft. But Martin was curious.

The easy answer, of course, is that this draft was based on contributions
to the research group, and we didn't get contributions that covered ECN,
but that's the easy answer to Martin's question to me.

My question for the research group is "do we think we'd learn any lessons
from analyzing ECN that we haven't already learned from other solutions?"

For ease of reference, the section on Lessons Learned is at
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-16#section-4,
and the table that lists the lessons is at the top of
https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-16#page-8.

What are your thoughts?

Best,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 7 Feb 2021 18:55:21 -0600

I know that people are working to get organized for their 2021 work plans,
but has anyone had a chance to think about Martin's question?

Best,

Spencer

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 8 Feb 2021 08:50:09 +0100

hi Spencer, Martin,

I suspect another reason here is that each of the other contributions covered efforts that are more definitively in the past (with the possible exception of the V6 Flow Label), while the story of ECN is in some way still ongoing. 

The story of ECN to its endpoint deployment in the mid-to-late-teens ticks many of the Lessons Learned boxes: justifying deployment with benefits for early adopters and partial deployment being chief among them. 

The one lesson potentially missing here (and which might make this worth writing up) is "Implementation Matters". As I understand it (in other words [citation needed]), the initial deployment of ECN in Linux caused routers from certain vendors to run off their state space and crash, and the folk wisdom became "turn it off so your network stays up" until long after the affected routers had been patched or forklifted.

There's an alternate reality, without that implementation failure, in which end-to-end ECN marking became prevalent because of OS defaults, and neither caused many problems nor saw much actual usage, because there was little incentive to turn it on in the network but no incentive to change the endpoint default.

It's a bit late, but I suppose it might make sense to add. I could write that up if someone has citations for the specifics.

Cheers,

Brian

> On 2 Feb 2021, at 17:53, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Dear PANRG,
> 
> The IETF conflict review for draft-irtf-panrg-what-not-to-do is sailing along smoothly (details at https://datatracker.ietf.org/doc/conflict-review-irtf-panrg-what-not-to-do/ballot/), but Martin Duke, the AD who is responsible for the conflict review, asked me privately if there was a reason we hadn't included ECN as one of the path-aware networking solutions in the draft. 
> 
> N.B. Martin asked me this privately, so it's not part of the IESG conflict review for the draft. But Martin was curious.
> 
> The easy answer, of course, is that this draft was based on contributions to the research group, and we didn't get contributions that covered ECN, but that's the easy answer to Martin's question to me. 
> 
> My question for the research group is "do we think we'd learn any lessons from analyzing ECN that we haven't already learned from other solutions?"
> 
> For ease of reference, the section on Lessons Learned is at https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-16#section-4, and the table that lists the lessons is at the top of https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-16#page-8.
> 
> What are your thoughts?
> 
> Best,
> 
> Spencer
> _______________________________________________
> Panrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/panrg

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 8 Feb 2021 09:15:16 -0600

Hi, Brian,

On Mon, Feb 8, 2021 at 1:50 AM Brian Trammell (IETF) <[email-masked]>
wrote:

> hi Spencer, Martin,
>
> I suspect another reason here is that each of the other contributions
> covered efforts that are more definitively in the past (with the possible
> exception of the V6 Flow Label), while the story of ECN is in some way
> still ongoing.
>
> The story of ECN to its endpoint deployment in the mid-to-late-teens ticks
> many of the Lessons Learned boxes: justifying deployment with benefits for
> early adopters and partial deployment being chief among them.
>
> The one lesson potentially missing here (and which might make this worth
> writing up) is "Implementation Matters". As I understand it (in other words
> [citation needed]), the initial deployment of ECN in Linux caused routers
> from certain vendors to run off their state space and crash, and the folk
> wisdom became "turn it off so your network stays up" until long after the
> affected routers had been patched or forklifted.
>

I had only the vaguest memory of this - thanks for the reminder!

> There's an alternate reality, without that implementation failure, in
> which end-to-end ECN marking became prevalent because of OS defaults, and
> neither caused many problems nor saw much actual usage, because there was
> little incentive to turn it on in the network but no incentive to change
> the endpoint default.
>
> It's a bit late, but I suppose it might make sense to add. I could write
> that up if someone has citations for the specifics.
>

Sally Floyd's ECN page (https://www.icir.org/floyd/ecn.html) is still the
gift that keeps on giving.

Murari Sridharan, Deepak Bansal, and Dave Thaler did a presentation in
TSVAREA about this in 2007. The relevant slides look like
https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld6.htm and
https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld7.htm.

I think "Implementation Matters", or maybe even "Broken Existing
Implementations Matter", is a good Lesson Learned that isn't explicitly
captured from another contribution.

So, here's my understanding of The Right Thing To Do.

   - I can start a contribution about this, based on what Dave and the
   Microsoft team reported in 2007.
   - Brian and I should probably coordinate on the current state of
   deployment today - as Brian pointed out, this may be the most successful
   failure that's described in this document :-)
   - Jen and Brian (as RG chairs) should confirm that this is actually The
   Right Thing To Do with the RG, once we have text, and the RG knows what
   "This" is.
   - At a minimum, I should reach out to Dave Thaler and ask him to check
   what we end up with for mistakes and mischaracterizations. He may have
   additional information about Vista experience that he didn't include in the
   2007 presentation.
   - Jen (as document shepherd) should probably be confirming that this is
   actually The Right Thing To Do with Colin (as IRTF Chair) - this isn't the
   biggest change I've seen for an IRTF-stream document during IRSG review,
   but I'm very unclear whether it would need to go back to the IESG for
   another conflict review, for instance.

 Does that sound about right?

Best,

Spencer

Cheers,
> > N.B. Martin asked me this privately, so it's not part of the IESG
> conflict review for the draft. But Martin was curious.
> >
> > The easy answer, of course, is that this draft was based on
> contributions to the research group, and we didn't get contributions that
> covered ECN, but that's the easy answer to Martin's question to me.
> >
> > My question for the research group is "do we think we'd learn any
> lessons from analyzing ECN that we haven't already learned from other
> solutions?"
> >

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 8 Feb 2021 11:22:56 -0600

Hi, Martin the Shepherding AD for
https://datatracker.ietf.org/doc/conflict-review-irtf-panrg-what-not-to-do/

On Mon, Feb 8, 2021 at 10:25 AM Martin Duke <[email-masked]> wrote:

> Hi Spencer,
>
> Thanks for pursuing this. No matter the specific outcome, I am confident
> that PANRG will Do The Right Thing.
>
> To your last point -- I don't think adding ECN will require another
> conflict review, unless you start making recommendations about how ECN
> should evolve further.
>

That's great news, and we've been really careful to stay away from
recommendations for evolving specific IETF protocols in this document.
That's Engineering. :-)

And thanks for your confidence.

Best,

Spencer

---

From: Colin Perkins <[email-masked]>
Date: Mon, 8 Feb 2021 23:41:01 +0000

> On 8 Feb 2021, at 15:15, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Brian, 
> 
> On Mon, Feb 8, 2021 at 1:50 AM Brian Trammell (IETF) <[email-masked] <mailto:[email-masked]>> wrote:
> hi Spencer, Martin,
> 
> Sally Floyd's ECN page (https://www.icir.org/floyd/ecn.html <https://www.icir.org/floyd/ecn.html>) is still the gift that keeps on giving. 
> 
> Murari Sridharan, Deepak Bansal, and Dave Thaler did a presentation in TSVAREA about this in 2007. The relevant slides look like https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld6.htm <https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld6.htm> and https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld7.htm <https://www.ietf.org/proceedings/68/slides/tsvarea-3/sld7.htm>. 
> 
> I think "Implementation Matters", or maybe even "Broken Existing Implementations Matter", is a good Lesson Learned that isn't explicitly captured from another contribution. 
> 
> I can start a contribution about this, based on what Dave and the Microsoft team reported in 2007.
> Brian and I should probably coordinate on the current state of deployment today - as Brian pointed out, this may be the most successful failure that's described in this document :-)
> Jen and Brian (as RG chairs) should confirm that this is actually The Right Thing To Do with the RG, once we have text, and the RG knows what "This" is. 
> At a minimum, I should reach out to Dave Thaler and ask him to check what we end up with for mistakes and mischaracterizations. He may have additional information about Vista experience that he didn't include in the 2007 presentation. 
> Jen (as document shepherd) should probably be confirming that this is actually The Right Thing To Do with Colin (as IRTF Chair) - this isn't the biggest change I've seen for an IRTF-stream document during IRSG review, but I'm very unclear whether it would need to go back to the IESG for another conflict review, for instance. 

No objection on my part.

Colin