---

CHOKe: a stateless Active Queue Management scheme

---

• Short-comings of FRED
  • FRED is very costly:

    FRED must maintain information per flow That's a lot of information to maintain ! (since there are several thousands of flows at any one time passing through one router)

  • The next paper we study presents a very ingenious little idea that provides almost the same level of service provided by FRED, but without maintaining any information on each flow

  ---

  ---

• CHOKe
  • The CHOKe algorithm uses similar parameters as RED:

    minthreshold = starting average queue size where the CHOKe algorithm begins dropping packets randomly maxthreshold = starting average queue size where the CHOKe algorithm begins dropping every new arriving packet wq = factor in computing the average queue length (see: click here ) maxp = max drop probability (for details, see: click here )

    ---

  • Flow chart of the CHOKe algorithm:

  • Puesdo code:

    p = new packet; if ( AvgQSize < minthreshold ) { Admit p; } else { /* ------------------------------------------ CHOKe flows with a large packets buffered ------------------------------------------ */ draw a packet q RANDOMLY from the queue; if ( flow(p) == flow(q) ) { drop p and q; // drop packets from likely high volume flow } else if ( minthreshold < AvgQSize <= maxthreshold ) { drop p probabilitically (according to RED's alg); } else // AvgQSize > maxthreshold { drop p; } }

    Key idea:

    The key idea of CHOKe is: when a flow overuses its fair share of bandwidth, the flow will have a lot of packets in the buffer. But drawing a second packet from the buffer and comparing against an arriving packet, we can identify misbehaving flows without keeping any information on the flows !

  ---

  ---

  ---

  ---

• Performance Evaluation of the CHOKe algorithm

  • Simulation Network:

    Notes:

    Bottle neck link: 1 Mbps Flows: 32 TCP flows 1 UDP flow transmitted at 2 Mpbs (twice the bottle neck speed) Note: Without intervention, the 2 Mbps UDP flow will use most (more than 95%) of the 1 Mbps link The UDP flow will block out all TCP flows !!!

  • Other parameter settings:

    Buffer size = 300 packets minthreshold = 100 maxthreshold = 200 wq = unspecified, assumed it used RED's default value (0.002) maxp = unspecified, assumed it used RED's default value (0.1)

    ---

  • Simulation result: Throughput of the UDP flow under DropTail, RED and CHOKe:

    Notes:

    Using DropTail and RED, the UDP flow grabs more than 95% of the bandwidth of the bottleneck link - That's not fair. Using CHOKe, the UDP flow gets about 22% of the bandwidth - Not perfect, but pretty good

    ---

  • Throughput of each flow under CHOKe:

    Note:

    The UDP flow got a little bit more throughput than the TCP flows. - Pretty good result achieved by a very simple addition to RED !!!

  ---

  ---

• Further Improvements
  • Suggested improvements:

    Use 2 or more packets in the comparison Use a dynamical number of packets that varies with the average queue length in the comparison:

  • Note: The paper also contains a simple analysis which does not lead to any important insights

    I omitted the analysis....

  ---

  ---

  ---

  ---

• Bottom line...
  • Sometimes, simple ideas can have very profound impact on the solution of a problem.

  • If you compare the amount of information needed:

    FRED maintains 2 values per flow (I.e.: Number of packets of the flow and number of strikes of the flow)          CHOKe maintain no information on flows

    Considering the effectiveness, then we would have to say that it does NOT worth it to put in so much effort in FRED to gain so little....