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

Sean Donelan sean at donelan.com
Wed Sep 5 17:36:21 UTC 2007


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.





More information about the NANOG mailing list