[tcpm] [Iccrg] Re: ECN feedback discussion

[Michael Welzl]

Hi,

Yes I meant TCP. Sorry if my message got across as meaning "ECN is  
useless". This is certainly not what I was trying to say: my point is,  
we're perhaps facing a chicken-egg problem where operators won't have  
much incentive to support ECN as they probably don't see many ECN- 
capable packets in their path.

I'm all for changing that!

 From anecdotal evidence (including yours, based on the email below!)  
as well as the IMC'11 paper:
Measuring the State of ECN Readiness in Servers, Clients, and Routers
http://rbeverly.net/research/papers/ecn-imc11.pdf

it seems to me that turning on ECN support in general won't cause you  
harm (although it's apparently common to have it disabled somewhere  
along the path). I think this was perhaps different in the past.

Cheers,
Michael


On Nov 9, 2012, at 5:54 PM, Emmanuel Lochin wrote:

> 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