[Iccrg] RE: Testing ECN support for UDP flows
Ingemar Johansson S
ingemar.s.johansson at ericsson.com
Fri Aug 21 08:10:36 BST 2009
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.
I have not looked at PlanetLab earlier, will have a look at it, thanks for the tip.
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 !
> > *******************************************
> >
>
More information about the Iccrg
mailing list