Subject: [Iccrg] "Classic congestion collapse": be on the lookout for....
From: [email-masked] (Jim Gettys)
Date: Wed Oct 19 18:14:25 2011

I have one credible report of a significant private network collapsing
with symptoms of "classic" 1980's flavour congestion collapse, along
with significant difficulty getting the network "up" again after collapse.

Please let me know if you know of other examples you can share.

Two trends are worrying:
    1) the retirement of Windows XP is making it much easier to saturate
networks in the first place.
    2) bufferbloat may also be playing a role, as it can destroy TCP
congestion avoidance. But we don't know, and can't get the data to know
right now either.  Buffers can hide in places we don't have AQM to
control the problem. And this problem has been growing...

Unfortunately, more information is probably unavailable about the
events, causes, and cures for the time being.  It's really hard to be
"first" with such a report publicly; much easier if you know you have
company.

For extra bonus points (not related to the above report), look for time
based congestion problems; we could end up hurting if there is self
synchronising behaviour going on.

I don't think I need to tell this audience about the RED manifesto, but
you might need to remind your friends.

But I'm worried, given the report,
                Jim Gettys
                Bell Labs

From: [email-masked] (David Hayes)
Date: Wed Oct 12 01:10:42 2011
Subject: [Iccrg] TCP test suite
Message-ID: <[email-masked]>

Hi Group,

This email is to announce that a preliminary version of the test suite is
now available at:

    http://caia.swin.edu.au/ngen/tcptestsuite/tools.html

Currently this is a tar ball of the test suite only. To use it you will need to
download the latest version of Tmix (this should be included in the final
release of ns 2.35, which hasn't been released yet). The README file gives more
information.

As part of our tests we are evaluating the test suite with New Reno, Cubic,
Compound, and Ledbat, and looking at the effect of having an initial window size
of 10. We plan to put together a paper describing the test suite implementation
along with any interesting findings we come across during our tests.

After we have finished our testing, we will release the test suite with the
results for NewReno and other tests, so that researchers only need to simulate
for their particular enhancement.

Which NewReno should be the standard test?

  In our current implementation the standard NewReno Sack test uses the ns2
  NewReno code. An alternative is to use the tcp_linux ns2 code. Our thoughts
  were that the standard test to which all others are compared shouldn't be
  Linux specific (or any other OS for that matter). What do you think?

Regards,

David

-- 
David Hayes
Research Associate
Centre for Advanced Internet Architectures
Faculty of Information and Communication Technologies
Swinburne University of Technology, Australia
http://caia.swin.edu.au/cv/dahayes/
Alternate Email: [email-masked]

From: [email-masked] (David)
Date: Thu Oct  6 04:52:08 2011
Subject: [Iccrg] TCP test suite
Message-ID: <[email-masked]>

Dear Group,

Quoting from the current draft:

"The goal of the test suite is to allow researchers to quickly and easily
evaluate their proposed TCP extensions in simulators and testbeds using a common
set of well- defined, standard test cases, in order to compare and contrast
proposals against standard TCP as well as other proposed modifications.  This
test suite is not intended to result in an exhaustive evaluation of a proposed
TCP modification or new congestion control mechanism.  Instead, the focus is on
quickly and easily generating an initial evaluation report that allows the
networking community to understand and discuss the behavioral aspects of a new
proposal, in order to guide further experimentation that will be needed to fully
investigate the specific aspects of a new proposal."

The current version of the draft can be found at
http://tools.ietf.org/html/draft-irtf-tmrg-tests-02. A revised version is
expected to be out soon.

So far, the following tests have been implemented in the ns2 version of the TCP
evaluation suite:

1. Basic dumbbell scenarios:
   - dial-up
   - access-link
   - data-center
   - trans-oceanic link
   - geostationary satellite
   - wireless

2. Delay/throughput trade-off as a function of queue size
   (This is really the basic access-link test for different queue sizes and AQM)

3. Ramp up time

4. Impact on standard TCP traffic

5. Multiple bottlenecks

Tests not yet implemented are:

1. Transients: release of bandwidth, arrival of many flows

2. Intra-protocol and inter-RTT fairness

I plan to release the implemented tests in the next few days for people to
evaluate. However, there are a couple of general points that can be highlighted
now:

A. The tests use Tmix to generate the test traffic (in most cases) and the
   background traffic. The tmix traffic traces are not stationary (traces will
   be released with the tests).
    - Comparing protocols within a particular test, say the basic dumbbell
    access-link test, works quite well.
    - However comparing access-link test results to data-center results is less
    straightforward, as the data-center test uses more of the traffic traces
    than the access-link test. This extra trace data being statistically
    different to the earlier data in the traces.

Is this a problem (or a feature)?

Special tmix traces could be concocted so that there is less statistical
variability in the traffic for each basic dumbbell test. However, a data-center
scenario with 1Gbps links goes through much more trace data than a dial-up
link scenario with a 56kbps bottleneck link. Would the resulting trace be
"realistic" enough?

B. Resource consumption.

   First a note that work in conjunction with the Tmix developers has greatly
   reduced this from what it was. I expect that the work on Tmix will be
   released in the final version of ns-2.35.

   Simulations were run on an i7 930, 12GB ram, 12GB swap running FreeBSD 8.2
   
   Rough resource usage for the New Reno mild congestion dumbbell tests:

   - access-link <4GB memory, 1hr simulation time
   - data-center ~6GB, 2.3 hrs
   - trans-oceanic >12GB, 4 hrs (although >12GB, it is not slowed much by swapping)

Is it reasonable to expect draft authors submitting new TCP proposals to have
access to machines with at least these resources?

Versions of the ns2 version of the test suite and documentation will be released
over the next week or so on http://caia.swin.edu.au/ngen/tcptestsuite/tools.html

I'll notify the group as it is released.

Regards,

David

-- 
+-------------------------------+
| David A. Hayes		|
| [email-masked]		|
+-------------------------------+

From: [email-masked] (Adhari, Hakim)
Date: Sat Oct  1 09:51:08 2011
Subject: [Iccrg] Deadline Extension: PAMS 2012 -- 2nd International Workshop on Protocols and Applications with Multi-Homing Support
Message-ID: <[email-masked]>

(Our apologies if you receive multiple copies of this CfP)

=================

Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to PAMS 2012.

The submission deadline has been extended to October 16, 2011.

=================

 

============== CALL FOR PAPERS ===============

2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2012) In conjunction with the 26th IEEE International Conference on Advanced Information Networkingand Applications (AINA 2012) Fukuoka, Japan, March 26-29, 2012 http://tdrwww.iem.uni-due.de/pams2012.html

The intent of our workshop is to bring together people from research and industry, in order to provide a discussion forum for state-of-the-art topics related to multi-homing on Network, Transport, Session and Application Layers.
The PAMS workshop will include full-paper sessions as well as a poster session (with short presentations) to introduce preliminary ideas as well as work in progress.

Workshops proceedings will be published by the IEEE CS Conference Publishing Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimization for Multi-Homed Systems
    * Multi-Homing in the Context of Future Internet

GENERAL CHAIRS:

    * Thomas Dreibholz, University of Duisburg-Essen, Germany
    * Martin Becke, University of Duisburg-Essen, Germany

PROGRAM CHAIRS:

    * Michael T?xen, M?nster University of Applied Sciences, Germany
    * Erwin P. Rathgeb, University of Duisburg-Essen, Germany

PROGRAM COMMITTEE

    * Hakim Adhari, University of Duisburg-Essen, Germany
    * Nicola Altan, Cetekom, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Glenford Mapp, Middlesex University, United Kingdom
    * Michio Honda, Keio University, Japan
    * Seok J. Koh, Kyungpook National University, Korea
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, University of British Columbia, Canada
    * Irene R?ngeler, M?nster University of Applied Sciences, Germany
    * Robin Seggelmann, M?nster University of Applied Sciences, Germany
    * Esbold Unurkhaan, Mongolian University of Science and Technology, Mongolia
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China

IMPORTANT DATES

    * Paper Submission Deadline:       October 16, 2011
    * Author Notification:             December 01, 2011
    * Camera-Ready Paper Submission:   January 06, 2012

CONTACT

For further information, please contact:

    * Thomas Dreibholz (dreibh AT iem.uni-due.de)
    * Martin Becke (martin.becke AT uni-due.de)

WEBSITE

http://tdrwww.iem.uni-due.de/pams2012.html