[e2e] RES: Why Buffering?

[Detlef Bosau]

Lachlan Andrew wrote:
> Absolutely.  If buffers elsewhere in the network are emptying or
> filling, then the ack rate isn't exactly the rate at which packets
> leave this buffer.  However, Jon seemed to be saying that the arrival
> rate at the queue could somehow exceed the departure rate in the long
> term.  That can only happen if (a) the window is increasing or (b) a
> buffer somewhere else is emptying.
>
>   

That's exactly the reason why I'm not comfortable with the term "rate".

"Rate", as you say yourself, describes a long term behaviour.

However, what you're talking about in the quoted paragraph is short term 
behaviour.

> Why?  *Long term* rates are meaningful, even if there is short-term
> fluctuation in the spacing between adjacent pairs of packets.
>   
Not only in the spacing between adjacent pairs of packets.

I'm still thinking of WWAN. And in WWAN, even the time to convey a 
packet from a base station to a mobile or vice versa is subject to 
short-term fluctuation.


>> One problem is that packets don't travel all parts of a path with the same
>> speed. TCP traffic may be bursty, perhaps links are temporarily unavailable.
>>     
>
> True.  Buffers get their name from providing protection against (short
> timescale) fluctuation in rate.

Is this their main objective?

As Jon pointed out, buffers should compensate asynchrounicity and 
"somehow" care for work compensation.

That's sometimes an interesting discussion between CS and EE guys. EE 
guys, particularly telco-guys quite often think of schedulers, while CS 
guys rarely use explicit scheduling. Think of TCP for instance, where we 
typically don't have schedulers at all.

With WWAN as an important exception: In WWAN, there _are_ schedulers at 
the base stations / access points.

That's one of the "collisions" in "EE thinking" and "CS thinking".

>> I once was told that a guy could drastically improve his throughput by
>> enabling window scaling.....
>> On a path from the US to Germany.
>>
>> I'm not quite sure whether the other users of the path were all amused about
>> the one guy who enabled window scaling ;-)
>>     
>
> Yes, enabling window scaling does allow TCP to behave as it was
> intended on large BDP paths.  If the others weren't amused, they could
> also configure their systems correctly.
>   

Which would leave the original user disappointed because he's not that 
smart as he thought he was ;-)

However: Cui bono? If the only consequence of window scaling is an end 
of the commercial crisis, at least for DRAM manufactures, at the cost of 
extremely long round trip times, we should rather avoid it ;-)

> The comment suggests that you thought that window scaling somehow
> makes one user's window larger than TCP intended. 
No way.
>  It doesn't.  It
> simply allows large windows to be signalled correctly, without
> imposing an artificially small limit.
>
>   

The problem is: Buffering shall provide for work conservation, as Jon 
pointed out. As soon as buffers "overcompensate" idle times and don't 
avoid idle times but introduce latency by themselves, the design is not 
really helpful.




-- 
Detlef Bosau		Galileistraße 30	70565 Stuttgart
phone: +49 711 5208031	mobile: +49 172 6819937	skype: detlef.bosau	
ICQ: 566129673		http://detlef.bosau@web.de