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 _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
