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

[Tan Koan-Sin]

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
> > 
>