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. On Thu, May 7, 2015 at 2:39 PM, Dave Taht <[email protected]> wrote: > 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 -- 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
