Wednesday, July 24, 2013

Quality of Service (QoS) Congestion-Avoidance Notes

Congestion-avoidance tools are complementary to, and dependent upon, queuing algorithms. Queuing/scheduling algorithms manage the front of a queue, while congestion-avoidance mechanisms manage the tail of a queue.

Congestion-avoidance tools are designed for TCP traffic, because TCP has built-in flow-control mechanisms that operate by gradually increasing traffic flows until packet loss has occurred.  Once packet loss has occurred, the transmission rate is reduced before slowly ramping up again.  This means that if no mechanism is in place to control TCP, any particular flow has the ability to eat up all available bandwidth.

When there are no congestion-avoidance tools in place, and queues fill, tail drop occurs, which means all traffic is dropped. 

In a constricted channel without congestion-avoidance tools, TCP connections eventually synchronize with each other – they ramp up together, lose packets together, and back off together.  This is called global synchronization and basically results in “waves” of TCP traffic.

Congestion-avoidance tools has no real benefit or use for UDP traffic, because UDP traffic does not have any retry logic.

Random Early Detection (RED)

RED combats global synchronization by preemptively and randomly dropping packets before queues fill.  Instead of waiting for the queues to fill, RED causes the router to monitor the buffer depth and perform early drops on random packets when the defined minimum queue threshold has been exceeded.

RED drops occur within the bounds of TCP retry timers, which slows the transmission rate of sessions but prevents them from starting slow.  This optimizes network throughput.

It should be noted that Cisco IOS doesn’t support RED, only Weighted RED (WRED).  When you utilize the random-detect command in a queue, it actually enables WRED.  However, if there are no separate IPP or DSCP markings within a given class of traffic, then the effective policy is simply RED.

Weighted Random Early Detection (WRED)

WRED is an enhancement to RED that allows you to control how packets are selected to be “randomly” dropped.  A configured minimum threshold determines when packets of a given IPP value begin to be dropped.  The configured maximum threshold determines at what queue depth that all packets of that value will be dropped. The mark probability denominator determines how aggressively that packets of a given IPP value are dropped.  For example, a denominator of 10 means that up to 1 of every 10 packets will be randomly dropped for that IPP value.  The maximum rate of 1 out of every 10 packets being dropped in this example occurs at the configured maximum threshold.  Past the maximum threshold, all packets of that value are dropped (tail drop).

By default, packets with lower IPP values are dropped sooner than packets with higher IPP values. Also, WRED is dependent on queuing, so a queuing option (usually either bandwidth or fair-queue) has to be enabled on the traffic class before you can utilize WRED.

DSCP values can also be used, and this is simply called DSCP-Based WRED.  It pretty much works the same way.  It uses AF drop-preference values (the second digit in the AF code, ex: In “AF21”, the “1”) to determine what packets will be dropped. For example, when WRED is enabled on an interface, packets with a higher drop precedence value, i.e. “AF23” would be dropped more often than those with lower drop precedence values, i.e. “AF21”.

Explicit Congestion Notification (ECN)

Traditionally, the only way to inform sending hosts that there was congestion on the network so they would slow their transmission rates was to drop TCP packets.  ECN was developed to combat this by marking the final 2 bits of the Type of Service (ToS) byte of the IP header.  These two bits are:

  • ECN-Capable Transport (ECT) bit – indicates whether ECN is supported on the device
  • Congestion Experienced (CE) bit – used in tandem with the ECT bit to signal that congestion was experienced en route.

When congestion occurs WRED drops packets when the configured threshold value is exceeded.  ECN is an extension to WRED, in that ECN marks packets instead of dropping them to communicate the existence of congestion.  Routers configured with the WRED ECN feature (Introduced in IOS 12.2(8)T), use this marking to know that the network is congested.  This allows TCP to be controlled  without dropping packets or at least with dropping fewer packets.

WRED ECN takes the following actions based on the bit settings:

  • If the number of packets in a queue are below the configured threshold, packets are transmitted (Normal operation).
  • If the number of packets is between the configured minimum and maximum thresholds:
    • If ECT – 1, CE – 0  or ECT – 0, CE – 1 and WRED determines packet should be dropped based on drop probability, the ECT and CE bits are changed to 1 and the packet is transmitted.
    • If ECT and CE bits are 0, this indicates that the sending device is not capable of ECN and the packet then can be dropped based on WRED drop probability.
    • If both ECT and CE bits are set to 1, the packet indicates that there is network congestion, the packet is transmitted and no further marking is required.
  • If the number of packets in the queue is above the maximum threshold, all packets are dropped.

Dynamic Buffer Limiting (DBL)

This was actually something I didn’t find out about until we started figuring out how to do QoS on a Catalyst 4500.  I went digging on Cisco’s website and from what I saw initially seemed like it was pretty awesome:

image

Industry’s First! Cisco innovation! High-speed hardware implementation!  Of course I want more info, so I clicked on Full Story:

image

Bummer – guess it can’t be found on the Kanye West - I mean cambeywest website.  Even putting in “Dynamic Buffer Limiting” into the search box on Cisco.com came up with nothing. On to Google….

Active Queue Management (AQM), which informs you of congestion before you run into a buffer overflow situation, utilizes DBL to track the queue length for each traffic flow. DBL tracks the queue length for each traffic flow in a switch.  When the queue length exceeds its limit, DBL drops packets or sets the ECN bits in the packet headers.

DBL classifies flows into two categories:

  • adaptive – reduce the rate of packet transmission once it receives congestion notification
  • aggressive – do not take any corrective action in response to congestion notification

For every active flow, the switch maintains two parameters - “buffersUsed” and “credits”.

2 comments:

  1. I've been exploring for a little bit for any high-quality articles or weblog posts in this sort of house . Exploring in Yahoo I at last stumbled upon this website. Reading this info So i am glad to express that I've a very good uncanny feeling I came upon exactly what I needed. I most indubitably will make sure to do not fail to remember this site and provides it a glance on a continuing basis.

    ReplyDelete
  2. I have been browsing online more than three hours today, yet I never found any interesting article like yours. It is pretty worth enough for me. In my opinion, if all website owners and bloggers made good content as you did, the net will be a lot more useful than ever before.

    ReplyDelete