Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04
On 5/7/2015 5:39 PM, Dave Taht wrote: > On Thu, May 7, 2015 at 2:31 PM, Michael Welzl wrote: >> Hi, >> >> >>> On 7. mai 2015, at 22.40, Dave Taht 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. > Hi Dave, I'm trying as a co-chair to figure out if we have consensus on this document to go forward. If it's easy to point to, or summarize, a list of negatives that haven't yet been included, I think that would make it simpler for the editors to incorporate. I wasn't able to go back and track every message, but the things that have been most discussed do seem to be included currently. If there are some still missing, I'd like to make sure they get discussed and incorporated as needed. There was the topic of "gaming ECN", which I thought Bob Briscoe's message on 4/15/2015 came close to putting to rest, and personally, I'm not sure if or how to reflect this conversation in the draft, but maybe others have more clear ideas? -- Wes Eddy MTI Systems ___ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04
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 wrote: > On Thu, May 7, 2015 at 2:31 PM, Michael Welzl wrote: >> Hi, >> >> >>> On 7. mai 2015, at 22.40, Dave Taht 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 >>> aqm@ietf.org >>> 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 aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04
On Thu, May 7, 2015 at 2:31 PM, Michael Welzl wrote: > Hi, > > >> On 7. mai 2015, at 22.40, Dave Taht 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 >> aqm@ietf.org >> 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 aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
Re: [aqm] review of draft-ietf-aqm-ecn-benefits-04
Hi, > On 7. mai 2015, at 22.40, Dave Taht 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
