Weighted random early detection

Weighted random early detection (WRED) is a queueing discipline for a network scheduler suited for congestion avoidance.[1] It is an extension to random early detection (RED) where a single queue may have several different sets of queue thresholds. Each threshold set is associated to a particular traffic class.

For example, a queue may have lower thresholds for lower priority packet. A queue buildup will cause the lower priority packets to be dropped, hence protecting the higher priority packets in the same queue. In this way quality of service prioritization is made possible for important packets from a pool of packets using the same buffer.[2]

It is more likely that standard traffic will be dropped instead of higher prioritized traffic.

Restrictions

On Cisco switches WRED is restricted to

  • TCP/IP traffic. Only this kind of traffic indicates congestion to the sender to enable a reduction of the transmission rate.

Non-IP traffic will be dropped more often than TCP/IP traffic because it is treated with the lowest possible precedence.

Functional Description

WRED proceeds in this order when a packet arrives:

  • Calculation of the average queue size.
  • The arriving packet is queued immediately if the average queue size is below the minimum queue threshold.
  • Depending on the packet drop probability the packet is either dropped or queued if the average queue size is between the minimum and maximum queue threshold.
  • The packet is automatically dropped if the average queue size is greater than the maximum threshold.

Calculation of average queue size

The average queue size depends on the previous average as well as the current size of the queue. The calculation formula is given below:

where is the user-configurable exponential weight factor, is the old average and is the current queue size. The previous average is more important for high values of . Peaks and lows in queue size are smoothed by a high value. For low values of , the average queue size is close to the current queue size.

gollark: I assumed it was fine for ASCII.
gollark: Yes.
gollark: osmarkslisp™ is probably TC while regex is… probably a "context-free" grammar?
gollark: So if you replace the osmarkslisp™ parser with json.decode and work out how to fix the string/atom distinction given that, and add string manipulation functions, parsing regex should be doable.
gollark: Well, Lisps are typically encoded in S-expressions, but it's entirely possible to have an utterly homoiconic program in JSON instead.

References
  1. "Congestion Avoidance Overview". Cisco. Retrieved 2012-05-10.
  2. "Class-Based Weighted Fair Queueing and Weighted Random Early Detection". Cisco. Retrieved 2020-05-07.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.