[Iccrg] RE: Testing ECN support for UDP flows

[Ingemar Johansson S]

Hi

I tried the netsh command but still it does not seem to work. 

The problem is also that the test app seems to do a SYN with ECE and CWD set, this is correct, according to RFC3168 the server should respond a SYN-ACK with ECE, this does not happen however, still the test app marks the test as successful..

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