[Iccrg] Is ECN too complicated?

[ken carlberg]

Actually, we did this with ping -z (depending on your flavor of OS, to  
set the ToS byte) , so ICMP packets with echo-request/echo-response.

and ouch, hadn't thought about the reverse direction, as such.  I  
ping'ed the path of the hops individually of one the leaf providers  
where we saw the zero'ed ECN field, and each hop of the "offending"  
provider responded with a correctly reflected value.  That is what led  
me to believe that perhaps the headache lies in the cable modem.

but again, i need to reiterate that the testing is no where near  
exhaustive, nor are all the variables accounted for.  we'll do some  
more tests down the line and see what we come up with.

-ken


On Aug 4, 2009, at 1:41 PM, Bob Briscoe wrote:

> Ken,
>
> [iccrg folks, please read down the thread to see Ken's addition to  
> this thread, which is pending in the iccrg moderator's queue.]
>
> Were your tests using UDP packets, or TCP?
> And did any results differ depending on the direction between the  
> same two endpoints?
>
>
> Bob
>
> At 17:43 04/08/2009, ken carlberg wrote:
>
>
>> Begin forwarded message:
>>
>>> From: ken carlberg <ken.carlberg at gmail.com >
>>> Date: August 3, 2009 9:34:53 PM EDT
>>> To: iccrg at cs.ucl.ac.uk
>>> Cc: Colin Perkins <csp at csperkins.org>, Ingemar Johansson S < ingemar.s.johansson at ericsson.com 
>>> >, Magnus Westerlund < magnus.westerlund at ericsson.com>, Piers  
>>> O'Hanlon <p.ohanlon at cs.ucl.ac.uk >
>>> Subject: Re: [Iccrg] Is ECN too complicated?
>>>
>>> Hi,
>>>
>>> Bob Briscoe forwarded me the following message, so I'll try and  
>>> give a reasonable response (while suffering from some jet lag)...
>>>
>>> Piers O'hanlon from UCL and I have done some tests from a handful  
>>> of sites from the UK and Washington DC to UCL.  It was clearly not  
>>> an extensive sampling, but we did find cases where the ToS byte  
>>> (and more specifically, the ECN field) was zero'ed out as opposed  
>>> to having the packet be dropped.  I think Piers came across two  
>>> out of three tests (from different source locations, and thus  
>>> different leaf providers) zero'ed out the field.
>>>
>>> In my case, tests from the customer sites of one of two cable  
>>> providers to UCL failed.  I have a couple of summer interns doing  
>>> some more tests for me from other local providers in the DC area,  
>>> but I need to meet up with them later this week to go over the  
>>> results and make sure they did things correctly.  However, I  
>>> suspect that the problem in at least one instance may lie with the  
>>> cable modem.  I still need to perform the test with a different  
>>> home router, so tests are on-going to eliminate anomalies and  
>>> outlyers.
>>>
>>> -ken
>>>
>>> ps, I'd also subscribe to the theory that backbone providers can't  
>>> be bothered with zero'ing out the ECN field.
>>>
>>>
>>>>> Date: Mon, 03 Aug 2009 18:28:00 +0100
>>>>> To: Mikael Abrahamsson <swmike at swm.pp.se>
>>>>> From: Bob Briscoe <rbriscoe at jungle.bt.co.uk >
>>>>> Subject: Re: [Iccrg] Is ECN too complicated?
>>>>> Cc: John Leslie <john at jlc.net>, iccrg IRTF list <iccrg at cs.ucl.ac.uk 
>>>>> >
>>>>> Bcc: ƒ\LTR\Tech\IN ICCRG
>>>>>
>>>>> Mike,
>>>>>
>>>>> The guys proposing ECN in RTP say their limited tests have found  
>>>>> that ECN-capable packets get cleared to 00 on some paths.
>>>>>
>>>>> This may be a case of firewalls with the rule "deny all, unless  
>>>>> known to be safe," rather than "allow all, unless known to be  
>>>>> unsafe". I think they used UDP packets and ECN on TCP is known  
>>>>> to be safe, whereas ECN on UDP is not known to be unsafe.
>>>>>
>>>>> Perhaps they should take advice from Bob Dylan, who said  
>>>>> (paraphrasing) "Don't drop packets, that you don't understand;  
>>>>> For the times they are a-changing."
>>>>>
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>> At 14:10 31/07/2009, Mikael Abrahamsson wrote:
>>>>>> On Fri, 31 Jul 2009, John Leslie wrote:
>>>>>>
>>>>>>> We do need them to leave ECN marking alone. (Has someone  
>>>>>>> documented
>>>>>>> which core router do and don't?)
>>>>>>
>>>>>> I don't know of any core router that will zero the ECN marking,  
>>>>>> all I have seen either have ECN support (used in their WRED  
>>>>>> schemes) or they don't know anything about ECN and just ignores  
>>>>>> the bits and just passes the packet unchanged (ECN-wise).
>>>>>>
>>>>>>> I don't feel the need for more detail of why intelligence in  
>>>>>>> core routers is expensive. What we do need is an upper bound  
>>>>>>> on packet drop (without ECN marking coming first) in actual  
>>>>>>> core routers.
>>>>>>
>>>>>> From what I have seen in recent major vendors, the new  
>>>>>> platforms seem to have around 50-200ms of buffers, coming down  
>>>>>> from the common 600ms 5+ years back.
>>>>>>
>>>>>> This is for 10G and 40G interfaces.
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>
>>>>> ________________________________________________________________
>>>>> Bob Briscoe,               Networks Research Centre, BT Research
>>>>
>>>> ________________________________________________________________
>>>> Bob Briscoe,               Networks Research Centre, BT Research
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090804/f7a0105c/attachment.html