[Iccrg] RE: Iccrg Digest, Vol 45, Issue 13
Ingemar Johansson S
ingemar.s.johansson at ericsson.com
Mon Aug 31 12:24:40 BST 2009
Hi Mirja
Of all the nodes that I pinged I did not see any case where ECN-CE (t=3) was set.
Did some extra testing this weeked and my (final ?) result seems to be that out of 46 hosts (webservers) that I tracerouted, 17 cleared the ECN bits. In 7 cases the ECN bits was cleared by intermediate nodes. I tracked down these nodes and found that likely two ISP's cleared the ECN bits, drop me a note if you want the IP addresses (don't want to point fingers in public)
My conclusion is that webservers are likely to clear the ECN bits. It is however much less likely that intermediate nodes clear the ECN bits but it may happen.
Regards
Ingemar
> -----Original Message-----
> From: iccrg-bounces at cs.ucl.ac.uk
> [mailto:iccrg-bounces at cs.ucl.ac.uk] On Behalf Of
> iccrg-request at cs.ucl.ac.uk
> Sent: den 31 augusti 2009 13:12
> To: iccrg at cs.ucl.ac.uk
> Subject: Iccrg Digest, Vol 45, Issue 13
>
> Send Iccrg mailing list submissions to
> iccrg at cs.ucl.ac.uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> or, via email, send a message with subject or body 'help' to
> iccrg-request at cs.ucl.ac.uk
>
> You can reach the person managing the list at
> iccrg-owner at cs.ucl.ac.uk
>
> When replying, please edit your Subject line so it is more
> specific than "Re: Contents of Iccrg digest..."
>
>
> Today's Topics:
>
> 1. Re: RE: Testing ECN support for UDP flows (Mirja Kuehlewind)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 31 Aug 2009 10:41:54 +0200
> From: Mirja Kuehlewind <mirja.kuehlewind at ikr.uni-stuttgart.de>
> Subject: Re: [Iccrg] RE: Testing ECN support for UDP flows
> To: iccrg at cs.ucl.ac.uk
> Message-ID: <200908311041.54154.mirja.kuehlewind at ikr.uni-stuttgart.de>
> Content-Type: Text/Plain; charset="iso-8859-1"
>
> Hi Ingemar,
>
> I have one more question regarding you tests: Did you have
> the case that you set t=1 or t=2 and got a response with t=3
> (so was there a router reaction on the ECN bits to signal
> congestion)?
>
> Thanks,
> Mirja
>
>
> On Friday 28 August 2009 09:14:57 Ingemar Johansson S wrote:
> > 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 !
> > > >> > *******************************************
> >
> > _______________________________________________
> > Iccrg mailing list
> > Iccrg at cs.ucl.ac.uk
> > http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>
> --
> -------------------------------------------------------------------
> Dipl.-Ing. Mirja Kühlewind
> Institute of Communication Networks and Computer Engineering
> (IKR) University of Stuttgart, Germany Pfaffenwaldring 47,
> D-70569 Stuttgart
>
> web: www.ikr.uni-stuttgart.de
> email: mirja.kuehlewind at ikr.uni-stuttgart.de
> tel: +49(0)711/685-67973
> -------------------------------------------------------------------
>
>
>
> ------------------------------
>
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
> End of Iccrg Digest, Vol 45, Issue 13
> *************************************
>
More information about the Iccrg
mailing list