Hi,
> On 7. mai 2015, at 22.40, Dave Taht <dave.t...@gmail.com> wrote: > > I see that during my absence here most mention of the potential > negative aspects of ecn > have been nuked from this document. 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 > 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 > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
