[e2e] RES: Why Buffering?

[Alexandre Grojsgold]

Paddy,

 

I’m sorry, but I am afraid I have to strongly disagree with Antonov´s view
on buffer length needs, and perhaps with most people´s opinion on this list.

 

About buffer sizes on routers, I suggest you look for Nick McKeown’s
presentation “Buffers: How we fell in love with them, and why we need a
divorce”. It makes sense to me.

 

IMHO, most of you seem to make confusion between buffers needed at the
*ends* of a TCP connection, and buffers needed middle way.  At the ends,
where congestion is detected, and TCP anti-congestion mechanisms act, large
buffers are necessary when you want to obtain a high bit rate over a long
round trip delay path.

 

This has nothing to do with buffers within routers. A lot of flows flow
through a backbone router. Some of them have large BW, same have very little
BW. Some of them have very very far endpoints, some of them come from the
host in the other side of the town. The router has no clue on the BW.delay
product of each flow, and cannot buffer accordingly – supposing this could
help someway.

 

In his text, Antonov says that buffers add “inertia”. This does not seem
true. In physical systems, inertia is added by mass. Buffers are more like
springs. If you think of a car suspension, a buffer too long is like a
suspension too soft. Maybe good to isolate from road irregularities, but
quite unstable.

 

As buffers grow large, the information about congestion takes longer time to
come back to a TCP sender, what makes the system less stable (not more
stable), and more prone to oscillatory behavior.

 

My vision of what a router does: what a router sees are output interfaces,
with a  given bandwidth and some characteristics. Under light traffic, the
output queue will be almost always empty, at most with a sending packet and
another waiting. If the integration of multiple flows traversing that output
interface gets close to the maximum bandwidth of the interface, and the
system is  close to a stable situation, some probability distribution
function must exist that can describe the queue length. Without any
mathematical proof, I dare to say that the average queue length in this
condition should be of a few (less than 10?) packets. Some fluctuations can
occur due to slight changes in traffic load, and since that does not mean
“congestion”, there must be enough buffer to keep these few packets in the
game. But when the number of packets waiting to be transmitted rises above a
certain limit (20? 40?) packets, this is seen  by the router as sign that
there are more flows trying to cross that output interface than it can
accommodate. So 
 time to start dropping some packets, and make a few
transmitting TCP guys to slow down. The buffer must  have the proper  size
to drop packets when there is a probable congestion, and do not drop packets
under normal fluctuations. Where does delay considerations get here? They
don’t.

 

n  Alexandre.

 

 

 

 

De: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] Em nome de Paddy Ganti
Enviada em: sexta-feira, 19 de junho de 2009 16:20
Para: end2end-interest at postel.org
Assunto: [e2e] Why Buffering?

 

For the question of "why do routers buffer", Vadim Antonov provided the
following rationale (http://www.irbs.net/internet/nanog/0204/0298.html)

----------------------------------------------------------------------------
----------------------------------------------------------------------------
-

Well, so far nobody provided a valid explanation for the necessity of 
buffering in routers (and any other stochastically multiplexing devices). 

The real reason for having buffers is the fact that information about 
congestions takes some time to propagate. (In TCP/IP congestion are 
detected by seeing lost packets). 

If buffers are not sufficient to hold packets until TCP speakers see 
congestion and slow down, the system becomes unstable. Buffers are, 
essentially, inertial elements in the delayed negative-feedback control 
loop. Insufficient inertia causes oscillations in such systems, which is 
sometimes useful, but in case of networks leads to decreased througoutput 
because the wire is utilized fully only at upswings and underutilized on 
downswings (collapsed TCP windows aggravate the effect futher). 

Consequently, the holding capacity of buffers should be sufficient to 
bring the inertia of the system up to the reaction time of the negative 
feedback (this is a simplification, of course). This reaction time is 
about one round-trip time for end-to-end packets. 

In real networks, the RTTs differ for different paths, so some 
"characteristic" RTT is used. So, to hold packets until TCPs slow down a 
router needs cRTT * BW bits of buffer memory (where BW is the speed of the 
interface). This rule can be somewhat relaxed if congestion control loop 
is engaged proactively before congestion occured (by using Random Early 
Detection), but not much. 

Even with properly sized buffers, sessions with longer RTTs suffer from 
congestions disproportionately because TCPs on the ends never get enough 
time to recover fully (i.e. to bring windows to large enough size to 
maintain steady stream of packets), while small-RTT sessions recover 
quickly, and, therefore, get bigger share of bandwidth. But I'm 
digressing :) 

--vadim
----------------------------------------------------------------------------
---------------------------------------------------- 

 

My question to the group is : what other reasons not mentioned here can be
reasons to buffer in a router?

 

-Paddy 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090622/a8f7f824/attachment.html