
From: service@paypal.com (service@paypal.com)
Date: Sat Jul 15 08:33:08 2006
Subject: [Iccrg] Restore your account access
Message-ID: <200607150526.k6F5QHtV001127@teto.atlogic.net>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060715/4b3a1c8e/attachment.html
>From mascolo@poliba.it  Tue Jul 18 12:46:01 2006
From: mascolo@poliba.it (Saverio Mascolo)
Date: Tue Jul 18 14:09:52 2006
Subject: [Iccrg] TCP Westwood+ linux 2.16.18 kernel implementation
Message-ID: <001a01c6aa5f$c3d2b960$723bccc1@HPSM>

We have updated the TCP Westwood+ linux kernel implementation with the
two following changes:

o RTT_min is updated each time a timeout event occurs (in order to
 cope with hard handovers in wireless scenarios)

o The bandwidth estimate filter is now initialized with the first
bandwidth sample in order to have better performances in the case of
small file transfers.

The patch has been applied to the mainstream kernel and it will be
available for kernels >= 2.6.18.

The patch is available at:

   http://c3lab.poliba.it/index.php/Westwood:Experimental

where you can also find a patch to Web100 (http://www.web100.org) in
order to enable the logging of the "end to end bandwidth estimate" variable used by westwood+.

I remember for sake of  completeness that the only diffrence between westwood and westwood+ is the "bandwidth estimate" algorithm that in westwood+ provides a measure of used bandwdith that is not aliased.


best,
saverio mascolo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060718/33cf5cb2/attachment.html

From: falk@ISI.EDU (Aaron Falk)
Date: Mon Jul 10 15:27:01 2006
Subject: [Iccrg] Fwd: Possible Internet2 awards program for new TCP stacks
References: <6.2.0.14.2.20060706140924.03dfc1a0@mail.internet2.edu>
Message-ID: <88676A75-868F-425B-AD3F-832093BC4A59@ISI.EDU>

Of possible interest.  --aaron

Begin forwarded message:

> From: Richard Carlson <rcarlson@internet2.edu>
> Date: July 6, 2006 2:44:48 PM EDT (CA)
> To: Joe Touch <touch@ISI.EDU>, Pascale Primet <pascale.primet@ens- 
> lyon.fr>, Katsushi Kobayashi <ikob@koganei.wide.ad.jp>, Aaron Falk  
> <falk@ISI.EDU>, "Douglas Leith" <doug@eee.strath.ac.uk>, "R. Hughes- 
> Jones" <R.Hughes-Jones@manchester.ac.uk>, "Cottrell, Les"  
> <cottrell@slac.stanford.edu>, Brian Tierney <bltierney@lbl.gov>
> Cc: Injong Rhee <rhee@eos.ncsu.edu>, Sally Floyd <floyd@icir.org>,  
> Jason Leigh <drspiff@mac.com>, Richard Carlson  
> <rcarlson@internet2.edu>
> Subject: Possible Internet2 awards program for new TCP stacks
>
> All;
>
> Hopefully you all know about the Internet2 Land Speed Record (LSR)  
> awards program http://lsr.internet2.edu/  Briefly, the LSR awards  
> program was established in 2000 to promote demonstrations that  
> highlight TCP's potential.  As the rules state, each entry must be  
> a RFC-791/793 stack with 1 or more sockets sending data between 2  
> Internet nodes.
>
> The original record was 751 Mbps over 5600 Kmeters.  The latest  
> record is 8.8 Gpbs over 30,000 Kmeters (the web page is out of  
> date).  Given that the current record crossed some 10 GE WAN-PHY  
> links and the rules call for a 10% increase to set a new record, we  
> may have to wait a while before the next generation 40/100 Gig HW  
> comes out.
>
> While these experiments show that TCP is capable of running at line  
> rates over any distance, we all know that performance can drop  
> dramatically if losses occur.  In fact, if you look at the MRTG  
> graphs the wining teams supply you can see they make multiple runs  
> and discard tests that suffer from any type of packet loss.
>
> Internet2 is looking for some way to promote testing, evaluation,  
> and growth in the field of TCP stack research.  One idea is to  
> create a new awards program, along the lines of the existing LSR  
> program.   I'm looking for advice and guidance on:
>
> 1) is this a good idea?
>
> 2) if so, what rules need to be changes/modified?
>         a) should some type of loss metric be included?
>         b) verification mechanisms?
>         c) is distance an important metric?
>         d) ensure others duplicate/repeat the experiment
>
> 3) if not, is there a better way to promote TCP stack research?
>
> Thanks in advance.  Any thought, comments, or suggestions would be  
> greatly appreciated.  Feel free to share this email with your  
> colleagues and collaborators.
>
> Regards;
> Rich
>
>
>
>
> ------------------------------------
>
>
>
> Richard A. Carlson                              e-mail:  
> RCarlson@internet2.edu
> Network Engineer                                phone:  (734) 352-7043
> Internet2                                       fax:    (734) 913-4255
> 1000 Oakbrook Dr; Suite 300
> Ann Arbor,  MI  48104



From: michael.welzl@uibk.ac.at (Michael Welzl)
Date: Fri Jul  7 09:09:05 2006
Subject: [Iccrg] Explaining my silence
Message-ID: <1152254056.4770.33.camel@lap10-c703.uibk.ac.at>

Folks,

As you can tell, the list is (again) fairly silent. This is
not how I intend to run it - when I was given my role here,
the first thing I thought is that I'll try hard to stir up
some discussions, contribute to drafts, get people to do so
too, an generally make things move!

Then reality knocked on my door  :(    all of a sudden, I'
have a day-job deliverable that will keep me busy for the
next couple of weeks.

I expect to be active again around mid-August.

Sorry for that!

Cheers,
Michael


