Congestion control train-wreck workshop at Stanford: Call for Demos

Congestion control train-wreck workshop at Stanford: Call for Demos

We would like to invite you to a two-day congestion control workshop, titled "Train-wrecks and congestion control: What happens if we do nothing?", which we are hosting at Stanford on 31 March - 1 April, 2008.

Spurred on by a widespread belief that TCP is showing its age and needs replacing - and a deeper understanding of the dynamics of congestion control - the research community has brought forward many new congestion control algorithms. There has been lots of debate about the relative merits and demerits of the new schemes; and a standardization effort is under way in the IETF.

But before the next congestion control mechanism is deployed, it will need to be deployed widely in operating systems and - in some cases - in switches and routers too. This will be a long road, requiring the buy-in of many people: Researchers, product developers and business leaders too. Our own experience of proposing new congestion control algorithms has been met with the challenge: "Show me the compelling need for a new congestion control mechanisms?", and "What will really happen to the Internet (and my business) if we keep TCP just the way it is?"

As a community, we need examples that are simple to understand, and demonstrate a compelling need for change. We call them the "Train wreck scenarios". Examples might show that distribution of video over wireless in the home will come to a halt without new algorithms. Or that P2P traffic will bring the whole network crashing down. Or that huge, high-performance data-centers need new algorithms. Whatever your favorite example, we believe that if we are collectively armed with a handful of mutually agreed examples, it will be much easier to make a business case for change. Or put another way, if we can't articulate compelling examples to industry leaders, then is the cost and risk of change worth it?

The goal of the workshop is to identify a handful of really compelling demonstrations of the impending train-wreck. The outcome will be a set of canonical examples that we will use to persuade industry of the need for change.

We are deliberately inviting you many months ahead of time - to give you time to create your compelling train-wreck demonstration. You can choose the way you present your demonstration: You could bring equipment and show a live-demo; you could show simulations or animations; or you could produce a video showing a real or synthetic demo. Whatever method you choose, the goal is to create a case that will persuade a mildly-technical but influential business leader of the need for change.

We will invite a panel of judges to give prizes for the most compelling examples in two categories: (1) The Overall Most Compelling Example, which will be judged on a combination of the technical merits and the presentation of the scenario, and (2) The Most Technically Compelling Example, which will be judged on its technical merit alone, without consideration of the way it is presented.

The whole purpose of the workshop it to focus on the {\em problem}, not the solutions. We are most definitely {\em not} interested in your favorite scheme, or ours. So we need some ground-rules.
\begin{center}
{\em No-one is allowed to mention a specific mechanism, algorithm or proposal at any time during the workshop: Not in their talk, not in a panel, and not in questions to the speakers. The only mechanisms that will be allowed mention are: TCP (in its standard and deployed flavors), and idealized alternatives for purposes of demonstration. For example, comparing TCP with an oracle that provides instantaneous optimal rates to each flow.}
\end{center}

Attendance to the workshop will be by invitation only - to keep the discussion focused and lively. We will video the entire workshop and all the demonstrations, and make it publicly available on the Internet. We will make any proceedings and talks available too. The goal is to open up the demonstrations for public scrutiny and feedback after the event.

The event is hosted by the Stanford Clean Slate Program - http://cleanslate.stanford.edu - and local arrangements will be made by Nick McKeown and Nandita Dukkipati. The workshop has received offers of support and funding from Cisco Systems and Microsoft. We hope to make a limited number of travel grants available.

We have a small Program Committee (listed below) to select the final demonstrations. We are soliciting a 1-page description of your demo. Please note the following dates.

Important Dates:

I don't mean to hijack this thread unnecessarily, but this seems like an interesting disconnect between ops people and research people (either that or I'm just showing my ignorance, which will be nothing new).

Is there a groundswell of *operators* who think TCP should be replaced, and believe it can be replaced?

Or is the motivation for replacing TCP mainly felt by those who spend a lot of time trying to get maximum performance out of single flows over high bandwidth-delay product paths?

Joe

Just imagine *that* switchover, with the same level of
transition planning as we received with IPv6...
:wink:
/John

Operators speak IP, not TCP -- not your problem...

More seriously -- the question is whether new services will cause
operator congestion problems that today's mechanisms don't handle.
It's also possible, per the note that some solutions will have operator
implications, such as new tuning knobs for routers and/or new funky new
DNS records to make it clear which hosts support TCP++. Beyond that,
there are likely implications for things like firewalls, ACLs, and
service measurements.

    --Steve Bellovin, http://www.cs.columbia.edu/~smb

John Curran wrote:

Is there a groundswell of *operators* who think TCP should be replaced, and believe it can be replaced?

Just imagine *that* switchover, with the same level of
transition planning as we received with IPv6...
:wink:

The congestion control mechanism can be replaced independent of the
transport. In point of fact linux systems have been using bic-tcp by
default since 2004 and nobody noticed...

Backwards compatibility is "a good thing" (and what was not a
achieved in the IPv6 case despite repeated claims to the contrary...)
/John

p.s. bic-tcp (and cubic) certainly have been noticed... "We first
         examined the scenario in which a long-lived Standard TCP and a
         high-speed transport protocol flow coexist. We observed the well-
         known unfairness problem: that is, a highspeed transport protocol
         flow starved the long-lived Standard TCP flow for bandwidth, ..."
         (K. Kumazoe, K. Kouyama, Y. Hori, M. Tsuru, Y. Oie, "Can highspeed
         transport protocols be deployed on the Internet? : Evaluation
         through experiments on JGNII", PFLDnet 2006, Nara, Japan.)
         We really don't know how well windows hosts (or Vista hosts with
         CTCP) actually perform on a shared network of bic-tcp systems.

Is there a groundswell of *operators* who think TCP should be
replaced, and believe it can be replaced?

Or is the motivation for replacing TCP mainly felt by those who spend
a lot of time trying to get maximum performance out of single flows
over high bandwidth-delay product paths?

Operators speak IP, not TCP -- not your problem...

Operators like inefficient protocols :slight_smile:

Operators are probably more interested in the "fairness" part of
"congestion" than the "efficiency" part of "congestion." And of course
the dreaded congestive collapse.

More seriously -- the question is whether new services will cause
operator congestion problems that today's mechanisms don't handle.
It's also possible, per the note that some solutions will have operator
implications, such as new tuning knobs for routers and/or new funky new
DNS records to make it clear which hosts support TCP++. Beyond that,
there are likely implications for things like firewalls, ACLs, and
service measurements.

I think its interesting because its an attempt to define what the problem is, and demostrate that problem exists. The next phase would be can those
conditions actually occur in the real world.

well, if you let the IETF do it...

--bill

TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not
per-flow?

Tony.

and, it includes the questions of what operators will be willing to deploy. One of the questions on the table, for example, is whether the network might be willing to characterize available capacity on links in datagrams that traverse them, either in an IP option or some interior header such as an IPv6 hop-by-hop option. The canonical variants there are XCP and RCP.

As I understand it, the conference organizers want to do something about TCP, but the examples of why it should be done that they are bringing up related to video and other applications. So this is going to have to extend to some variation on a session layer (SIP, for example), and potentially protocols like dccp.

Well, if you're too lazy to participate ... you'll have accept what
you're given. If you're not happy with that, get off your butt and do
something about it.

Is this not partially where SCTP fits in? Reading a few of the SCTP RFC's
certainly indicates that SCTP has some interesting possibilities as far as
congestion control is concerned.