Subject: [aqm] Please review: Benefits and Pitfalls of using ECN

From: [email-masked]
Date: Wed, 11 Mar 2015 20:10:06 -0000

AQM'ers,

Michael and I have a new version of the WG draft motivating use of ECN.
This version seeks to produce a readable and near-complete version that
should be ready for review comments. Please let us know what you think via
the AQM list, all comments appreciated.

Alas, due to a slight technical mistake by me, we missed the ID deadline.
So I have posted an interim version here:

http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.txt
http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml

I plan to upload this version to the archives as soon as they reopen.

Best wishes,

Gorry & Michael

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 17 Mar 2015 11:11:38 -0400

> http://www.erg.abdn.ac.uk/users/gorry/ietf/AQM/draft-ietf-aqm-ecn-benefits-01.xml

I've reviewed this copy and have some comments, one larger and
the rest smaller.

Large comment:

I (personally) really do not like using the word "pitfall" in this
document, given that we want people to use ECN, and not scare them
about this list of pitfalls that await them the day they start using
it.

We could call these "operational difficulties that have been
encountered" or "challenges due to misbehaving network devices and
endpoints".

I worry about someone that doesn't have time to carefully read and
consider all the benefits and whether they outweigh the "pitfalls",
and may not fully grok that the pitfalls have known mitigations and
will hopefully go away over time.

We *should* be more clear that there are mitigations and that plenty of
nodes are able to use ECN happily today because it is implemented in
the major OSes and network devices.

For instance, there is no mention of things like ECN blackhole
detection, and measurements of this, such as:
http://conferences.sigcomm.org/imc/2011/docs/p171.pdf

We *definitely* need to stress that bleaching, lying, and cheating
behaviors are non-conformant, in some cases may be from legacy code,
and should be expected to go away over time rather than proliferate,
because these behaviors will cause problems for the growing critical
mass of conforming nodes.

So, in summary, I would really suggest that we go through the document
searching for every instance of "pitfall" and try to be more gentle,
and even change the title just to "The Benefits of Using Explicit
Congestion Notification (ECN)".  There is way more text in the document
about benefits than pitfalls anyways, and I think we could consider the
section discussing pitfalls as just fairly presenting possible
challenges to successfully using ECN.

That's just my opinion ... I'd be curious what others think.

Small comments:
- In section 1, paragraph 3, I suggest changing the text:
  "where the exact combination of AQM/ECN algorithms is generally
   not known by the transport endpoints."
  to:
  "where the exact combination of AQM/ECN algorithms does not need
   to be known by the transport endpoints."

  Since the document is for people that might not be familiar with
  this, it seems worth rewording so they don't think it's somehow
  bad or suboptimal that the endpoints don't know if AQM or ECN is
  supported within the network.

- section 1, paragraph 4, I suggest changing:
  "that would otherwise have been dropped"
  to:
  "that would otherwise have been dropped if the application or
   transport did not support ECN"

  I think this kind of wording will emphasize that they need to
  make sure they're enabling it at the endpoint.

- section 2, paragraph 3 should be changed:
  "Applications that experience congestion in such endpoints"
  to:
  "Applications that experience congestion in such network devices"

Even smaller comments:
- section 1, paragraph 2, "forward" -> "forwards"
- section 1, paragraph 2, "this packet" -> "packets"
- section 1, paragraph 3,
  "The focus of this document is on usage of ECN"
  to:
  "The focus of this document is on usage of ECN by transport and
   application flows"
- section 2, paragraph 2, I think the ECN RFC (3168) could also be cited
  in addition to 2309bis for the recommended behavior for network
  devices

-- 
Wes Eddy
MTI Systems

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 17 Mar 2015 18:45:25 +0000

> the major OSes and network devices.
See below.

> http://conferences.sigcomm.org/imc/2011/docs/p171.pdf
OK - Happy to cite this.

> mass of conforming nodes.
Agree, we can emphasise this.

> That's just my opinion ... I'd be curious what others think.
Personally, I'd be really happy to do rework this language.

I would also like to revert the title (to just say "benefits", as in the 
original Individual ID submission), I believe we changed the title in 
response to comments from the group, but this was at a time when we had 
not describe some of the realities of deploying ECN. I'd like to think 
these have been addressed, and revert to the original title.

Note: If any people prefer to keep the "pitfall" word, then send an 
email asap - and give me some advice, otherwise I'll likely follow the 
edits suggested above.

>     to be known by the transport endpoints."
Agree.

>     transport did not support ECN"
Agree.

>    "Applications that experience congestion in such network devices"
Oh dear, yes will fix -- or we could just say "experience congestion"?

>    in addition to 2309bis for the recommended behavior for network
I'll also fix these in the draft before we upload.

Gorry