Subject: [tsv-area] Testing ECN support for UDP flows

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 20 Aug 2009 13:43:49 +0200

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

---

From: ken carlberg <[email-masked]>
Date: Thu, 20 Aug 2009 09:49:45 -0400

Ingemar,

This particular response may be best for the ICCRG list and its  
research view of things, but would it be possible to accomplish some  
of what you want to do directly or indirectly through PlanetLab?  I  
don't recall the connectivity requirements and layout for PlanetLab,  
but to avoid ECN info lost from encapsulated traffic between PlanetLab  
sites, perhaps one could find multi-homed hosts that can also be  
reached via the Internet.  And since the hosts are targeted for  
research work, one should be able to add some of the test software you  
are speaking of below.  (but this is just an educated guess on my part)

-ken

On Aug 20, 2009, at 7:43 AM, Ingemar Johansson S wrote:

> 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 ?)
> 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.
>

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Thu, 20 Aug 2009 17:37:39 +0100

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.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 21 Aug 2009 09:10:36 +0200

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: [email-masked] [mailto:[email-masked]] 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:
> 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
> >

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 21 Aug 2009 11:08:57 +0200 (CEST)

On Fri, 21 Aug 2009, Ingemar Johansson S wrote:

> 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.

http://technet.microsoft.com/en-us/magazine/2007.02.cableguy.aspx

In some versions of Windows you have to change the registry to be allowed 
to set any TOS bits, perhaps this is what's missing?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Fri, 21 Aug 2009 10:40:13 +0100

2009/8/21 Mikael Abrahamsson <[email-masked]>:
>> traceroute tests on our Linux boxes next week when I really start working.
>> It could be that this will do.
>
> In some versions of Windows you have to change the registry to be allowed to
> set any TOS bits, perhaps this is what's missing?
>
Yes and as Jonathon Lennox pointed out in the AVT WG it's no longer
possible  to set the TOS bit directly in Vista (the registry tweak no
longer works) as mentioned in the above article. It seems one has to
use their QoS APIs and I don't think they allow you to touch the ECN
bits.

Piers

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Fri, 21 Aug 2009 10:47:43 +0100

> 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 fault…
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.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 21 Aug 2009 12:39:56 +0200

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 

> Sent: den 21 augusti 2009 11:48
> To: Ingemar Johansson S
> > 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 
> > 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:
> http://technet.microsoft.com/en-us/library/bb726965.aspx#ctl00
> _MTContentSelector1_mainContentContainer_ctl05
> 
> Behalf Of 
> >> Piers O'Hanlon
> >> 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.
> routers as 
> >> 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.
> >>
> >> there is any ?) So... how do I best test this on a larger scale ?
> >> >
> >> 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.
> >> >
> >> 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.
> >> >
> >> 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.
> >> >

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 24 Aug 2009 08:22:15 +0200

Hi

Thanks for the input, seems like it is just an unnecessary complication to run on an MS-Windows PC. 

/Ingemar

> Sent: den 21 augusti 2009 11:40
> To: Ingemar Johansson S
> Cc: tsv-area; iccrg; Colin Perkins; carlberg; Mikael Abrahamsson
> Subject: Re: [tsv-area] Testing ECN support for UDP flows
> 
> 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.
> > In some versions of Windows you have to change the registry to be 
> > allowed to set any TOS bits, perhaps this is what's missing?
> >
> Yes and as Jonathon Lennox pointed out in the AVT WG it's no 
> longer possible  to set the TOS bit directly in Vista (the 
> registry tweak no longer works) as mentioned in the above 
> article. It seems one has to use their QoS APIs and I don't 
> think they allow you to touch the ECN bits.
> 
> Piers
> 
> > --

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 14:26:03 +0100

I've been doing some similar tests on setting the "reserved" flag in the IP header (evil bit) and have given up trying to do it in Windows since they have blocked a lot of access to the raw IP socket...

Toby

____________________________________________________________________ 
Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ingemar Johansson S
> Sent: 24 August 2009 07:22
> To: Piers O'Hanlon
> Cc: iccrg; tsv-area
> Subject: [Iccrg] RE: [tsv-area] Testing ECN support for UDP flows
> 
> Hi
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg