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

[Wu Yan]

Hi,
   For the 1st question, is the assumption sound?

   For the second question, the major difficulty is FQ is time consuming. In order to do FQ, you should do 
   1 flow identification. For IP packet, possibly you need to take into consideration the IP dest/src address, TCP port number, TOS, etc. 
   2 scheduling, which requires that the router must do some sort to determine the output sequence.
   These 2 steps take some time. You can check the website of Juniper Networks Inc. and see how they are trying solve this problem. 
   Regards.
   
   Yan Wu

----------------------------------------------------------------------
   Telecommunication Research Center 
   Department of Electrical Engineering           
   Arizona State University 
   
  ----- Original Message ----- 
  From: Jeong-woo Cho 
  To: End2End 
  Sent: Wednesday, August 22, 2001 9:00 AM
  Subject: [e2e] Fundamental Questions about Router Queue in High Speed IP Networks




   Studying scheduling algorithms(FQ, SFQ, RED, FRED, REM, BRED, SRED) in IP networks, I got some questions that I cannot answer. If you have any ideas on the following questions, please let me know the answers or the pointers to related literature.

  ** Assumptions : We can reduce larger queuing delays caused by huge router queue size by using several schemes.


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

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