[e2e] Fundamental Questions about Router Queue in High Speed IP Networks

[Jiangbin Yang]

Esther made good points.

If the link is serving non-synchronized UDP flows ONLY,
and assuming the "offered load" to the link 
(ratio of total traffic input rate to the total link capacity)
is the same, then the queue size distribution is about the same
independent of the link capacity.
That is, under the condition and assumption, 
"as link speed grows, the queue size needed to accomodate bursts 
does not grow proportionally".
When the queue size distribution is about the same,
queueing delay will be reciprocal to the link speed.

However, if the link is also serving "aggressive" TCP flows,
when the offered load is the same, the queue size may tend to grow
as the link speed (or number of TCP flows) grows
if the queue/buffer is not properly managed.
Indeed, we need queue management algorithms for TCP flows.

Proper buffer size is needed, depends on the transport protocol,
link speed and traffic scenario.

I'd also like to emphasize a bit that 
"this delay (queueing delay when the buffer is full) 
should not constantly occur, and is not meant to enlarge throughput, 
but to prevent loss (which, by the way does enhance throughput and
fairness).


Jiangbin Yang


-----Original Message-----
From: Vos, E.W. [mailto:E.W.Vos at kpn.com]
Sent: Friday, August 24, 2001 12:21 PM
To: End2End
Cc: Neil Spring; 'Tan Koan-Sin'; Jeong-woo Cho
Subject: RE: [e2e] Fundamental Questions about Router Queue in High
Speed IP Networks


Thanx for this question. I was also wondering why buffer sizes are so small
(as I understand, Cisco advises 50 packets, independant of link speed).

I don't see why buffering is so wrong. Actually, a buffer should be large
enough to accomodate incidental bursts of traffic. Aren't the effects of
dropping a packet much worse than delaying one a little bit? 

Of course, we don't need buffers which hols tens of thousands of packets.
But a queue of 50 packets on an STM1 (155Mbps) only adds (assuming 1500B
packets) 4 ms extra delay. Max! And this is only a slow link! Also, as link
speed grows, the queue size needed to accomodate bursts does not grow
proportionally. So why not allow a few 10s of ms delay on STM1s? 

Remember, this delay should not constantly occur, and is not meant to
enlarge throughput, but to prevent loss (which, by the way does enhance
throughput and fairness). Of course, when links speeds are to slow, no
solution (large buffers or loss) will work. But I actually believe these
delay effects are much less worse than loss.  

Esther 


> -----Original Message-----
> From: Tan Koan-Sin [mailto:freedom at csie.nctu.edu.tw]
> Sent: donderdag 23 augustus 2001 10:32
> To: Jeong-woo Cho
> Cc: End2End; Neil Spring
> Subject: Re: [e2e] Fundamental Questions about Router Queue in High
> Speed IP Networks
> 
> 
> 
> FYI.
> 
> Robert Morris studied TCP behavior with many flows, and 
> proposed two methods to cure the time-out problem in the many-flow 
> situation [1]. The first one is that instead of having a buffer about 
> one round-trip time as suggested in [2], the buffer at router 
> should be proportional to the total number of active flows so 
> that TCP flows can survive well. Both FRED [3] and FPQ [4] 
> take this approach. The second approach is to make TCP less 
> aggressive and more adaptive when its congestion window is small. 
> Wu-chang Feng et al proposed SUBTCP in [5], but SUBTCP used a 
> multiplicative increase/ multiplicative decreased algorithm, 
> which will not converge to a fair point. 
> 
> When cwnd is below 4 packets. Limited Transmit [6] can help a 
> little bit.
> 
> [1] Robert Morris, "TCP behavior with many flows,"  ICNP '97.
> [2] Curtis Villamizar and Cheng Song, "High performance TCP 
> in ANSNET,"
>     ACM CCR, vol. 24, no. 5, Oct. 1994. 
> [3] Dong Lin and Robert Morris, "Dynamics of random early detection," 
>     SIGCOMM '97
> [4] Robert Morris, "Scalable TCP Congestion Control," Ph.D thesis, 
>     Harvard University, 1999.
> [5] Wu-chang Feng, Dilip D. Kandlur, Debanjan Saha, and Kang 
> S. Shin,  
>     "Techniques for eliminating packet loss in congested 
> TCP/IP networks,"
>     Tech. Rep., University of Michigan, 1997
> [6] Mark Allman, Hari Balakrishnan, and Sally Floyd, "Enhancing TCP's 
>     loss recovery using Limited Transmit,  Jan. 2001, RFC 3042.
> 
> on Thu, Aug 23, 2001 at 04:24:26PM +0900, Jeong-woo Cho wrote:
> > > 1. That the number of connections that can occupy a
> > > router's buffers limits the number of connections that
> > > can traverse a router. (it doesn't)
> > 
> > I know it doesn't. Router's buffer DOES NOT LIMIT the no. 
> of connections that can traverse a router. But TCP needs 
> buffering. TCP experiences coarse timeouts when cwnd(current 
> windows size) is smaller than 4 packets.
> > 
> > > 
> > > 2. That increased buffering would yield increased
> > > performance: if there's a bottleneck, queueing only adds
> > > delay, not throughput.  buffering -> delay, which hurts
> > > everyone, particularly new tcp flows and those without
> > > window scaling.
> > 
> > I found that RED with 160 kbytes buffer, it can support 
> only 100 flows with satisfactory fairness. (Standard 
> deviation of each flow's share to be smaller than 0.2) Over 
> 100 flows, RED induces TCP's coarse timeouts and fairness 
> could not be achieved AT ALL. 
> > 
> > I agree that "BUFFERING only adds DELAY, not THROUGHPUT". 
> But I want to stress that "BUFFERING improves FAIRNESS"
> > 
> > > 
> > > 3. That tcp's retransmission timeout would be helped by
> > > increased queue space: varying rtt would likely confuse the
> > > retransmission estimator (increasing the retransmission
> > > timeout), while causing spurious retransmissions.  There
> > > are plenty of ways to avoid timeout based retransmission,
> > > (ecn, fast retransmit, sack) at least whenever the window
> > > is larger than a few packets.
> > 
> > ECN should be implemented in all routers in the earth. I 
> don't think that it would be possible in a short time. Fast 
> retransmit can operate well only when each TCP connection's 
> cwnd(current window size) is larger than or equal to 4 packets.
> > 
> > > 
> > > 4. That queues in core routers should be provisioned for
> > > fairness instead of utilization and price.  fairness is
> > > a harder problem than this.
> > 
> > Without guaranteeing fairness to a certain extent, what do 
> a router can guarantee for us? Fairness is more important for 
> real time applications. I found that fairness improves the 
> smoothness of real time applications' instantaneous sending rates.
> > 
> > > 
> > > That said, I wouldn't be surprised if excessively large
> > > queues exacerbate the performance difference between TCP
> > > connections with varying RTT's, as the nearer sender is
> > > better able to saturate the queue, defeating the original 
> > > fairness goal.
> > > 
> > > -neil
> > > 
> > 
>