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

[Piers O'Hanlon]

On 29 Oct 2012, at 16:27, Mikael Abrahamsson 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.
> 
There are a some that have ECN - like Thomson/Technicolor who represent a large installed base in the UK at least (and probably in other parts of Europe too). Though the functionality is currently not switched on in domestic deployments - though can be by hand.

> 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?
> 
Well if ECN was enabled on the inbound link then an ECN-enabled TCP connection could actually relatively safely signal back to the sender (in the usual way with ECN TCP flags) and lead to some ECN based congestion control for those flows. But the outbound bandwidth can be quite contentious so ECN could also be of value there but the ECN marks would currently mostly get lost... 

But I guess it's possible for the gateway to mark outgoing packets and potentially maintain that state until it sees the returning corresponding returning ACK to which it could then add the 'mark' to.... Anyone looked at this?

Piers


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