Hi, Below:
> On 25. mar. 2015, at 13.12, De Schepper, Koen (Koen) > <[email protected]> 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. Cheers, Michael _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
