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. 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.
--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dav...@spamcop.net | -- Mark Twain
_______________________________________________
aqm mailing list
aqm@ietf.org
https://www.ietf.org/mailman/listinfo/aqm
