<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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. <div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-ken<br><div><br></div><div><br><div><div>On Aug 4, 2009, at 1:41 PM, Bob Briscoe wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div> Ken,<br><br> [iccrg folks, please read down the thread to see Ken's addition to this thread, which is pending in the iccrg moderator's queue.]<br><br> Were your tests using UDP packets, or TCP?<br> And did any results differ depending on the direction between the same two endpoints?<br><br> <br> Bob<br><br> At 17:43 04/08/2009, ken carlberg wrote:<br><br> <br> <blockquote type="cite" class="cite" cite="">Begin forwarded message:<br><br> <blockquote type="cite" class="cite" cite=""> <font face="Helvetica, Helvetica" size="4"><b>From: </b>ken carlberg <<a href="mailto:ken.carlberg@gmail.com">ken.carlberg@gmail.com</a> ><br> <b>Date: </b>August 3, 2009 9:34:53 PM EDT<br> <b>To: </b><a href="mailto:iccrg@cs.ucl.ac.uk">iccrg@cs.ucl.ac.uk</a><br> <b>Cc: </b>Colin Perkins <<a href="mailto:csp@csperkins.org">csp@csperkins.org</a>>, Ingemar Johansson S <<a href="mailto:ingemar.s.johansson@ericsson.com"> ingemar.s.johansson@ericsson.com</a>>, Magnus Westerlund <<a href="mailto:magnus.westerlund@ericsson.com"> magnus.westerlund@ericsson.com</a>>, Piers O'Hanlon <<a href="mailto:p.ohanlon@cs.ucl.ac.uk">p.ohanlon@cs.ucl.ac.uk</a> ><br> <b>Subject: Re: [Iccrg] Is ECN too complicated?<br> </b></font><br> Hi,<br><br> Bob Briscoe forwarded me the following message, so I'll try and give a reasonable response (while suffering from some jet lag)...<br><br> 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.<br><br> 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.<br><br> -ken<br><br> ps, I'd also subscribe to the theory that backbone providers can't be bothered with zero'ing out the ECN field.<br><br> <br> <blockquote type="cite" class="cite" cite=""> <blockquote type="cite" class="cite" cite="">Date: Mon, 03 Aug 2009 18:28:00 +0100<br> To: Mikael Abrahamsson <<a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a>><br> From: Bob Briscoe <<a href="mailto:rbriscoe@jungle.bt.co.uk">rbriscoe@jungle.bt.co.uk</a> ><br> Subject: Re: [Iccrg] Is ECN too complicated?<br> Cc: John Leslie <<a href="mailto:john@jlc.net">john@jlc.net</a>>, iccrg IRTF list <<a href="mailto:iccrg@cs.ucl.ac.uk">iccrg@cs.ucl.ac.uk</a>><br> Bcc: ƒ\LTR\Tech\IN ICCRG<br><br> Mike,<br><br> The guys proposing ECN in RTP say their limited tests have found that ECN-capable packets get cleared to 00 on some paths.<br><br> 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.<br><br> 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."<br><br> <br><br> Bob<br><br> At 14:10 31/07/2009, Mikael Abrahamsson wrote:<br> <blockquote type="cite" class="cite" cite="">On Fri, 31 Jul 2009, John Leslie wrote:<br><br> <blockquote type="cite" class="cite" cite="">We do need them to leave ECN marking alone. (Has someone documented<br> which core router do and don't?)</blockquote><br> 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).<br><br> <blockquote type="cite" class="cite" cite="">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.</blockquote><br> 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.<br><br> This is for 10G and 40G interfaces.<br><br> --<br> Mikael Abrahamsson email: <a href="mailto:swmike@swm.pp.se">swmike@swm.pp.se</a><br><br> _______________________________________________<br> Iccrg mailing list<br> <a href="mailto:Iccrg@cs.ucl.ac.uk">Iccrg@cs.ucl.ac.uk</a><br> <a href="http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg" eudora="autourl"> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg</a></blockquote><br> ________________________________________________________________<br> Bob Briscoe, Networks Research Centre, BT Research</blockquote><br> ________________________________________________________________<br> Bob Briscoe, Networks Research Centre, BT Research</blockquote></blockquote></blockquote> <x-sigsep><p> ________________________________________________________________<br> Bob Briscoe, Networks Research Centre, BT Research</p></x-sigsep></div> </blockquote></div><br></div></div></body></html>