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

[Wu Yan]

I agree with this argument.
Burstiness will happen in networks. And buffering is to deal with the
burstiness and prevent packet loss. Of course the buffer size should not be
too large. Holding tens of thousands of packets is of no use.
Actually, in a paper on router design by someone in Bell lab(98?), they've
discussed this problem and proposed to use certain amount of buffer to
prevent loss and guarantee performance. I think
their result is collected from router prototypes and shoudl be reliable.

Regards.


Yan Wu

Telecommunications Research Center
Electrical Engineering Department
Arizona State University







----- Original Message -----
From: "Vos, E.W." <E.W.Vos at kpn.com>
To: "End2End" <end2end-interest at postel.org>
Cc: "Neil Spring" <nspring at zarathustra.saavie.org>; "'Tan Koan-Sin'"
<freedom at csie.nctu.edu.tw>; "Jeong-woo Cho" <ggumdol at comis.kaist.ac.kr>
Sent: Friday, August 24, 2001 9:21 AM
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
> > > >
> > >
> >
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/end2end-interest/attachments/20010824/dd47fbf9/attachment.html