lh | 9ed821d | 2023-04-07 01:36:19 -0700 | [diff] [blame] | 1 | .TH RED 8 "13 December 2001" "iproute2" "Linux" |
| 2 | .SH NAME |
| 3 | red \- Random Early Detection |
| 4 | .SH SYNOPSIS |
| 5 | .B tc qdisc ... red |
| 6 | .B limit |
| 7 | bytes |
| 8 | .B [ min |
| 9 | bytes |
| 10 | .B ] [ max |
| 11 | bytes |
| 12 | .B ] avpkt |
| 13 | bytes |
| 14 | .B [ burst |
| 15 | packets |
| 16 | .B ] [ ecn ] [ harddrop] [ bandwidth |
| 17 | rate |
| 18 | .B ] [ probability |
| 19 | chance |
| 20 | .B ] [ adaptive ] |
| 21 | |
| 22 | .SH DESCRIPTION |
| 23 | Random Early Detection is a classless qdisc which manages its queue size |
| 24 | smartly. Regular queues simply drop packets from the tail when they are |
| 25 | full, which may not be the optimal behaviour. RED also performs tail drop, |
| 26 | but does so in a more gradual way. |
| 27 | |
| 28 | Once the queue hits a certain average length, packets enqueued have a |
| 29 | configurable chance of being marked (which may mean dropped). This chance |
| 30 | increases linearly up to a point called the |
| 31 | .B max |
| 32 | average queue length, although the queue might get bigger. |
| 33 | |
| 34 | This has a host of benefits over simple taildrop, while not being processor |
| 35 | intensive. It prevents synchronous retransmits after a burst in traffic, |
| 36 | which cause further retransmits, etc. |
| 37 | |
| 38 | The goal is to have a small queue size, which is good for interactivity |
| 39 | while not disturbing TCP/IP traffic with too many sudden drops after a burst |
| 40 | of traffic. |
| 41 | |
| 42 | Depending on if ECN is configured, marking either means dropping or |
| 43 | purely marking a packet as overlimit. |
| 44 | .SH ALGORITHM |
| 45 | The average queue size is used for determining the marking |
| 46 | probability. This is calculated using an Exponential Weighted Moving |
| 47 | Average, which can be more or less sensitive to bursts. |
| 48 | |
| 49 | When the average queue size is below |
| 50 | .B min |
| 51 | bytes, no packet will ever be marked. When it exceeds |
| 52 | .B min, |
| 53 | the probability of doing so climbs linearly up |
| 54 | to |
| 55 | .B probability, |
| 56 | until the average queue size hits |
| 57 | .B max |
| 58 | bytes. Because |
| 59 | .B probability |
| 60 | is normally not set to 100%, the queue size might |
| 61 | conceivably rise above |
| 62 | .B max |
| 63 | bytes, so the |
| 64 | .B limit |
| 65 | parameter is provided to set a hard maximum for the size of the queue. |
| 66 | |
| 67 | .SH PARAMETERS |
| 68 | .TP |
| 69 | min |
| 70 | Average queue size at which marking becomes a possibility. Defaults to |
| 71 | .B max |
| 72 | /3 |
| 73 | |
| 74 | .TP |
| 75 | max |
| 76 | At this average queue size, the marking probability is maximal. Should be at |
| 77 | least twice |
| 78 | .B min |
| 79 | to prevent synchronous retransmits, higher for low |
| 80 | .B min. |
| 81 | Default to |
| 82 | .B limit |
| 83 | /4 |
| 84 | .TP |
| 85 | probability |
| 86 | Maximum probability for marking, specified as a floating point |
| 87 | number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%, |
| 88 | respectively). Default : 0.02 |
| 89 | .TP |
| 90 | limit |
| 91 | Hard limit on the real (not average) queue size in bytes. Further packets |
| 92 | are dropped. Should be set higher than max+burst. It is advised to set this |
| 93 | a few times higher than |
| 94 | .B max. |
| 95 | .TP |
| 96 | burst |
| 97 | Used for determining how fast the average queue size is influenced by the |
| 98 | real queue size. Larger values make the calculation more sluggish, allowing |
| 99 | longer bursts of traffic before marking starts. Real life experiments |
| 100 | support the following guideline: (min+min+max)/(3*avpkt). |
| 101 | .TP |
| 102 | avpkt |
| 103 | Specified in bytes. Used with burst to determine the time constant for |
| 104 | average queue size calculations. 1000 is a good value. |
| 105 | .TP |
| 106 | bandwidth |
| 107 | This rate is used for calculating the average queue size after some |
| 108 | idle time. Should be set to the bandwidth of your interface. Does not mean |
| 109 | that RED will shape for you! Optional. Default : 10Mbit |
| 110 | .TP |
| 111 | ecn |
| 112 | As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion |
| 113 | Notification allows RED to notify remote hosts that their rate exceeds the |
| 114 | amount of bandwidth available. Non-ECN capable hosts can only be notified by |
| 115 | dropping a packet. If this parameter is specified, packets which indicate |
| 116 | that their hosts honor ECN will only be marked and not dropped, unless the |
| 117 | queue size hits |
| 118 | .B limit |
| 119 | bytes. Recommended. |
| 120 | .TP |
| 121 | harddrop |
| 122 | If average flow queue size is above |
| 123 | .B max |
| 124 | bytes, this parameter forces a drop instead of ecn marking. |
| 125 | .TP |
| 126 | adaptive |
| 127 | (Added in linux-3.3) Sets RED in adaptive mode as described in http://icir.org/floyd/papers/adaptiveRed.pdf |
| 128 | .nf |
| 129 | Goal of Adaptive RED is to make 'probability' dynamic value between 1% and 50% to reach the target average queue : |
| 130 | .B (max - min) / 2 |
| 131 | .fi |
| 132 | |
| 133 | .SH EXAMPLE |
| 134 | |
| 135 | .P |
| 136 | # tc qdisc add dev eth0 parent 1:1 handle 10: red |
| 137 | limit 400000 min 30000 max 90000 avpkt 1000 |
| 138 | burst 55 ecn adaptive bandwidth 10Mbit |
| 139 | |
| 140 | .SH SEE ALSO |
| 141 | .BR tc (8), |
| 142 | .BR tc-choke (8) |
| 143 | |
| 144 | .SH SOURCES |
| 145 | .TP |
| 146 | o |
| 147 | Floyd, S., and Jacobson, V., Random Early Detection gateways for |
| 148 | Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html |
| 149 | .TP |
| 150 | o |
| 151 | Some changes to the algorithm by Alexey N. Kuznetsov. |
| 152 | .TP |
| 153 | o |
| 154 | Adaptive RED : http://icir.org/floyd/papers/adaptiveRed.pdf |
| 155 | |
| 156 | .SH AUTHORS |
| 157 | Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko |
| 158 | <makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>, |
| 159 | Eric Dumazet <eric.dumazet@gmail.com>. |
| 160 | This manpage maintained by bert hubert <ahu@ds9a.nl> |
| 161 | |
| 162 | |