<html>
<body>
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></x-sigsep>
________________________________________________________________<br>
Bob
Briscoe,
Networks Research Centre, BT Research</body>
</html>