[Iccrg] RE: Testing ECN support for UDP flows

Fri Aug 28 08:14:57 BST 2009

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 !
> >> > *******************************************
> >> >
> >>
> >
> 