Subject: [Iccrg] RE: Iccrg Digest, Vol 45, Issue 13
From: [email-masked] (Ingemar Johansson S)
Date: Mon Aug 31 12:13:20 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: den 31 augusti 2009 13:12
> To: [email-masked]
> Subject: Iccrg Digest, Vol 45, Issue 13
> 
> Send Iccrg mailing list submissions to
> 	[email-masked]
> 
> 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
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> 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 <[email-masked]>
> Subject: Re: [Iccrg] RE: Testing ECN support for UDP flows
> To: [email-masked]
> Message-ID: <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]] 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-masked]>:
> > > > 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-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:
> > > >> http://www.icir.org/tbit/ecn-tbit.html
> > > >>
> > > >> Piers.
> > > >>
> > > >> 2009/8/20 Ingemar Johansson S 
> <[email-masked]>:
> > > >> > 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
> > [email-masked]
> > 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: [email-masked]
> tel: +49(0)711/685-67973
> -------------------------------------------------------------------
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> End of Iccrg Digest, Vol 45, Issue 13
> *************************************
> 

From: [email-masked] (Mirja Kuehlewind)
Date: Mon Aug 31 09:30:48 2009
Subject: [Iccrg] RE: Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked] [mailto:[email-masked]] 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-masked]>:
> > > 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-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:
> > >> http://www.icir.org/tbit/ecn-tbit.html
> > >>
> > >> Piers.
> > >>
> > >> 2009/8/20 Ingemar Johansson S <[email-masked]>:
> > >> > 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
> [email-masked]
> 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: [email-masked]
tel: +49(0)711/685-67973
-------------------------------------------------------------------

From: [email-masked] (Ingemar Johansson S)
Date: Fri Aug 28 08:04:02 2009
Subject: [Iccrg] RE: Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked] [mailto:[email-masked]] 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-masked]>:
> > 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-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:
> >> http://www.icir.org/tbit/ecn-tbit.html
> >>
> >> Piers.
> >>
> >> 2009/8/20 Ingemar Johansson S <[email-masked]>:
> >> > 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: [email-masked] (toby.moncaster)
Date: Tue Aug 25 14:16:08 2009
Subject: [Iccrg] RE: [tsv-area] Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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 

> -----Original Message-----
> 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
> 
> Thanks for the input, seems like it is just an unnecessary complication
> to run on an MS-Windows PC.
> 
> /Ingemar
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Piers O'Hanlon
> > 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
> >
> > 2009/8/21 Mikael Abrahamsson <[email-masked]>:
> > > 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?
> > >
> > 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
> >
> > > --
> > > Mikael Abrahamsson ? ?email: [email-masked]
> > >
> >
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Ingemar Johansson S)
Date: Mon Aug 24 07:13:09 2009
Subject: [Iccrg] RE: [tsv-area] Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

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

/Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Piers O'Hanlon
> 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
> 
> 2009/8/21 Mikael Abrahamsson <[email-masked]>:
> > 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?
> >
> 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
> 
> > --
> > Mikael Abrahamsson ? ?email: [email-masked]
> >
> 

From: [email-masked] (Ingemar Johansson S)
Date: Fri Aug 21 11:30:01 2009
Subject: [Iccrg] RE: Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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-masked] [mailto:[email-masked]] 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-masked]>:
> > 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-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:
> >> http://www.icir.org/tbit/ecn-tbit.html
> >>
> >> Piers.
> >>
> >> 2009/8/20 Ingemar Johansson S <[email-masked]>:
> >> > 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: [email-masked] (Mikael Abrahamsson)
Date: Fri Aug 21 09:58:45 2009
Subject: [Iccrg] Re: [tsv-area] Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <Acohi3waP2Qt6Ju4SieBJBEQqzem4w==> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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: [email-masked] (Ingemar Johansson S)
Date: Fri Aug 21 08:00:55 2009
Subject: [Iccrg] RE: Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <Acohi3waP2Qt6Ju4SieBJBEQqzem4w==> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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:
> http://www.icir.org/tbit/ecn-tbit.html
> 
> Piers.
> 
> 2009/8/20 Ingemar Johansson S <[email-masked]>:
> > 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: [email-masked] (Douglas Leith)
Date: Thu Aug 20 20:13:12 2009
Subject: Fwd: [Iccrg] RG status update
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Lawrence,

Seeing this reminded me I was waiting for your comments on the last  
HTCP internet draft.  Do you have more detailed comments or should I  
just go with the ones already sent to the list ?

Doug

> HTCP
> http://tools.ietf.org/id/draft-leith-tcp-htcp-06.txt
> Status: initial reviews provided
> Actions: waiting for the authors to update the draft
>         need RG to writeup a short description of the findings for  
> TCPM
>

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[Verizon])
Date: Thu Aug 20 18:37:15 2009
Subject: [Iccrg] RG status update
Message-ID: <[email-masked]>

This is similar to material that Michael and I usually present at ICCRG
meetings, but since some people can't make it to them, and since we hope
to make progress not only at meetings, but in between too ... here's the
first of what we plan to submit to the list as periodic snapshots of the
group's progress and activities:

Document on Congestion Control in the RFC Series
------------------------------------------------
http://tools.ietf.org/id/draft-irtf-iccrg-cc-rfcs-07.txt
Status: in the RFC editor queue since 2008-11-10, reason:
        REF    draft-housley-iesg-rfc3932bis    NOT-RECEIVED
Actions: None; awaiting resolution of IRTF document stream process?

Document on Open Research Issues in Internet Congestion Control
---------------------------------------------------------------
http://tools.ietf.org/html/draft-irtf-iccrg-welzl-congestion-control-open-research-04
Status: felt to be complete; asked for final feedback from RG @ IETF 75
Actions:  Chairs will re-confirm with authors that this is "done" and submit to IRSG
          for publication week of 8/17/09

Document on Capacity Sharing Architecture
-----------------------------------------
http://trac.tools.ietf.org/group/irtf/trac/wiki/CapacitySharingArch
Status: still in startup phase
Actions: Editor team to update and sumbit draft-mathis-iccrg-unfriendly
         as something like draft-irtf-iccrg-capacity-sharing-arch

Proposed Experimental TCP Congestion Control Modifications
----------------------------------------------------------
Compound TCP
http://tools.ietf.org/id/draft-sridharan-tcpm-ctcp-02.txt
Status: ICCRG review completed and sent to TCPM
Actions: None

CUBIC
http://tools.ietf.org/id/draft-rhee-tcpm-cubic-02.txt
Status: initial reviews provided
Actions: waiting for the authors to update the draft
         need RG to writeup a short description of the findings for TCPM

HTCP
http://tools.ietf.org/id/draft-leith-tcp-htcp-06.txt
Status: initial reviews provided
Actions: waiting for the authors to update the draft
         need RG to writeup a short description of the findings for TCPM

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

From: [email-masked] (ken carlberg)
Date: Thu Aug 20 14:40:08 2009
Subject: [Iccrg] Re: Testing ECN support for UDP flows
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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:

> 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: [email-masked] (Ingemar Johansson S)
Date: Thu Aug 20 12:35:33 2009
Subject: [Iccrg] Testing ECN support for UDP flows
Message-ID: <[email-masked]>

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: [email-masked] ([email-masked])
Date: Wed Aug 19 14:21:19 2009
Subject: [Iccrg] Meeting minutes
Message-ID: <[email-masked]>

Hi,

The notes from our last meeting (taken by Joseph Ishac - thanks!)
are now available at:
http://www.ietf.org/proceedings/75/minutes/iccrg.txt

and at the bottom of this email.

Cheers,
Michael

----

ICCRG Notes:

Start Time: 9:02 am
Room State: Packed

No Bashing
First is ICCRG Status: No Comments

=====
Dimitri Papadimitriou
"Open Research Issues" Talk
=====
Wes: Lot of work has gone into this document, chairs think it's finished. 
Trying to close on this document, please put forth any final comments in
the next two weeks so that it can go to review.  (No additional comments
from room)

=====
Lawrence Stewart:
The future of congestion control: feedback from an implementer's perspective
30 mins (9:15)
======

(13:59) Bob Briscoe: Is the motivation of the offloading to get to those
working at high speeds or if it's more to do with other factors (doing
other things at high speed, interrupts, etc) - Bob thinks it's the latter.
Lawrence and Bob: agree on the clarification (that it is about the other
factors)

(18:25) Question off Mic (from the crowd): Have you looked at ECN behavior?
A: No, have not yet looked at ECN personally, there are implementations in
BSD, etc... but I've not worked with it for this.

(31:40) Aaron Falk: So you're saying that the I-Ds should state
packet/byte behavior differences - so you're saying that researchers
should understand what the differences are... should be part of describing
the performance.... a TMRG input point
A: Absolutely... important work that someone should do.  Some of these
issues don't come up unless you put it in the light of a particular
approach.
Aaron Falk: Nice candidate for a short RFC is to describe the Musts and
Shoulds of how you should be specifying congestion control
A: Definitely only highlight the key ones here, but I could see a document
detailing these and more.
Tim Shepard: If I had one version, couldn't you just figure out the other
- or might it not be that simple. - Appreciates the issues that can arise
from the two approaches (Path MTU discovery...)
A: Right there are a lot of issues... Certainly being more specific if
we're leaving things unspecified would be an excellent start
Mike Lambrets:  Works for an ISP.  Has users that complain about speed of
network (slow).  Would exposing tcp performance in a standard way be
within scope.  API to get those metrics... be able to answer the question:
"Is the download slow because of X reason?"
A: Gray area, isn't there an API for this already? in some part? API calls
to adapt behavior?
Aaron Falk (shout out): Thinks web 100 has that
A: Would be nice to have this to tune behavior, with an appliance application
ML: Yes, it's hard to do manually with Wireshark, etc...
A: Yes, it doesn't scale - it's a nightmare.
(Agreement, examples)
A: It would be nice to integrate with pcap libraries (author has some
effort in this)... should also be helping implementers more often.

(43:00) Bryan Ford:  Likes the results on delay and is a personal interest
area.  Not sure if this research group has looked at the detail of the
basic question - if it's possible for a CC algorithm in the wild to
realistically achieve a low delay and still be operable.
A: Personally, thinks the answer is yes... graceful degregation, if you
have a fat pipe, there's not much of a problem - but we need to
standardize the approaches.  Don't have a concrete answer, but the point
is to document these.
Wolfgang Beck (JABBER): ledbat might have some useful input to this.
A: Sure, the scavenger class TCP is interesting in certain uses.  Most
people are concerned with good TCP performance (tuned right), although not
completely up on all of ledbat's work.
S. Shalunov:  Remind everyone of ledbat... doesn't think it's a well
formed goal to try and fill buffers and at the same time keep them empty.
A: Thinks we show that it's not good to fill buffers completely
SS: Do you think it's possible to compete with NewReno "fairly" and
maintain low-delay... it pursues to goals of keeping the buffer both full
and empty at the same time ... how do you do that??
A: Clarifying position: More in favor of keeping the buffers "less full". 
There's more that we should be able to do to make customers happier, even
if we don't fully utilize the network
A: There are lot of different options you can tweak to get better
performance, in a home scenario (science labs might be a different
story)... like to make sure the default is good and does the least amount
of harm.
Joseph Ishac: Shouldn't your goal be to keep the network utilized and the
delays as low as possible... what that means to your buffers is not
necessarily so cut and dry
Bryan Ford: Is if possible to have tcp friendliness and empty buffers??
A: And it's a good one.
Wes: Go to the ledbat wg this afternoon
SS: Perplexed that the relationship between buffer occupancy and extra
delay isn't cut and dry.  It seems obvious that it's proportional.
Tim Shepard: It could be more complicated... it depends on how the queues
are serviced.  You can have multiple queues... etc.
A: It would be interesting to see what would happen if simple things like
priority or weighted queuing is put in routers.... or maybe just shrink
the buffers.
SS: I like that... you tell these people and they just do it? In the many
devices already deployed... (/sarcasm)
A: Sure, we'll piggyback this on IPv6 deployment... it's hard work... we
shouldn't work on the assumption that this will never change.  Would like
to see these recommendations come out from somewhere.
ML: Ethernet to home space has very little buffering... l3 switches with
ms buffers.  Agree that CPU manufactures should use fair queuing...
prioritize acks, etc...

=====
Bob Briscoe / Matt Mathis
Beyond TCP-friendly Design Team
30 minutes (53:00)
=====

(1:00:00) Aaron Falk: Question about the goals - how to shift to a new
capacity sharing arch... you want to do capacity sharing, understand how
to your going to implement it and how to migrate to it... is it really
that broad of scope?
A: Yes - both what is the target and how do we get there.
AF: process note - you need to have these teams have outgoing feedback to
share problems
A: Plan to use ICCRG list
Wes: Arch here means defining the pieces that would be needed and not
specifying the actual pieces to put into these slots.
AF (no mic): This goes beyond requirements right?
Wes: This is a feasible set of things that can be used, not specifying
specific pieces for each slot.
A: where do functions fit... and how do you accommodate existing stuff.
AF:  Do you believe you will develop and recommend mechanisms?
A: No. on either count... but would like to deprecate potentially.
AF: This isn't a mechanism development... ie: ReECN
A: NO... that's coming up next... this is beside that not in it.
A & Wes: Not to try and approve a particular architecture... Really need
to develop and architecture and see what we need, where current activities
sit.
??(A: Haven't really fully passed these thoughts past other authors,
chairs..)

A: Ask chairs if a particular diagram is a good record of this.
Wes: Thinks diagram is similar... just made up one that was better though
for Aaron in the plenary.
Aaron Falk: Notes that a RG can't publish BCP's
Tim Shepard (no mic): current practice or bcp?
ML: are you planing on deprecating Rfc 5033 with this document? (or
replacing)
A: Might not need to be... document doesn't say tcp friendly is good...
not very strict on recommendations.  Might be able to coexist.

(1:29:29) ??: Doesn't think the comparison is fair... TCP gets less CC
signals.
A: Right, because of it's behavior.
??: So overall it's still AIMD... your saying that if your getting a
constant flow of signals then you need to do AIAD?
A: Doesn't work like that... by working in the terms here, you will get
enough signals where TCP doesn't get enough as it gets faster.

(1:39:0) Dave Craig: Confused by goals, relentless wants to pick up more
loss to figure out the bw, but the policing is going to put a limit on the
congestion you can create.  Why would I want to run relentless if that's
going to put me up against the congestion limit faster.
A: Depends on how others play the game... and it is a tradeoff.  That
space is why I think congestion needs to be the right metric for the
internet space and why this needs to be figured out early.
Gorry Fairhurst: Re-ECN, Relentless, and then slides to say how we fit
this and more all together.  Interesting to see how we build something
with all these different mechanisms... Is that still a focus of this
activity... as we really need that still
A: Still of interest and we would like to get more involved.
GF: How do these things fight, and in different environments... is a very
interesting question
Bryan Ford: Doesn't this have a vulnerability to "rich jerks"... aren't
these preferential to folks (that can buy a lot of bandwidth)?  Or be able
to be a primary cause of the congestion.
A: You have a mechanism to mediate between rich jerk and congestion
(network)... use $$ from jerks to upgrade bottlenecks, ie.
BF: Two orthogonal items in moment fairness (at a granularity of per
flow/user) ... or done in high order metrics (number of bytes)
A: Would like to have an algorithm that could be used liberally, but there
might be conditionals to it in either case... and there will most
definitely be tussles.  I would like to see those play out.
Janardhan Iyengar: Can you say more about the transition in moving away
from the current solutions.
A: The transition is almost more away from a mind set (ie TCP Friendly). 
If we take those away, what new "Rules" do we use?  Not just the
mechanisms, but the mindset as well.  How to transition when the network
is doing policing in one area, but not in others, etc.  Do we need to say
something to operators?
Mike Lambrins: From experience in residential ethernet... trend has been
for more fast dumb devices... instead of being clever with what you have,
sometimes it is better to spend the $$ on just upgrading the system
operationally.  Better to look at a graph that doesn't flatline. 
Operationally... fast is the answer.
A: Exactly what I'm trying to do... trying to find the min - a place where
you just have ECN.
ML: If you only have a 5ms buffer, I don't see the point in ECN
A: technique you can run a token bucket as if you running at a slower rate...
ML: (understands the technique) Also just wanted to note how the ISP
community was moving (to faster devices)
A: Understood, but the assumptions are also changing as we now are having
things like window scalling changes, etc.
Doug G) If your not looking at tuplets... do you create an opportunity for
DOS attacks that happen in the middle of the network.
A) Yes it is an attack that Mark Handley thought up a while back.  There
might be a way of combating the situation by adjusting the behavior at the
application layer.  Example given was a DNS scenario.
DG) However, they're not causing the issue, and they have no control over
the policing (in this attack)
A) So yes the question is very important, a case we thought of - and a
solution needs to be worked out.  However, we need a good solution for
handling this congestion as well.

=====
Michael Welzl
MulTFRC
http://heim.ifi.uio.no/michawe/research/projects/multfrc/index.html
30 minutes (1:58:00)
=====

(2:13:00) Bob Briscoe: Clarifying... you don't get any more performance if
you're fighting yourself... if your self-congested
A: Sure if you own your own bottleneck - or the only one fighting for your
choke point.
Bryan Ford: Seems like you're most interested in N>1, and there are two
uses... be more aggressive against other users, the other is when your
self congested and your not getting the performance out of your access
link... but that's where these CC algorithms such as CUBIC come in.
A: But then you don't have some of these solutions for things like
multimedia traffic (no CUBIC for example, which you might use for file
transfers)
BF: So in terms of a specific number, the tcp spec has a magic number of 2
for the # of connections to be fair
A: (willing to compromise with 4 (from 6))
BF: Wanted to suggest the most interesting use case might be when N<1...
simple and safe short term way of allowing for a good starting point on
fair multipath behavior
A: (agrees on multipath behavior benefit)
Gorry: Have you looked at sharing with bursty traffic sources instead of
just continuous traffic sources.
A: Have not yet looked into that.... just normal TCP competition.
Pasi Sarolahti: Would like to get an impression if people would be
interested in following up... seeing this happen in the DCCP working
group.
A + Wes: Show of hands for discussing this in the DCCP working group?
(Not much show of hands)
Wes: Asks who is actually in DCCP (not much show of hands either - maybe
one) - so there may be interest, but no personnel present.

=====
Dragana Damjanovic
Explicit Feedback on Access Links
30 minutes (11 mins actual time left) (2:21:00)
=====

(2:25:00) Joseph Ishac: Clarifying - So this is coming from just the next
hop?
Lloyd Wood: Getting information from the link is a difficult issue.  Had
this issue with router/modem integration... modem has to talk to the next
hop router.  You have a similar problem here, host on a home net and a
stub link.  Did you think of the mechanisms to actually communicate or
send the data?  Mulicast?
Tim Shepard: One of your slides said IP option.  Not sure what was meant.
A: One of the methods would be to use a small IP option from the end host
to the router and no further.
LW: Will supply info about this issue, there might be some commonality.
Bryan Ford: Unclear of the purpose... is it fairness?  or is it taking
advantage of optimal bandwidth as soon as possible.
A: Kind of managing of the access link, trying to smartly use your own
bandwidth.
Tim Shepard: as an example - Does this already - uses Linux traffic
control to not saturate the line on his linux box and DSL modem... to not
fill it's queue, make sure receive window doesn't open to large.  Does
this by hand.  Is your approach to come up with some automated solution?
A: Yes... just really wanted to clarify the objective (reducing delay?)
TS: What do you mean by IP option?  IPv4 option?  It doesn't seem like a
good idea.  If a box isn't there that understands, then it's going to be
dropped or forwarded into the network and dropped by some router.  Don't
see a path forward with IPv4 options.
A: Yeah, I don't have a complete solution.  The router might be able to
send to the end host without issue, but not the other way around.
??: If that's the case (direction?), why mess with options at all - just
roll your own solution.
A: Yes that's possible.
(shout out): Source quenching
GF: Quick start caution... assuming that the first link is the bottleneck
is a bit risky... might not be doing the right thing for you.
A: Understood - QS isn't necessarily the option to use, but you could use
a QS to the first router, not the whole path.
GF: That's a big assumption if your going to another node or access
link... recommends QS be done on the whole path... simply doing it on your
access link and assuming that is the bottleneck may be a "little" risky
ML: Should the OS try to queue this or should TCP fix it?  Want to do this
for more than TCP (ie: UDP streams).  How do you communicate this?  Seems
complicated.

(2:31:55) Adjourn

From: [email-masked] (Lars Eggert)
Date: Fri Aug  7 19:06:07 2009
Subject: [Iccrg] *** deadline extended to Aug 13 *** ACM ReArch'09 (co-located with ACM CoNEXT)
Message-ID: <[email-masked]>

ReArch'09 Workshop - Re-Architecting the Internet
Co-located with ACM CoNEXT 2009
Rome, Italy, December 1, 2009
http://conferences.sigcomm.org/co-next/2009/workshops/rearch

*** Extended Submission Deadline: August 13, 2009 ***
Submit at: http://edas.info/newPaper.php?c=7673

The Internet architecture has been remarkably successful in
allowing a planet-scale internetwork to form. However, this
architecture is losing its original simplicity and transparency
as new classes of applications, business models, security
mechanisms, scalability enablers and operational and management
requirements give rise to point solutions that extend the
architecture without regards to its original design principles.

Although these developments are necessary in the short term to
allow the Internet to continue to operate under the present
economical, technical and social conditions, in combination,
they have significantly reduced the potential for longer-term
evolution of the Internet architecture. This loss of
flexibility is already being felt as the number of Internet
nodes grows by another order of magnitude.

Several substantial Future Internet initiatives are underway in
Europe, the Americas and Asia, and the vendor and network
operator communities are also actively discussing the
limitations of the current Internet architecture as well as its
potential evolution. The first solution proposals in this space
have already started to be analyzed.

ReArch'09 - the second instance of this workshop since its very
successful debut at CONeXT 2008 - will discuss the underlying
problems of the Internet architecture and protocols and debate
how we might fix them in a way that regains us the original
architectural simplicity and clarity of the Internet for another
30+ years.

This workshop solicits original, high-quality papers that
analyze and discuss ideas for a new Internet architecture,
including specific improvements to current Internet protocols,
especially at the internetworking, transport and application
layers, new internetworking components that integrate into the
existing architecture and ideas for clean-slate internetworking
architectures.

Topics

ReArch'09 covers all aspects related to the current and future
Internet architecture including, but not limited to, the
following impact:

  * New networking paradigms
  * New business models
  * New routing architectures
  * New traffic engineering and congestion control mechanisms
  * Measurements and analyses that characterize and quantify
    architectural limitations
  * New architecture proposals and their implications for
    research and operations
  * New protocols to address specific architectural limitations
  * Studies of interactions between stakeholders of the Internet
    and the architecture itself
  * Design principles and interfaces to accommodate the
    conflicting interests of stakeholders in the architecture
  * Principles of evolving future architectures
  * Discussions on interworking with the existing Internet and
    deployability

Papers that present interesting, fresh ideas at an early stage
are more suitable for this workshop than highly polished results
or incremental refinements of previous work. Submissions may
include position papers that point out new directions and
attempt to stimulate discussion; position papers should be
clearly marked as such. Submission must be original and not
already be published or submitted for publication elsewhere.
The proceedings of the workshop will be published in the ACM
Digital Library.

Submissions

Submitted papers must be at most six (6) pages long, including
all figures, tables, references, appendices, etc. They must be
formatted according to the standard ACM double column format
*except* that *all* text must use a font size of 10 points or
larger. Longer submissions will not be reviewed. The review
process is single-blind. Submit papers via EDAS at
http://edas.info/newPaper.php?c=7673

  Submission Deadline:      *** August 13, 2009 ***
  Notification Deadline:        September 10, 2009
  Camera Ready Deadline:        October 1, 2009
  ReArch'09:                    December 1, 2009

Committees

Workshop Co-Chairs

  Lars Eggert, Nokia Research Center & TKK, Finland
  Tilman Wolf, University of Massachusetts, USA

Technical Program Committee

  Bengt Ahlgren, SICS, Sweden
  Mark Allman, ICSI, USA
  Bob Briscoe, BT Group, United Kingdom
  Brian Carpenter, University of Auckland, New Zealand
  Jon Crowcroft, University of Cambridge, United Kingdom
  Kevin Fall, Intel Research, USA
  Pierre Francois, UC Louvain, Belgium
  James Griffioen, University of Kentucky, USA
  Robert Hancock, Roke Manor Research, United Kingdom
  Mark Handley, University College London, United Kingdom
  Hiroaki Harai, NICT, Japan
  Daniel Massey, Colorado State University, USA
  Martin May, Thomson Research, France
  Akihiro Nakao, Univeristy of Tokyo, Japan
  Pekka Nikander, Ericsson Research Nomadiclab, Finland
  Craig Partridge, BBN Technologies, USA
  George Rouskas, North Carolina State University, USA
  Peter Steenkiste, Carnegie Mellon University, USA
  Christian Vogt, Ericsson Research, USA
  Klaus Wehrle, RWTH Aachen, Germany
  Rolf Winter, NEC Network Labs, Germany
  Martina Zitterbart, University of Karlsruhe, Germany

Steering Committee

  Marcelo Bagnulo, University Carlos III of Madrid, Spain
  Olivier Bonaventure, UC Louvain, Belgium
  Kenjiro Cho, IIJ, Japan
  Joe Touch, USC/ISI, USA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090807/cb26835d/smime.bin
>From [email-masked]  Fri Aug 14 19:40:05 2009
From: [email-masked] (Aaron Falk)
Date: Fri Aug 14 19:30:48 2009
Subject: [Iccrg] [Fwd: Copyrights and the IRTF and Independent Stream]
Message-ID: <[email-masked]>

Forwarding to all active IRTF RG mail lists because this issue affects
the publication rights for IDs and RFCs developed within the IRTF. 
Information about IRTF RFCs can be found in
http://tools.ietf.org/html/draft-irtf-rfcs-03.  Please direct comments
to the RFC-interest list (coordinates below).

--aaron
  IRTF Chair

-------- Original Message --------
Subject: 	[rfc-i] Copyrights and the IRTF and Independent Stream
Date: 	Thu, 13 Aug 2009 18:59:42 +0200
From: 	Olaf Kolkman <[email-masked]>
To: 	RFC Interest <[email-masked]>

Dear Colleagues,

This mail is about rights in RFCs and Internet drafts. The topic draws
context, and uses terminology from:
RFC 4844: The RFC Series and RFC Editor
RFC 4846: Independent Submissions to the RFC Editor
RFC 5378: Rights Contributors Provide to the IETF Trust
RFC 5377: Advice to the Trustees of the IETF Trust on Rights to Be
Granted in IETF Documents

First some administrational notes.

This mail serves as setting a baseline for a public discussion and is
based on a few (virtual and real-life) hallway discussions. The goal
of this discussion is to make sure all issues are brought to the table
and the stream maintainers and the Trust are aware of the communities
opinions. I see my role as an IAB member that is driving the
discussion, and mildly moderating it. In the end it is the role of the
IAB to see that an appropriate stream dependent process has been
followed and that the streams do not interact inapropriatly. So in
that sense this discussion informs the IAB too.

Although this mail is sent to multiple lists I would like to urge folk
to discuss the issues on the rfc-interest list:
   http://www.rfc-editor.org/mailman/listinfo/rfc-interest

Without further ado.

As you may know RFCs are published from different streams. With
respect to the incoming and outgoing rights only the rights of the
IETF stream documents are well defined. And currently the IAB has
chosen to have IAB documents fall under this regime too. The situation
is less clear for Independent and IRTF Stream documents: all existing
provisions are targeted specifically towards IETF Contributions (in
the narrow context defined by RFC5378). Besides, currently and in the
context of copyrights, Internet Drafts (I-Ds) are seen as IETF
contributions.

Maintainers of the Independent and IRTF stream would like to have
documents from their streams published with full rights to make
derivative works or make no derivative works whatsoever, and require
attribution in both cases.

There are two strategies to make this work:

1. Allow I-Ds and RFCs for the IAB, IRTF, and Independent stream to be
published with a Creative Commons license added.

A rough outline of one of the ideas that is floating around ist that
all contributions that are intended to become an RFC or are an IETF
contribution (in the sense of RFC 5378 definition) will continue to
have the 5378 license terms as defined by the trust. Since 5378 is
non-exclusive authors may add a creative commons license if they'd
like to. Care should be taken that those licenses would not be applied
to IETF contributions, as that could lead to 'spoofed standard-track
RFCs'

2. Have the trust manage the rights for the IAB, IRTF, and Independent
streams RFCs and I-Ds.

Both strategies may require that at the moment Internet Drafts is
published as an RFC it is clear on which stream they are intended to
be published, with which rights, and that the authors have appropriate
authority to grant/sublicense those rights.

In both cases we want to avoid that IETF contributions (I-Ds and
RFCs, although it is not clear whether this is a strong requirement
for I-Ds) are published with a license policy that would circumvent the
Trust's control over the outgoing rights.

A tactic/straw-man to implement (2) is as follows:

    i) Treat all I-Ds as or similar to IETF contributions (this way
       there is no doubt about the Trust having all necessary rights,
       see BCP78 section 5.3). There seem to be two paths to proceed:

        i.1) The stream controllers choose to apply the RFC5378 rules.
        	    This possibility is offered in section 4 of 5378 and the
  	    IAB stream chooses to apply the rules through its
	    declaration in section 11.

        i.2) The streams write a stream specific "Rights contributors
             provide to the IETF trust" document.

     ii) Have the stream controllers request  the IETF Trust to create
         license(s) for non IETF-Stream RFCs that grant for (full|no)
	derivative rights, attribution required. (document this
	request in an RFC).

    iii) Ask the trust to develop language that can be put on an I-D
         with which the author can request (full|no) derivative rights
         if/when the I-D is published on a specific non-IETF stream
	document. This sort of text would serve as an indication of
	consent with wide licensing and could be included as
	boilerplate material together with an indication of intended
	stream (as in draft-iab-streams-headers- boileplates).

There are some pros and cons to this scheme that we need to identify
in public discussion, hence this mail.

During the hallway discussion, I've seen the following arguments and
identified the following open questions. I don't claim completeness.

- The Trust is not well equiped to hold non-IETF documents. Mainly
   because it requires the interperetation that all documents are IETF
   Documents.

   Is this interpretation based on language in the Trust agreement or
   on the definition of IETF Documents in the context of BCP78?

   Or, is the trust well suited, and does implementation only need some
   boilerplate changes?

- IETF Stream RFCs need to be protected by limited derivative rights
   so that the IETF keeps ownership over its Standards and can maintain
   those.

   Suppose a I-D with full derivative rights is posted (either because
   the author has published it with Creative Commons, or because the
   Trust allows full derivative rights for stream specific I-Ds) would
   narrowing down the rights by publication as an IETF stream RFC cause
   any problems?

Feedback welcome,

--Olaf Kolkman

From: [email-masked] (Mikael Abrahamsson)
Date: Tue Aug  4 19:03:51 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <20090731124802.GB9935@verdi> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, 4 Aug 2009, Bob Briscoe wrote:

> Incidentally, there's no reason for ECN not to be on by default in TCP 
> servers in Linux. TCP servers in in Win Vista have ECN on by default.

I believe (as per discussion I had with them 6-12 months ago) Linux kernel 
developers are leaning towards enabling ECN by default, but then you need 
to distros to actually keep this setting into their packaged kernels.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Bob Briscoe)
Date: Tue Aug  4 18:34:08 2009
Subject: Fwd: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090804/c08c90bc/attachment.html
>From [email-masked]  Tue Aug  4 19:02:02 2009
From: [email-masked] (ken carlberg)
Date: Tue Aug  4 18:54:21 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Actually, we did this with ping -z (depending on your flavor of OS, to  
set the ToS byte) , so ICMP packets with echo-request/echo-response.

and ouch, hadn't thought about the reverse direction, as such.  I  
ping'ed the path of the hops individually of one the leaf providers  
where we saw the zero'ed ECN field, and each hop of the "offending"  
provider responded with a correctly reflected value.  That is what led  
me to believe that perhaps the headache lies in the cable modem.

but again, i need to reiterate that the testing is no where near  
exhaustive, nor are all the variables accounted for.  we'll do some  
more tests down the line and see what we come up with.

-ken

On Aug 4, 2009, at 1:41 PM, Bob Briscoe wrote:

> Ken,
>
> [iccrg folks, please read down the thread to see Ken's addition to  
> this thread, which is pending in the iccrg moderator's queue.]
>
> Were your tests using UDP packets, or TCP?
> And did any results differ depending on the direction between the  
> same two endpoints?
>
>
> Bob
>
> At 17:43 04/08/2009, ken carlberg wrote:
>
>
>> Begin forwarded message:
>>
>>> From: ken carlberg <[email-masked] >
>>> Date: August 3, 2009 9:34:53 PM EDT
>>> To: [email-masked]
>>> Cc: Colin Perkins <[email-masked]>, Ingemar Johansson S < [email-masked] 
>>> >, Magnus Westerlund < [email-masked]>, Piers  
>>> O'Hanlon <[email-masked] >
>>> Subject: Re: [Iccrg] Is ECN too complicated?
>>>
>>> Hi,
>>>
>>> Bob Briscoe forwarded me the following message, so I'll try and  
>>> give a reasonable response (while suffering from some jet lag)...
>>>
>>> Piers O'hanlon from UCL and I have done some tests from a handful  
>>> of sites from the UK and Washington DC to UCL.  It was clearly not  
>>> an extensive sampling, but we did find cases where the ToS byte  
>>> (and more specifically, the ECN field) was zero'ed out as opposed  
>>> to having the packet be dropped.  I think Piers came across two  
>>> out of three tests (from different source locations, and thus  
>>> different leaf providers) zero'ed out the field.
>>>
>>> In my case, tests from the customer sites of one of two cable  
>>> providers to UCL failed.  I have a couple of summer interns doing  
>>> some more tests for me from other local providers in the DC area,  
>>> but I need to meet up with them later this week to go over the  
>>> results and make sure they did things correctly.  However, I  
>>> suspect that the problem in at least one instance may lie with the  
>>> cable modem.  I still need to perform the test with a different  
>>> home router, so tests are on-going to eliminate anomalies and  
>>> outlyers.
>>>
>>> -ken
>>>
>>> ps, I'd also subscribe to the theory that backbone providers can't  
>>> be bothered with zero'ing out the ECN field.
>>>
>>>
>>>>> Date: Mon, 03 Aug 2009 18:28:00 +0100
>>>>> To: Mikael Abrahamsson <[email-masked]>
>>>>> From: Bob Briscoe <[email-masked] >
>>>>> Subject: Re: [Iccrg] Is ECN too complicated?
>>>>> Cc: John Leslie <[email-masked]>, iccrg IRTF list <[email-masked] 
>>>>> >
>>>>> Bcc: ?\LTR\Tech\IN ICCRG
>>>>>
>>>>> Mike,
>>>>>
>>>>> The guys proposing ECN in RTP say their limited tests have found  
>>>>> that ECN-capable packets get cleared to 00 on some paths.
>>>>>
>>>>> This may be a case of firewalls with the rule "deny all, unless  
>>>>> known to be safe," rather than "allow all, unless known to be  
>>>>> unsafe". I think they used UDP packets and ECN on TCP is known  
>>>>> to be safe, whereas ECN on UDP is not known to be unsafe.
>>>>>
>>>>> Perhaps they should take advice from Bob Dylan, who said  
>>>>> (paraphrasing) "Don't drop packets, that you don't understand;  
>>>>> For the times they are a-changing."
>>>>>
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>> At 14:10 31/07/2009, Mikael Abrahamsson wrote:
>>>>>> On Fri, 31 Jul 2009, John Leslie wrote:
>>>>>>
>>>>>>> We do need them to leave ECN marking alone. (Has someone  
>>>>>>> documented
>>>>>>> which core router do and don't?)
>>>>>>
>>>>>> I don't know of any core router that will zero the ECN marking,  
>>>>>> all I have seen either have ECN support (used in their WRED  
>>>>>> schemes) or they don't know anything about ECN and just ignores  
>>>>>> the bits and just passes the packet unchanged (ECN-wise).
>>>>>>
>>>>>>> I don't feel the need for more detail of why intelligence in  
>>>>>>> core routers is expensive. What we do need is an upper bound  
>>>>>>> on packet drop (without ECN marking coming first) in actual  
>>>>>>> core routers.
>>>>>>
>>>>>> From what I have seen in recent major vendors, the new  
>>>>>> platforms seem to have around 50-200ms of buffers, coming down  
>>>>>> from the common 600ms 5+ years back.
>>>>>>
>>>>>> This is for 10G and 40G interfaces.
>>>>>>
>>>>>> --
>>>>>> Mikael Abrahamsson    email: [email-masked]
>>>>>>
>>>>>> _______________________________________________
>>>>>> Iccrg mailing list
>>>>>> [email-masked]
>>>>>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>>>>
>>>>> ________________________________________________________________
>>>>> Bob Briscoe,               Networks Research Centre, BT Research
>>>>
>>>> ________________________________________________________________
>>>> Bob Briscoe,               Networks Research Centre, BT Research
> ________________________________________________________________
> Bob Briscoe,               Networks Research Centre, BT Research
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20090804/f7a0105c/attachment.html
>From [email-masked]  Tue Aug  4 21:00:00 2009
From: [email-masked] (Bob Briscoe)
Date: Tue Aug  4 18:57:10 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <20090731124802.GB9935@verdi>
References: <[email-masked]>
	<20090731124802.GB9935@verdi>
Message-ID: <[email-masked]>

John,

Very simply, the ECN I'd like to see on any and every queue is just 
RFC3168. That defines the encoding of the congestion signals without 
being religious about the AQM algo. It recommended RED, but other 
better AQM algos are not precluded.

I'd say that advice should still apply. Is there any variant of RED 
that's worse than tail drop? I think not (unless it's configured 
completely stupidly). So virtually any RED is better than nothing.

If a vendor was going to implement an AQM in hardware right now, they 
might want to take advice from those who are working in this area 
right now (to avoid committing just before simpler or better ideas 
get published). But otherwise there's nothing to stop ECN being 
implemented, then as new ideas come out, they can be implemented on 
newer models. RFC3168 is sufficient for interworking.

inline responses...

At 13:48 31/07/2009, John Leslie wrote:
>Bob Briscoe <[email-masked]> wrote:
> >
> > I wanted to carry this question over to the list. It is central to
> > challenge #1 in our open issues. What level of router support for cc
> > is appropriate?
>
>    Some explicit congestion notification is decidedly needed. I would
>hope that in the vast majority of cases this would be marking a
>packet rather than dropping it.
>
>    I believe Bob has in mind a specific usage of ECN (RFC 3168) here.
>(It would be good to include a pointer to exactly how he means to
>use it.)
>
>    ECN need not be deployed at _every_ router in the Internet cloud,
>so long as the markings are preserved (and packet drop at non-ECN
>routers is sufficiently rare). But there will be a need to apply
>back-pressure somehow, preferably by dropping packets that come from
>sources that don't manage the congestion.

I see no reason for vendors not to put ECN on even the fastest 
routers & switches. And I don't see why it shouldn't be on by 
default. Operators can turn it off if they want, but if it were 
implemented in hardware, I doubt that would give any noticable 
performance improvement.

However, if it's not been implemented, operators can't turn it off or on.

> > My premise is that ECN is the most minimal mechanism we can imagine
> > on each queue, to get info out of those boxes to the edge of the
> > network, where capacity sharing can be controlled - rather than
> > trying to do capacity sharing on every resource (which I have shown
> > is not even the right thing to be wanting to do).
>
>    I would agree.
>
> > So I was a bit surprised to hear ECN criticised as too complex. It's
> > a tiny no. of cycles per packet. If ECN is too complex, whither RCP?
>
>    It's the _perceived_ complexity that's the problem. Many of us just
>don't understand what Bob is currently proposing; and it's a bit
>cloudy which RFCs actually apply when he says "ECN".

Just RFC3168 - the vendor can choose their favourite AQM algo.

> > BTW, I've recently proved that the parts of the ECN algo that make
> > marking follow a uniform distribution can be removed (redundant).
>
>    Yet another example of what we don't know...

Again, see above - it doesn't matter if the algo is being improved 
all the time; the state of the art is good enough.

I've written up this proof (as an aside in my PhD thesis), which I'll 
make available shortly as the thesis is now all done and dusted. It's 
fairly obvious once you think about it that uniformly distributing 
marks across an aggregate won't uniformly distribute them in each 
flow - they will still be geometrically distributed in each flow, so 
you might as well not bother with this part of the code, which 
includes some complicated arithmetic, division etc.

I've just checked the altq RED code (the FreeBSD variant). Kenjiro 
Cho did quite a good job of optimising this code, so I checked 
because he might have noticed this part was redundant and removed it. 
However his code still includes the uniform distribution stuff. 
Whether it's also in commercial vendor code, I don't know.

>
> > Also, recent work by Damon Wischik iwhere there's hi stat mux (the
> > boxes we're worried about) you don't even need the RED ramp, just a
> > step at a small number of packets.
>
>    Yet another...

Again, algo streamlining will help, but the state of the art is good enough.

> > If ECN is still too complex, I'm at a loss (irony intended).
>
>    In order for this to work in the wild, we need quite a few routers
>near the core to perform the flavor of ECN that Bob wants. We just
>don't yet understand how much of a hurdle this might be (but we're
>pretty sure the hurdle is insurmountable until it's better defined).
>
>    It's not a question of how complex the code might be: it's a
>question of how difficult it will be to get enough deployment.

I agree. That's why I questioned Mikael. It's surely not complexity, 
but lack of operator pull.

Perhaps this is a symptom of vendors telling operators what their 
requirements should be, and in this case, they don't recommend it 
because it's too simple to charge extra for. Especially as it would 
remove the need for a lot of the other complexity the vendors try to sell.

Incidentally, there's no reason for ECN not to be on by default in 
TCP servers in Linux. TCP servers in in Win Vista have ECN on by default.

Bob

>--
>John Leslie <[email-masked]>

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

From: [email-masked] (Bob Briscoe)
Date: Mon Aug  3 18:23:36 2009
Subject: [Iccrg] incentives for 1/p: I muddled my answer in Stockholm
Message-ID: <[email-masked]>

Folks,

In Stockholm, I said that 1/p congestion controls like Relentless 
ensure that, relative to TCP, there are more congestion signals per 
RTT as flows get faster. This emergent property ensures 
responsiveness scales with speed.

Someone (sorry I didn't see who, as the lights were shining in my 
eyes) asked whether this implied re-ECN and responsiveness 
requirements were pulling in opposite directions; re-ECN gives 
transports the incentive to create less congestion but transports 
require more congestion signals to remain responsive. I'm sorry, I 
gave an answer that was unclear and inconclusive, whereas I could 
have been clear and conclusive...

To be clear, a move to 1/p congestion controls is unaffected by 
incentives to reduce congestion. Why? Because transports have another 
degree of freedom for reducing congestion: the 'weight'. Having 
chosen a weight, using a 1/p control ensures the weight chosen for a 
particular type of session remains correct as capacity scales over 
time and on different paths.

Let's assume the transport converges on an average window W:
         W = w/(p^b)
where
         w: weight (note lower case)
         p: loss fraction (or ECN marking)
         b: responsiveness parameter
b_TCP = 1/2
b_Rel = 1   (Rel: Relentless)

If the transport can set w and b, the transport has more degrees of 
freedom than it needs to alter the number of congestion signals per RTT.

Imagine we start at a time in history where use of TCP leads to just 
enough congestion signals to control most flows passing through most 
bottlenecks (e.g. one signal every few RTTs). The question: what to 
do wherever and whenever faster links are available:

Scenario #1: Stay with TCP (b=1/2):
Over faster links, people will need to increase their w so that TCP 
gets more frequent signals, and can accelerate fast enough to use the 
available capacity while staying controllable (Note: increasing w 
could be hacked at the application layer with multiple TCP flows over 
the same path and a congestion manager).

Scenario #2: Move from TCP to Relentless (b=1):
The first time Relentless is used, it can be set with a low w, but no 
lower than the point where there aren't frequent enough signals for 
responsive control. Then whenever higher or lower speed links are 
encountered, for ever into the distant future, the same w can be used 
for the same type of session.

Summary
-------
Moving from TCP (b=1/2) to Relentless (b=1) doesn't imply more 
congestion than _necessary_ to keep responsiveness, because w can be 
reduced as low as desired.
But once you set b=1 (e.g. Relentless) and you set w as low as 
feasible for a certain type of session, you don't have to configure 
anything ever again. Whereas, if you keep with TCP, you continually 
have to fiddle with the weights to keep it working as links get faster.

Bob

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research  

From: [email-masked] (Bob Briscoe)
Date: Mon Aug  3 18:21:00 2009
Subject: [Iccrg] Is ECN too complicated?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <20090731125707.GC9935@verdi> <[email-masked]>
Message-ID: <[email-masked]>

Mike,

The guys proposing ECN in RTP say their limited tests have found that 
ECN-capable packets get cleared to 00 on some paths.

This may be a case of firewalls with the rule "deny all, unless known 
to be safe," rather than "allow all, unless known to be unsafe". I 
think they used UDP packets and ECN on TCP is known to be safe, 
whereas ECN on UDP is not known to be unsafe.

Perhaps they should take advice from Bob Dylan, who said 
(paraphrasing) "Don't drop packets, that you don't understand; For 
the times they are a-changing."

Bob

At 14:10 31/07/2009, Mikael Abrahamsson wrote:
>On Fri, 31 Jul 2009, John Leslie wrote:
>
>>We do need them to leave ECN marking alone. (Has someone documented
>>which core router do and don't?)
>
>I don't know of any core router that will zero the ECN marking, all 
>I have seen either have ECN support (used in their WRED schemes) or 
>they don't know anything about ECN and just ignores the bits and 
>just passes the packet unchanged (ECN-wise).
>
>>   I don't feel the need for more detail of why intelligence in 
>> core routers is expensive. What we do need is an upper bound on 
>> packet drop (without ECN marking coming first) in actual core routers.
>
> From what I have seen in recent major vendors, the new platforms 
> seem to have around 50-200ms of buffers, coming down from the 
> common 600ms 5+ years back.
>
>This is for 10G and 40G interfaces.
>
>--
>Mikael Abrahamsson    email: [email-masked]
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research 

From: [email-masked] (Xiaoming Fu)
Date: Sun Aug  2 16:38:58 2009
Subject: [Iccrg] Call for Submissions: ICNP 2009 PhD Forum
Message-ID: <[email-masked]>

Our apologies for cross-posting...
----
Dear colleagues,

Please kindly note that the ICNP'09 call for submissions to PhD forum as 
well as posters and demos are all due on August 7, 2009.

Best regards,
Xiaoming Fu (ICNP'09 Publicity Chair)

IEEE ICNP 2009 PhD Forum
========================
http://edas.info/W.php?page=113

The ICNP'09 PhD Forum provides an environment for doctoral students to 
present and discuss their dissertation research both with their peers 
and experienced researchers from academia and industry. In addition to 
providing feedback and advice, this forum shall provide an opportunity 
for students to network as well as to practice presenting their research 
clearly and concisely.

This forum is best suited to senior Ph.D. students who have developed a 
mature research dissertation topic and framework and are far enough into 
their PhD to have a concrete presentation outlining the key challenges 
they plan to solve as well as the strategies and methods that are 
applicable.

This forum is broadly for students graduating in the next several months 
to about a year. Certainly feedback will help them fine-tune their 
thesis. Graduate students also get a chance to get feedback that they 
can use to write their papers, and address additional items in their 
research.

Format
======
Each participant will have 15 minutes allotted for a presentation. We 
will limit the number of participants to no more than 5 presenters.

Submission
==========
    1. A summary of the student's dissertation research (up to 3 pages) 
including a brief discussion of motivation, challenges, related work and 
initial results. Applicants should clearly identify their contributions 
to the field of networking protocols design and analysis.
    2. A short biographical sketch (1 page max) describing the 
applicants affiliations and research activities. This should include the 
date that the student expects to complete his/her dissertation.

Please use the IEEE conference proceedings style (2-column) when 
preparing your abstract. If accepted, a student may be asked to provide 
explanations or clarification by the camera-ready deadline.

Important dates
===============
Submission deadline             August 7, 2009, (Fri 23:59 PDT)
Notification of decisions     August 28, 2009
Final version of abstracts     September 4, 2009

Where to submit?
================
By email to: [email-masked]
Use Subject Line: ICNP 2009 PhD forum submission

Registration
============
Students may register for the conference at the student rate for 
participation in PhD forum (if they are not presenting a full paper in 
the conference which requires a full registration).