On Thu, May 7, 2015 at 2:31 PM, Michael Welzl <[email protected]> wrote: > Hi, > > >> On 7. mai 2015, at 22.40, Dave Taht <[email protected]> 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?
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. > > 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/aqm > -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
