[tcpm] [Iccrg] Re: ECN feedback discussion

[Emmanuel Lochin]

Sorry but "none" means TCP? Because I use ECN (I take my network
engineer hat). And I am not the only one ... at least all my
sys/network admin colleagues are using it too. I use it to take QoS
decisions and to collect statistics on my network (the rationale of
using a counter comes from this observation).

Ok, ECN might be not used inside the whole network but who cares? All
my core devices are ECN compliant so why not using inside my own
network?
We know, following "The power of explicit congestion notification", A.
Kuzmanovic, Sigcomm05, that even a partial deployment of ECN brings
out benefit for the end-user. My GNU/Linux stack does not react to
ECN? Not a problem ... my access network does.

On my side, I use specific mechanisms conjointly with ECN inherited
from the QoS epoch. For instance, I can shape ECN feedbacks to slow
down connexions or to give a delay penalty to a specific flow.
Basically I use ECN like an "alert".

The problem is that we do not propose the right tools to operate with
ECN. ECN* was an attempt, Re-ECN is also a good example of a practical
usage of ECN.

Emmanuel





On 9 November 2012 16:11, Michael Welzl <michawe at ifi.uio.no> wrote:
>
> On Nov 9, 2012, at 4:06 PM, Yuchung Cheng wrote:
>
>> On Thu, Nov 8, 2012 at 11:49 PM, Mikael Abrahamsson <swmike at swm.pp.se>
>> wrote:
>>>
>>> On Thu, 8 Nov 2012, Yuchung Cheng wrote:
>>>
>>>> My worries are that we can design fancier stuff, in the end if it does
>>>> not
>>>> matter for applications, it does not matter. Is today's basic ECN not
>>>> being
>>>> used b/c it's too basic?
>>>
>>>
>>>
>>> I'd imagine ECN isn't used today because nobody knows what it is and why
>>> it's good to use. It's like IPv6, it doesn't really solve anything for
>>> the
>>> individual entitiy (ISP|user|equipment vendor), but as a whole, it would
>>> be
>>> good if we had it.
>>>
>>> I would also venture to say that congestion used to happen in the core
>>> and
>>> distribution. This is not really the case anymore, now congestion happens
>>> much closer to the edge, which is also the place where there is least
>>> homogenous control and thus harder to coordinate any technology.
>>>
>>> I have been running with ECN on, on most my machines for years now, just
>>> to
>>> make sure it doesn't break anything. When it was first implemented in the
>>> Linux kernel, ECN broke a lot of things. PIX firewalls for instance,
>>> dropped
>>> ECN packets. This is not the case anymore as far as I can tell, I haven't
>>> noticed any ECN related problem at all since I re-enabled it, hm, 3-4
>>> years
>>> ago perhaps.
>>>
>>> To get ECN (and other more advanced tech) into production networks, we
>>> need
>>> to be able to explain to users and manufacturers (and ISPs) what good it
>>> does, and how it can make their life metter. From the bufferbloat
>>> discussion, I'd say this is quite hard, since most don't even know how
>>> TCP
>>> works in conjunction with large buffers, much less the difference between
>>> different TCP algorithms. So teaching about benefits of ECN is quite
>>> hard.
>>>
>>> ECN is a good idea. IPv6 is a good idea. IPv6 is now happening (slowly)
>>> because IPv4 ran out. Nothing happened really for 5-10 years because IPv6
>>> didn't really solve any problem people thought they had. ECN is the same
>>> thing. ECN makes the network more efficient, in that it doesn't drop the
>>> packet if there is congestion. But how does that help the individual end
>>> user? That's harder to explain.
>>>
>>> Sorry for not being able to give any constructive suggestions on how to
>>> solve the problem of lack of ECN support, but if we can get some
>>> consensus
>>> about why ECN hasn't been implemented, perhaps that helps us making
>>> future
>>> decisions?
>>
>> +1
>>
>> ECN has many good things but it's not used. If we are going to develop
>> a "useful" ECN+ maybe we should ask why the operators don't use ECN.
>> And I know many ops guy that know extremely well about TCP so maybe
>> they have valid reasons.
>
>
> Chicken-egg, I suppose: why support something that noone uses?
>
> Cheers,
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> tcpm at ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm