[Iccrg] RE: Testing ECN support for UDP flows

Mon Aug 31 09:41:54 BST 2009

Hi Ingemar,

I have one more question regarding you tests: Did you have the case that you 
set t=1 or t=2 and got a response with t=3 (so was there a router reaction on 
the ECN bits to signal congestion)? 

Thanks,
Mirja

On Friday 28 August 2009 09:14:57 Ingemar Johansson S wrote:
> Hi
>
> Managed to do some initial tests, for starters I tried ECN support for ICMP
> using the linux traceroute command
>
> >sudo traceroute -I -t x host
>
> where x is the ToS byte.
>
> The test set was
> + 21 arbitary hosts picked at whim
>    (15 responded to traceroute with t=0)
> + 13 hosts from the ECN hall of shame list
> http://urchin.earth.li/cgi-bin/ecn.pl (5 responded to traceroute with t=0)
>
> The method was to find the hosts that clears the ECN bits and then
> traceroute the nodes along the path to see where the ECN bits are cleared.
> I tried up to five values on the ToS field (t=0,1,2,3,255)
>
> Sofar I see two kinds of behaviors
> 1) ECN cleared in the other endpoint (webserver)
> 2) ECN cleared by an ISP (not by endpoint)
>
> Issue 1) Happens with hostnames like www.3gpp.org,  www.telia.com and some
> others. However if one traceroute the closest visible node before the
> endpoint one can see that the ECN bits are not cleared. The conclusion is
> then that the issue is in the IP stack  of the webserver (ECN not enabled?)
> and not along the path. This issue was discovered in 7 out of 15 of the
> responding arbitary hosts that I picked. None of the hosts showed a
> tendency to drop packets that had a ToS field other than zero.
>
> Issue 2) Happens with the hostnames www.walmart.be, www.teletch.co.nz and
> www.negocios.pt, all of them are on the ECN hall of shame list. Closer
> inspection however reveals that the problem is most likely not the
> endpoints. If one traceroute nodes along the path one can see that ECN is
> cleared somewhere along the path. One conclusion here is that there are
> indeed some ISPs that clear the ECN bits. Again, none of the hosts showed a
> tendency to drop packets that had a ToS field other than zero.
>
> In general. When the ToS value was set to 255 the DSCP field was reset to
> DF. I did not investigate in more detail where this happened. In two of the
> cases the DSCP field was set to 0xA (AF) in the ICMP echo-reply, no matter
> what the ToS was set to in the ech-request.
>
> In order to see how likely issue 2 above is one can maybe traceroute border
> gateways instead of endpoint hosts, if possible how do one find these IP
> addresses. ?
>
> Regards
> Ingemar
>
> > -----Original Message-----
> > From: p.ohanlon at gmail.com [mailto:p.ohanlon at gmail.com] On
> > Behalf Of Piers O'Hanlon
> > Sent: den 21 augusti 2009 11:48
> > To: Ingemar Johansson S
> > Cc: iccrg; tsv-area; carlberg; Colin Perkins; Magnus Westerlund
> > Subject: Re: Testing ECN support for UDP flows
> >
> > 2009/8/21 Ingemar Johansson S <ingemar.s.johansson at ericsson.com>:
> > > Hi
> > >
> > > Tried with an MS-Windows version of tracert (ftrace), it
> >
> > was supposed to be able to set the ToS field. However it
> > seems like when I run wireshark that the modified ToS field
> > does not stick, it could be some Windows specific feature
> > that simply clears the ToS field. I will try some traceroute
> > tests on our Linux boxes next week when I really start
> > working. It could be that this will do.
> >
> > > I also tried
> >
> > http://www.microsoft.com/windows/using/tools/igd/default.mspx
> > as it claimed that my homelaptop is indeed ECN capable. The
> > test seems however to be a bit limited and perhaps a bit
> > faulty. The SYN packet sets ECE and CWR according to RFC3168,
> > the ECE flag is however not set in the SYN-ACK packet, still
> > the ECN test is marked as passe!. Also the ECN bits are never
> > set in any subsequent data traffic which means that AFAIK
> > nothing is really tested.
> >
> > If your home laptop is Vista then it will support ECN for TCP
> > but it needs to be enabled using netsh:
> > netsh interface tcp set global ecncapability=enabled
> >
> > See:
> > http://technet.microsoft.com/en-us/library/bb726965.aspx#ctl00
> > _MTContentSelector1_mainContentContainer_ctl05
> >
> > > I have not looked at PlanetLab earlier, will have a look at
> >
> > it, thanks for the tip.
> >
> > Sure.
> >
> > Piers.
> >
> > > Regards
> > > /Ingemar
> > >
> > >> -----Original Message-----
> > >> From: p.ohanlon at gmail.com [mailto:p.ohanlon at gmail.com] On
> >
> > Behalf Of
> >
> > >> Piers O'Hanlon
> > >> Sent: den 20 augusti 2009 18:38
> > >> To: Ingemar Johansson S
> > >> Cc: iccrg; tsv-area; carlberg; Colin Perkins; Magnus Westerlund
> > >> Subject: Re: Testing ECN support for UDP flows
> > >>
> > >> Hi Ingmar,
> > >>
> > >> I found that one could do some quite useful tests using (on
> > >> Linux) traceroute -t <tos> hostname. Linux machines seem
> >
> > to reflect
> >
> > >> the TOS byte contents even in ICMP error responses and ICMP echos.
> > >> Though DSCP bits are usually reset the the ECN bits are more
> > >> resilient... Since traceroute uses UDP as default it's
> >
> > quite a neat
> >
> > >> test. And it seems that ICMP time exceeded responses are
> >
> > more likely
> >
> > >> to get thru router filters than plain ICMP responses - and the can
> > >> carry ECN markings.
> > >> Though it seems that that there maybe some bugs in certain
> >
> > routers as
> >
> > >> I've seen the TOS byte reversed in some replies?!
> > >>
> > >> As ken mentioned - I was thinking that wide area testing could be
> > >> most easily done using PlanetLab - though as far as I'm aware it
> > >> doesn't tunnel packets - though packet timings can get
> >
> > skewed by the
> >
> > >> vserver implementation. Also the network sharing system in use on
> > >> Planetlab can make things tricky if someone else on that machine
> > >> using the same ports.
> > >>
> > >> Additionally it may be worth checking with the methodology used by
> > >> Floyd et al when they did their [tcp] tbit testing:
> > >> http://www.icir.org/tbit/ecn-tbit.html
> > >>
> > >> Piers.
> > >>
> > >> 2009/8/20 Ingemar Johansson S <ingemar.s.johansson at ericsson.com>:
> > >> > Hi
> > >> >
> > >> > Sorry for the cross-post, I would believe that it is best
> > >>
> > >> to reply to tsv-area only.
> > >>
> > >> > I have previously asked people regarding the support of ECN
> > >>
> > >> especially
> > >>
> > >> > for UDP flows.. There seems to be a lot of uncertanities
> > >>
> > >> around this and in general it is difficult to get any
> >
> > clear view (if
> >
> > >> there is any ?) So... how do I best test this on a larger scale ?
> > >>
> > >> > 1) UDP port 7: The idea is to ping other host with UDP
> > >>
> > >> packets on port 7, some of the packets are ECT(0)/(1) marked, some
> > >> are not. If I get things right, port 7 is not genarally
> >
> > enabled these
> >
> > >> days, are there any host around that are known to leave
> >
> > port 7 open.
> >
> > >> > 2) Modified STUN client: The idea is to do STUN requests to
> > >>
> > >> a number of STUN servers. Some of the STUN requests are ECT.
> > >>
> > >> > 3) Setup a mesh of volountary hosts that installs a
> > >>
> > >> software that agrees to communicate via a specific port, the hack
> > >> would need to implement some means to communicate NAT'ed addresses
> > >> etc. This would require some logistic effort to gather up
> >
> > volounteers
> >
> > >> for the test-fest.
> > >>
> > >> > Ideally the test should be able to tell if possible ECN
> > >>
> > >> issues are located close to the user (e.g firewalls, WLAN routers
> > >> etc) or in the core-networks. Also I believe that running
> >
> > UDP would
> >
> > >> be beneficial even though I know some people have already
> >
> > tried with
> >
> > >> ICMP.
> > >>
> > >> > Which would be the best alternative in order to do such a
> > >>
> > >> test ?, comments/suggestions are welcome.
> > >>
> > >> > Regards
> > >> > Ingemar
> > >> >
> > >> > *******************************************
> > >> > Ingemar Johansson
> > >> > Senior Research Engineer, IETF "nethead"
> > >> > EAB/TVK - Multimedia Technologies
> > >> > Ericsson Research Ericsson AB
> > >> > Box 920 S-971 28 Luleå, Sweden
> > >> > Tel: +46 (0)10 7143042
> > >> > ECN: 852-43042
> > >> > ECC: 852-19042
> > >> > Mobile: +46 (0)730 783289
> > >> > Visit http://labs.ericsson.com !
> > >> > *******************************************
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

web: www.ikr.uni-stuttgart.de
email: mirja.kuehlewind at ikr.uni-stuttgart.de
tel: +49(0)711/685-67973
-------------------------------------------------------------------