[e2e] RES: Why Buffering?
Jon.Crowcroft at cl.cam.ac.uk
Wed Jun 24 01:27:08 PDT 2009
In missive <4A40FC9F.9060504 at web.de>, Detlef Bosau typed:
>>Jon Crowcroft wrote:
>>> the naive argument for bw*delay buffer
>>> was that AIMD involves rate halving=20
>>It's not the rate being halved but the congestion window.
>>And I'm always curious to see that some people expect some easy=20
>>relationship between rate and sending window / congestion window. Maybe,=20
>>there is one. Than it's certainly not a trivial one.
that's why i said "naive" argument:)
the rate does halve over a v. long (lotsa rtts) (well, the arrival
rate at the bottleneck) - the packet rate thru the bottleneck
obviously can't exceed the capacity;)
>>> so by corollary, just before the rate halved
>>> it was twice the bottleneck's capacity
>>Yes. That's the common rationale. However, Alexandre is correct here:
>>Some router in between has no idea of a path's capacity - at least as
>>this cannot be easily described by some "latency bandwidth product" in
>>So, the idea of having the "latency bandwidth product" of a path doubled
>>as buffer capacity in a router is a nice one for theoretical papers. But
>>I'm not quite sure what this should mean for reality: Consider a router
>>in Rotterdam which sees both, traffic from Wladiwostok to London,
>>Hamburg to New York and from Den Haag to Santiago to Chile.
>>Which is "the" latency bandwidth product which should be doubled?
>>Surely not a different one for any possible flow.
removing the RT dependence in TCP congestion window is a goal of quite
a few researchers...
>>> if there's lots of flows
>>> and the individual flows are all even reasonably=20
>>> unsynchronised in their AIMD phase
>>> (very good chance due to random local perturbation
>>> (law of large number argument says..)
>>> then you are right (well, nick mckeown's right:)
>>> if you use some smart queue management and ECN
>>> then you're right
>>> if most flows stop before reaching their operating point
>>> your right=20
>>> (well actually, there's a way to be wrong
>>> in a quite ghastly way if you have many sy cnhronised flows
>>> in "slow start", heading thru the same bottleneck...
>>> but it ought to be quite a rare event - like
>>> black swans and mrket meltdowns:-)
>>So, after a long list of scenarios where Alexandre is right: Is there a
>>scenario, where he is wrong? ;-)
More information about the end2end-interest