Subject: [aqm] review of draft-ietf-aqm-ecn-benefits-04

From: Dave Taht <[email-masked]>
Date: Thu, 7 May 2015 13:40:25 -0700

I see that during my absence here most mention of the potential
negative aspects of ecn
have been nuked from this document.

Would the right procedure be to submit a new, separate document
covering the following as to how various aqm and fq_aqm algorithms are
affected, how misbehavior happens, particularly with flows in slow
start at low bandwidths?

Aside from these caveats i find the document to well written and quite readable.

I had submitted some stuff like this to the list last time.

 Especially at low bandwidths,

A) packets have sufficient "mass", for dropping at the point of
congestion to be more appropriate than marking inside of an RTT. At
higher bandwidths, ecn marking is a win.

i am observing drop rates of 30% or more on some tests with modern
tcps and IW10 at bandwidths below 5mbits on the rrul related tests.
doing ecn marks instead - In one test, ecn marks cracked 25% of all
packets and nearly all non-ecn marked flows, including syns, were
getting dropped.

B) Ecn causes more packet loss for non-ecn marked flows.

C) existing AQM algorithms handle ect(3) overloads very differently -
present day codel never drops til the (very large default) packet
limit is hit, pie kicks into a drop mode very rapidly, fq_codel
sidesteps the issue by allowing less demanding flows to slip by with
less impact from the "mass" of the ecn flows, and cake follows a drop
then mark policy on overload that appears to be working halfway
decently - in addition to having the benefits of multi-queuing that
fq_codel has.

D) slow start behavior at low bandwidths with ecn enabled leads to
unacceptable latencies for other flows, no matter the aqm algorithm.

My own evaluation was and remains that ECN as presently implemented
for tcp should not be used in single queued aqms at low bandwidths
unless that ecn-enabled tcp is the sole transport, or there are other
mitigating circumstances such as it being a long RTT uplink.

packets have mass. slow start and iw10 have consequences.

E) I do think ecn has benefits for other sorts of flows than tcp. In
particular, routing related packets.

F) Recently, when pressed to a wall about it by an isp, i ended up
recommending that iptv multicast streams be all marked ecn capable via
the appropriate setsockopt option (hopefully triggering better
behavior on the competing tcp flows and minimizing packet loss on the
tv flows which are controlled by the isp to always, in total, be less
than the total bandwidth provided to the customer), rather than trying
to put some sort of fixed priority queue into cake (even though cake
respects diffserv) and thus require full co-ordination between cpe and
isp.

I figure i am going to live to regret that recommendation.

-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

---

From: Michael Welzl <[email-masked]>
Date: Thu, 7 May 2015 23:31:30 +0200

Hi,

> On 7. mai 2015, at 22.40, Dave Taht <[email-masked]> wrote:
> 

Actually I don't think we really removed any - it's just a stylistic change (title, headlines). So: could you be specific about which one there is in a (which?) previous version that is missing in this one?

Cheers,
Michael

> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Dave Taht <[email-masked]>
Date: Thu, 7 May 2015 14:39:53 -0700

> Actually I don't think we really removed any - it's just a stylistic change (title, headlines). So: could you be specific about which one there is in a (which?) previous version that is missing in…

You are correct. I should have said that few of the negatives I had
attempted to discuss previously were added to the document.

I did see the new(ish) section 3.4 which is good, and I am trying to
catch up on some of the older threads like gaming ecn to see what was
resolved.

---

From: Dave Taht <[email-masked]>
Date: Thu, 7 May 2015 14:50:11 -0700

I would like to find a co-author(s) for a paper analyzing aqm, ecn,
and slow start behavior.

skeptics welcomed. No intent to make ietf prague,probably another
conference, as it will take a long while to pour through this dataset
and packet captures.

Please contact me off-list if interested.