[Iccrg] Why don't we stop treating ECN and loss similarly?

[Mayutan A.]

Sorry for jumping in late.

"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."

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:
www.net.informatik.uni-goettingen.de/publications/1754/NF-TCP_Networking2011.pdf
http://www.net.informatik.uni-goettingen.de/publications/1718/NF-TCP-techreport.pdf

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.

Mayutan


On Mon, Oct 29, 2012 at 5:27 PM, Mikael Abrahamsson <swmike at swm.pp.se>wrote:

> On Mon, 29 Oct 2012, Michael Welzl wrote:
>
>  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?
>>
>
> 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.
>
> 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?
>
>
> --
> Mikael Abrahamsson    email: swmike at swm.pp.se
>
> ______________________________**_________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/**mailman/listinfo/iccrg<http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg>
>



-- 
Mayutan Arumaithurai
0049-551-2712647 (Home number)
0049-176-20322049 (mobile number)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20121030/ff0138c4/attachment.html