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

Neil Spring nspring at zarathustra.saavie.org
Wed Aug 22 17:21:38 PDT 2001


Yan Wu described question 2 well, but I couldn't figure
out which of the assumptions you made in question 1 was
questionable.

I think you're making the following questionable
assumptions in question 1:

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)

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.

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.

4. That queues in core routers should be provisioned for
fairness instead of utilization and price.  fairness is
a harder problem than this.

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


On Thu, Aug 23, 2001 at 01:31:49AM +0900, Jeong-woo Cho wrote:
> 1. Why do routers have small queue sizes?
> 
>  Because TCP is a window-based congestion control
> scheme, If routers provide small queue sizes such as 60
> kbytes or 90 kbtytes, only up to 40 or 60 TCP connections
> can be buffered in a router queue. I think that we should
> increase router queue sizes to support more TCP connections
> without TCP's coarse retransmit timeout and to support
> high value of fairness because TCP's VERY coarse timeout
> itself induces unfairness. Is there any technological
> obstables for providing larger router queue sizes? To
> support thoudands of TCP connections in core routers,
> I think that router should provide TCP connections with
> several giga bytes queue sizes.

> 
> 2. Why do researchers stress on Single FIFO scheduling schemes such as RED?
> 
>  If core routers can provide several giga bytes queue size, why don't core routers use Fair Queuing schemes such as Fair Queuing and Stochastic Fair Queuing? I think RED itself and its variant are far to support minimum QoS such as fairness. RED is unscalable in that RED can't prevent buffer overflows when there are many TCP connections. Although SRED(Stabilized RED) solved this problem, I do not think that it can protect TCP connections from unresponsive flows and can provide fairness even when there are only TCP connections.
>  I think that FQ should be implemented in routers, if per-flow queuing can be implemented. Is there any technological obstables for implementing per-flow queuing in high speed core routers?
> 
> 
> Thanks in advance.
> 
> 
> 
> ----------------------------------------------------------------------
>  Cho, Jeong-woo
>  
>  Communication and Information Systems Laboratory
>  Dept. of Electrical Engineering and Computer Science
>  Korea Advanced Institute of Science and Technology(KAIST)
>  373-1 Kusong-dong, Yusong-gu, Taejon 305-701, Korea
>  
>  TEL: +82-42-869-8067 (ex.107) FAX: +82-42-867-0550
>  E-mail: ggumdol at comis.kaist.ac.kr
> ----------------------------------------------------------------------



More information about the end2end-interest mailing list