[e2e] RES: Why Buffering?

[Jon Crowcroft]

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
 >>some networks.
 
 >>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
 >>>  =20
 >>> (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? ;-)

probably.....
 


 cheers

   jon