[Iccrg] benchmarking new tcp congestion control algorithms

[Wesley Eddy]

On Sun, Feb 11, 2007 at 12:28:36PM +0000, Douglas Leith wrote:
> 
> Just posted this to the end2end list, but in view of the discussions  
> at pfldnet last week and the agenda for the iccrg meeting tomorrow,  
> it might be topical for iccrg.
> 
> I've put together a set of short ns scripts to carry out the tcp  
> benchmark tests described in
> 
> Experimental evaluation of high-speed congestion control protocols,  
> Li, Y.T, Leith,D., Shorten,R. Transactions on Networking, 2007 (see  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf).
> 
> The ns scripts are at http://www.hamilton.ie/net/eval/tcptesting.zip.
> 
> Its now very easy to rerun these tests against proposed new  
> congestion control algorithms.  Baseline tests for standard tcp, high- 
> speed tcp, scalable tcp, bic tcp, fast tcp and htcp are reported in  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf and these experimental  
> measurements can be directly compared against the simulation results  
> generated by the script.
> 
> Let me know if you have any comments.
> 


I think these kinds of contributions are very helpful for the community.
I wonder if based on this, it would be possible to propose a "minimal"
set of test scenarios and objectives that we could use as a sort of
first stage of screening for new congestion control schemes.  If we
could come up with some rough consensus on what battery of test results
demonstrates that a given scheme is safe, then we could do to things:

1) leverage the set of tests as a fair and level way to achieve
   consensus that particular congestion control schemes that are
   proposed in the ICCRG are safe to be published as Experimental.

2) use the test output to refine proposed congestion control schemes,
   tweak parameters, and understand the differences between schemes

All around I think a standard battery of tests and some goals for the
tests based on the tmrg-metrics work would be fantastically useful.
Does anyone else agree or have cycles to work on this kind of
infrastructure for the group?

-- 
Wesley M. Eddy
Verizon Federal Network Systems