Sorry for jumping in late. <br><br>"According to RFC 3168, senders must react to ECN just as if packets had
been dropped. This is to maintain fairness between ECN-compatible and
non-compatible flows. Because of this requirement, AQMs cannot ECN-mark packets more
aggressively than it drops packets from non-ECN-capable flows - else
ECN-marked flows would be at a disadvantage."<br><br>We (University of Goettingen and K.K. Ramakrishnan (AT & T) had earlier proposed (and performed experiments) to use ECN for LEDBAT like flows. As soon as such flows see ECN marking, they would back-off to allow other flows to get more of the bandwidth. In scenarios where ECN enabled LEDBAT flows co-exist with many normal flows, RFC 3168 would be fine since it was required that ECN enabled LEDBAT like flows are at a disadvantage. But in scenarios where most flows were LEDBAT like flows, reducing the congestion window by half on observing ECN marking resulted in lower overall throughput due to high fluctuations. You can find the papers and results in the following links:<br>
<a href="http://www.net.informatik.uni-goettingen.de/publications/1754/NF-TCP_Networking2011.pdf">www.net.informatik.uni-goettingen.de/publications/1754/NF-TCP_Networking2011.pdf</a><br><a href="http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techreport.pdf">http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techreport.pdf</a><br>
<br>Therefore in my opinion, it would make make sense to evaluate the effect of changing the current behavior of reducing the congestion window by half on observing ECN markings to other variants such as decrease by 1/4th and so on.<br>
<br>Mayutan<br><br><br><div class="gmail_quote">On Mon, Oct 29, 2012 at 5:27 PM, Mikael Abrahamsson <span dir="ltr"><<a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Mon, 29 Oct 2012, Michael Welzl wrote:<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The bottleneck is often the last mile. So often it's perhaps more important what my modem does than what ISPs do inside their network somewhere... there, turning on ECN can't be such a big deal, as e.g. the buffer bloat folks are putting (FQ_)CoDel in their CeroWrt?<br>
</blockquote>
<br></div>
The problem is not getting these distributions to adopt it, it's to get Dlink, Netgear, Linksys et al to implement it into their mainstream firmware images.<br>
<br>
But, as we all are headed for an ETTx world, it's quite likely we will all sit behind small buffer devices that'll be the chokepoint of our Internet connection, what good does ECN do there?<div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se" target="_blank">swmike@swm.pp.se</a><br>
<br>
______________________________<u></u>_________________<br>
Iccrg mailing list<br>
<a href="mailto:Iccrg@cs.ucl.ac.uk" target="_blank">Iccrg@cs.ucl.ac.uk</a><br>
<a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" target="_blank">http://oakham.cs.ucl.ac.uk/<u></u>mailman/listinfo/iccrg</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mayutan Arumaithurai<br>0049-551-2712647 (Home number) <br>0049-176-20322049 (mobile number)<br>