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: =============== Workshop: 31 March - 1 April, 2008 1-page demo description submission deadline: 1 Dec, 2007 Notification of acceptance: 15 Dec, 2007 Final demo submissions: 17 March, 2008 Last date for demo withdrawals: 25 March, 2008 Please email your initial 1-page submissions to: Nandita Dukkipati <nanditad@stanford.edu> and Nick McKeown <nickm@stanford.edu> Best wishes, and we hope to see you in Stanford! Nandita Dukkipati Nick McKeown Program Committee: ================== 1. Albert Greenberg, Microsoft Research 2. Peter Key, Microsoft Research 3. Flavio Bonomi, Cisco 4. Bruce Davie, Cisco 5. Steven Low, Caltech 6. Frank Kelly, Cambridge 7. Lars Eggert, Nokia Research/IETF 8. Nick McKeown, Stanford 9. Guru Parulkar, Stanford 10. Nandita Dukkipati, Stanford/Cisco/Princeton
On 3-Sep-2007, at 1328, nanditad@stanford.edu wrote:
Spurred on by a widespread belief that TCP is showing its age and needs replacing
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
At 9:21 PM -0400 9/3/07, Joe Abley 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... ;-) /John
John Curran wrote:
At 9:21 PM -0400 9/3/07, Joe Abley 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... ;-)
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...
/John
At 7:40 PM -0700 9/3/07, Joel Jaeggli wrote:
John Curran wrote:
At 9:21 PM -0400 9/3/07, Joe Abley 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... ;-)
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.
On Mon, Sep 03, 2007 at 09:37:46PM -0400, John Curran wrote:
At 9:21 PM -0400 9/3/07, Joe Abley 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... ;-) /John
well, if you let the IETF do it... --bill
On Tue, 4 Sep 2007 04:19:32 +0000 bmanning@vacation.karoshi.com wrote:
On Mon, Sep 03, 2007 at 09:37:46PM -0400, John Curran wrote:
At 9:21 PM -0400 9/3/07, Joe Abley 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... ;-) /John
well, if you let the IETF do it...
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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On Mon, 3 Sep 2007 21:21:26 -0400 Joe Abley <jabley@ca.afilias.info> wrote:
On 3-Sep-2007, at 1328, nanditad@stanford.edu wrote:
Spurred on by a widespread belief that TCP is showing its age and > needs replacing
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?
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
On Mon, 3 Sep 2007, Steven M. Bellovin wrote:
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 :-) 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.
On Mon, 3 Sep 2007, Sean Donelan wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow? Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
On Mon, 3 Sep 2007, Sean Donelan wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow?
How would you define "user" in that context? Stephen
On Tue, 4 Sep 2007, Stephen Stuart wrote:
On Mon, 3 Sep 2007, Tony Finch wrote:
On Mon, 3 Sep 2007, Sean Donelan wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow?
How would you define "user" in that context?
Given that we're trusting the user's OS to implement congestion control, it seems reasonable to trust it to define per-user in a sensible way. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
And given that it is travelling between users who may or may not have trust established between them and intermediate systems which may or may not have trust established with each other or the endpoints, we got ourselves a bit of a pickle here. And trust is far bigger than trust in a security sense (where the only presently massively adopted working model is end-to-end with any intermediate systems being completely oblivious -- unless markings for example are exposed on the wrapper..) Sensible it is only within a single administrative control domain, as cross domain isn't just a technical but a business challenge (economic and political). What would an evo of TCP solve over, say, DCCP? Or just using straight unadulterated UDP? Without meaning to offend anyone, sure does smell a bit like Ph.D. thesis generator mode to me. Best Regards, Christian -- Sent from my BlackBerry. -----Original Message----- From: Tony Finch <dot@dotat.at> Date: Tue, 4 Sep 2007 15:09:52 To:Stephen Stuart <stuart@tech.org> Cc:Sean Donelan <sean@donelan.com>, nanog <nanog@merit.edu> Subject: Re: Congestion control train-wreck workshop at Stanford: Call for Demos On Tue, 4 Sep 2007, Stephen Stuart wrote:
On Mon, 3 Sep 2007, Tony Finch wrote:
On Mon, 3 Sep 2007, Sean Donelan wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow?
How would you define "user" in that context?
Given that we're trusting the user's OS to implement congestion control, it seems reasonable to trust it to define per-user in a sensible way. Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
On Tue, 4 Sep 2007, Stephen Stuart wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow?
How would you define "user" in that context?
Operators always define the "user" as the person paying the bill. One bill, one user. Its fun to watch network engineers' heads explode.
On Tue, 4 Sep 2007, Stephen Stuart wrote:
Operators are probably more interested in the "fairness" part of "congestion" than the "efficiency" part of "congestion."
TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not per-flow?
How would you define "user" in that context?
Operators always define the "user" as the person paying the bill. One bill, one user.
It's easy to imagine a context where authentication at the application layer determines "user" in a bill-paying context. Passing that information into the OS, and having the OS try to schedule fairness based on competing applications' "guidance," seems like a level of complexity that adds little value over implementing fairness on a per-flow basis. In theory, any such notion of "user" is lost once the packet gets out on the wire - especially when user is determined by application-layer authentication, so I don't consider 802.1X or the like to be helpful in this instance.
Its fun to watch network engineers' heads explode.
What if the person paying the bill isn't party to either side of the TCP session? Stephen
On Wed, 5 Sep 2007, Stephen Stuart wrote:
Operators always define the "user" as the person paying the bill. One bill, one user.
It's easy to imagine a context where authentication at the application layer determines "user" in a bill-paying context. Passing that information into the OS, and having the OS try to schedule fairness based on competing applications' "guidance," seems like a level of complexity that adds little value over implementing fairness on a per-flow basis. In theory, any such notion of "user" is lost once the packet gets out on the wire - especially when user is determined by application-layer authentication, so I don't consider 802.1X or the like to be helpful in this instance.
Money and congestion are aggregated on many different levels. At the dorm level, money and congestion may be shared on a per-student basis while at the institution level money and congestion may be shared on a per-department basis, and on a backbone level money and congestion may be shared on a per-institution basis. That's the issue with per-flow sharing, 10 institutions may be sharing a cost equally but if one student in one department at one institution generates 95% of the flows should he be able to consume 95% of the capacity?
Its fun to watch network engineers' heads explode.
What if the person paying the bill isn't party to either side of the TCP session?
The person paying the bill is frequently not a party to either side of individual TCP sessions, that is why you also frequently have disputes over which TCP session should experience what level of congestion.
On Sep 5, 2007, at 8:01 AM, Sean Donelan wrote:
That's the issue with per-flow sharing, 10 institutions may be sharing a cost equally but if one student in one department at one institution generates 95% of the flows should he be able to consume 95% of the capacity?
The big problem with this line of reasoning is that the student isn't visible at the network layer; at most, the IP address s/he is using is visible. If the student has an account at each of the universities s/he might be using all of them simultaneously. To the network, at most we can say that there were some number of IP addresses generating a lot of traffic. One can do "interesting" things in the network in terms of scheduling capacity. My ISP in front of my home does that; they configure my cable modem to shape my traffic up and down to not exceed certain rates, and lo and behold my families combined computational capacity doesn't exceed those rates. One could similar do such things on a per- address or per-port basis in an enterprise network. That's where the discussion of per-address WFQ came from a decade ago - without having to configure each system's capabilities, make the systems using a constrained interface share it in some semi-rational manner automatically. That kind of thing is actually a lot harder on the end system; they don't talk with each other about such things. Can that be defeated? Of course; use a different IP address for each BitTorrent TCP session for example. My guess is "probably not on a widespread basis". That kind of statement might fall in the same category as "640K is enough", though. Can you describe for me what problem you would really like solved? Are you saying, for example, that BitTorrent and similar applications should be constrained in some way so that the many TCPs from one system typically gets no more bandwidth than the single TCP on the system next door? Or are you really trying to build constraints on a per-user basis?
On Wed, 5 Sep 2007, Fred Baker wrote:
capacity. My ISP in front of my home does that; they configure my cable modem to shape my traffic up and down to not exceed certain rates, and lo and
Well, in case you're being DDoS:ed at 1 gigabit/s, you'll use more resources in the backbone than most, by some definition of "you". So my take is that this is impossible to solve in the core because routers can't keep track of individual conversations and act on them, doing so would increase cost and complexity enormously. -- Mikael Abrahamsson email: swmike@swm.pp.se
On Wed, 5 Sep 2007, Stephen Stuart wrote:
Operators always define the "user" as the person paying the bill. One bill, one user.
It's easy to imagine a context where authentication at the application layer determines "user" in a bill-paying context. Passing that information into the OS, and having the OS try to schedule fairness based on competing applications' "guidance," seems like a level of complexity that adds little value over implementing fairness on a per-flow basis. In theory, any such notion of "user" is lost once the packet gets out on the wire - especially when user is determined by application-layer authentication, so I don't consider 802.1X or the like to be helpful in this instance.
Money and congestion are aggregated on many different levels. At the dorm level, money and congestion may be shared on a per-student basis while at the institution level money and congestion may be shared on a per-department basis, and on a backbone level money and congestion may be shared on a per-institution basis.
Agreed.
That's the issue with per-flow sharing, 10 institutions may be sharing a cost equally but if one student in one department at one institution generates 95% of the flows should he be able to consume 95% of the capacity?
That depends on the expectations of the institutions. If our example student is able to generate 95% of flows because the network in question is otherwise relatively quiet (maybe it's the middle of the night, or a holiday), then yes, our example student should be able to consume 95% of the capacity. If expectations are otherwise, then no, and I'd expect that policies capable of enforcing that regardless of the number of flows would be put in place at the appropriate boundaries. Let's say our example student is capable of generating 95% of flows by virtue of having access to 95% of the IP endpoints in the example network. How do you envision the OS notion of "user" helping you implement a per-user notion of fairness on the backbone? Stephen
On Wed, 5 Sep 2007, Stephen Stuart wrote:
That depends on the expectations of the institutions. If our example student is able to generate 95% of flows because the network in question is otherwise relatively quiet (maybe it's the middle of the night, or a holiday), then yes, our example student should be able to consume 95% of the capacity. If expectations are otherwise, then no, and I'd expect that policies capable of enforcing that regardless of the number of flows would be put in place at the appropriate boundaries.
If there is no congestion, then this conversation serves no purpose. I'd like one infinite improbability drive too.
Let's say our example student is capable of generating 95% of flows by virtue of having access to 95% of the IP endpoints in the example network. How do you envision the OS notion of "user" helping you implement a per-user notion of fairness on the backbone?
That's why I don't think operators care about "users" or "endpoints" but they do care about who is paying the bills. Operators care about the relative "fairness" between bill payers, not flows, sessions or users. Suppose MIT has a /8, Harvard as a /16; if MIT figured out they could get more backbone bandwidth than Harvard by multiplexing its "flows" across more addresses, and starving Havard students of backbone capacity. Suppose Harvard was paying for 50% of the backbone cost, while poor MIT could only afford to pay for 10% of the backbone cost. If the congestion point was always at the backbone edge, you might be able to accomplish this by making Harvard's connection bigger than MIT's connection. But lets imagine instead, during periods of little congestion you want both Harvard and MIT to use as much of the backbone as they can, and only when there is congestion do you want to "share" the backbone congestion "fairly" between them.
On Wed, 5 Sep 2007, Stephen Stuart wrote:
[...]
If there is no congestion, then this conversation serves no purpose. I'd like one infinite improbability drive too.
Sure. When mine arrives, I'll drop it into my matter replicator so you can have one. :-)
Let's say our example student is capable of generating 95% of flows by virtue of having access to 95% of the IP endpoints in the example network. How do you envision the OS notion of "user" helping you implement a per-user notion of fairness on the backbone?
That's why I don't think operators care about "users" or "endpoints" but they do care about who is paying the bills. Operators care about the relative "fairness" between bill payers, not flows, sessions or users.
Suppose MIT has a /8, Harvard as a /16; if MIT figured out they could get more backbone bandwidth than Harvard by multiplexing its "flows" across more addresses, and starving Havard students of backbone capacity. Suppose Harvard was paying for 50% of the backbone cost, while poor MIT could only afford to pay for 10% of the backbone cost.
If the congestion point was always at the backbone edge, you might be able to accomplish this by making Harvard's connection bigger than MIT's connection. But lets imagine instead, during periods of little congestion you want both Harvard and MIT to use as much of the backbone as they can, and only when there is congestion do you want to "share" the backbone congestion "fairly" between them.
Yes, that's the notion that I was trying to convey. I agree that operators don't care about users, my reason for steering the conversation back toward them is that what kicked this sub-thread off was the assertion that knowledge of user by the OS at a TCP endpoint could somehow provide relevant information for resource allocation in a network such that congestion is divided among users. Techniques for trying to impose how congestion is "fairly" shared among flows exist and aren't what we're talking about. Could a technique be developed that used a notion of "user" in a network? (From Fred's reply, I think that's what we're talking about.) I'd argue that if it could it would be complex and therefore unsuitably fragile in a service provider environment, and would lose all relevance the moment a congestion point at an administrative boundary was crossed. Stephen
On Sep 3, 2007, at 6:44 PM, Steven M. Bellovin wrote:
More seriously -- the question is whether new services will cause operator congestion problems that today's mechanisms don't handle.
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.
On Monday 03 September 2007, Steven M. Bellovin wrote:
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.
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. -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
participants (14)
-
bmanning＠vacation.karoshi.com -
Christian Kuhtz -
Fred Baker -
Joe Abley -
Joel Jaeggli -
John Curran -
Lamar Owen -
Mark Smith -
Mikael Abrahamsson -
nanditad＠stanford.edu -
Sean Donelan -
Stephen Stuart -
Steven M. Bellovin -
Tony Finch