> On 26. mar. 2015, at 15.36, David Collier-Brown <dave...@rogers.com> wrote: > > On 03/25/2015 03:03 PM, Michael Welzl wrote: >> Hi, >> >> Below: >> >> >>> On 25. mar. 2015, at 13.12, De Schepper, Koen (Koen) >>> <koen.de_schep...@alcatel-lucent.com> >>> wrote: >>> >>> Hi all, >>> >>> Related to DCTCP and different (more) marking ECN than dropping (let's call >>> it ECN++ in this mail), the talk I gave in iccrg (Data Center to the Home) >>> shows that it is possible to have fairness between ECN++ flows (DCTCP, >>> Relentless TCP, Scalable TCP, ...) and drop based Reno/Cubic flows. >>> >>> The ECN++ flows typically respond to marking proportional to 1/p (with p >>> the marking or dropping probability), while the Reno flavors respond >>> proportional to 1/p^0.5 (one over square root of p). >>> >>> This means that the only difference between marking and dropping is that an >>> AQM has to think twice before it drops, and that is what we want, right? We >>> mark fast by comparing our congestion indicator (derived from the queue >>> size or packet sojourn time, or PI controller) with a random generated >>> value. For a drop decision we just can compare the congestion indicator >>> with the maximum of 2 random values (= thinking twice and is resulting in a >>> drop probability which is the square of the marking probability). This will >>> compensate the square root in Reno-like TCPs. If it is a problem to >>> generate 2 random values per packet, you can keep your previous random >>> value, as it is (pseudo) independent of the newly generated. >>> >>> As this is a very simple relation between marking and dropping, AND it >>> gives extra advantages, it is worth considering. The EXTRA advantages are: >>> - low latency AND high throughput (compared to low latency OR high >>> throughput) >>> - less variability in flow fairness between competing flows (because of the >>> high marking probability, the flows get more signals and will stray of >>> less). If you get one drop every 10 seconds, and you had bad luck that your >>> flow got 2 drops in a row, you have reduced your throughput by 4, compared >>> to the other flow who should have had the second mark, running still at >>> full throughput. >>> - The marking will scale to higher throughputs, every flow will get the >>> same signal rate independent from the throughput (preferably every >>> millisecond). It is a solution which scales to the future. >>> >>> If we want to promote the use of ECN, let's make sure we get all the >>> benefits, and have a solution that doesn't need to be revised after x years >>> anyway. This is an opportunity to do it better this time, with lots of >>> benefits which might convince people to finally use ECN. >>> >>> I propose to recommend the "think twice" concept, or at least describe its >>> extra benefits in the draft. >>> >> This draft is not specifying a new behavior for ECN, which is what you >> propose. Thus I think this is out of scope of this document. >> >> > > I might suggest this is an implementation of a relationship between ECN and > drop, based on an observation of how fairness might be achieved. > > The implementation doesn't belong, unless you have an appendix of interesting > implementation concerns.
Yes - > The observation that > • there is a relationship between ECN and drop > • there are fairness problems to consider, and > • there are values of the relationship that minimize or exclude the > fairness problem > is new, a genuinely good thing, and arguably deserves mention as a benefit. Every item in your list is so vague that I can't see the value of adding it. I think these things have to be coupled with a specific algorithm (such as the one described above) to make sense - but I think we agree that this document isn't the place for a new algorithm. Cheers, Michael _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
