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: [email protected] [mailto:[email protected]] 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 <[email protected]>: > > 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: [email protected] [mailto:[email protected]] 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 <[email protected]>: > >> > 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 ! > >> > ******************************************* > >> > > >> > > >
