RE: question re RED [7:51650]
bergenpeak wrote: > > When RED is running on an interface, do packets get dropped > before being put into the queue (at the tail, based on ave > queue size, etc) or do they get dropped when they reach the > head of the queue? Incoming packets get dropped before being queued, based on the average queue size. As you probably know, this is different from the classic "tail drop," however, which happens when the queue is full. (Packets at the end or tail of a stream of packets get dropped because the queue is full.) RED drops arriving packets probabilistically. The probability of drop increases as the estimated average queue size grows. Note that RED responds to a time-averaged queue length, not an instantaneous one. Thus, if the queue has been mostly empty in the "recent past", RED won't tend to drop packets (unless the queue overflows, of course!). On the other hand, if the queue has recently been relatively full, indicating persistent congestion, newly arriving packets are more likely to be dropped. I didn't make that up. I got it from RFC 2309. :-) > > Is there any difference in when packets are dropped when WRED > is being used (instead of RED)? Here is where it really gets interesting. >From reading descriptions of RED versus WRED in the excellent book "Integrating Voice and Data Networks" by Scott Keagy, I would say that WRED does muck with packets already queued. Whereas RED cares only about the size of the queue, WRED also has some scheduling capabilities. Here's what he says: "Unlike RED, which purely manages queue depth, WRED also has some characteristics of a scheduling algorithm. Instead of explicitly stating which packets will go next, WRED selects which packets will not go next. Most scheduling algorithms are "additive" in nature, where the final packet order is the result of each packet being explicitly placed in order. WRED starts with a random ordering of packets, and removes packets such that the desired packet ordering is approached. This "subtractive" process offers a very limited scheduling functionality. The additive process offers a much finer control, but the subtractive process uses far fewer system resources." "Whereas the additive ordering mechanism must actively move (or at least store a pointer for) each packet into a new reordered buffer, the subtractive mechanism merely discards packets that violate the ordering rules. Each packet requires less processing and less buffer resources when using the subtractive ordering mechanism." Priscilla > > Thanks > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51679&t=51650 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: question re RED [7:51650]
Hi Priscilla, Thanks much for the response and the RFC reference. Would one still consider a vendor's implementation to be "RED" (compliant with RFC 2309) if packets at the head of the queue are dropped instead of at the tail? Thanks again. Priscilla Oppenheimer wrote: > > bergenpeak wrote: > > > > When RED is running on an interface, do packets get dropped > > before being put into the queue (at the tail, based on ave > > queue size, etc) or do they get dropped when they reach the > > head of the queue? > > Incoming packets get dropped before being queued, based on the average queue > size. As you probably know, this is different from the classic "tail drop," > however, which happens when the queue is full. (Packets at the end or tail > of a stream of packets get dropped because the queue is full.) > > RED drops arriving packets probabilistically. The probability of drop > increases as the estimated average queue size grows. Note that RED responds > to a time-averaged queue length, not an instantaneous one. Thus, if the > queue has been mostly empty in the "recent past", RED won't tend to drop > packets (unless the queue overflows, of course!). On the other hand, if the > queue has recently been relatively full, indicating persistent congestion, > newly arriving packets are more likely to be dropped. > > I didn't make that up. I got it from RFC 2309. :-) > > > > > Is there any difference in when packets are dropped when WRED > > is being used (instead of RED)? > > Here is where it really gets interesting. > > >From reading descriptions of RED versus WRED in the excellent book > "Integrating Voice and Data Networks" by Scott Keagy, I would say that WRED > does muck with packets already queued. Whereas RED cares only about the size > of the queue, WRED also has some scheduling capabilities. Here's what he says: > > "Unlike RED, which purely manages queue depth, WRED also has some > characteristics of a scheduling algorithm. Instead of explicitly stating > which packets will go next, WRED selects which packets will not go next. > Most scheduling algorithms are "additive" in nature, where the final packet > order is the result of each packet being explicitly placed in order. WRED > starts with a random ordering of packets, and removes packets such that the > desired packet ordering is approached. This "subtractive" process offers a > very limited scheduling functionality. The additive process offers a much > finer control, but the subtractive process uses far fewer system resources." > > "Whereas the additive ordering mechanism must actively move (or at least > store a pointer for) each packet into a new reordered buffer, the > subtractive mechanism merely discards packets that violate the ordering > rules. Each packet requires less processing and less buffer resources when > using the subtractive ordering mechanism." > > Priscilla > > > > > Thanks Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51691&t=51650 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: question re RED [7:51650]
bergenpeak wrote: > > Hi Priscilla, > > Thanks much for the response and the RFC reference. Would one > still > consider a vendor's implementation to be "RED" (compliant with > RFC 2309) > if packets at the head of the queue are dropped instead of at > the tail? Well, I don't see any use of the capitalized MUST in the RFC, so it's pretty easy to be "compliant" with the RFC. Dropping at the head of the queue is not what the RFC describes when it's discussing RED, however. The only place it mentions that technique is in the discusssion of methods that handle lock-out but don't handle the full-queues situation. Search for "drop front on full." You'll see that it's mentioned in the RFC, but not in reference to RED. In the discussion of RED, they talk about dropping arriving frames. On the other hand, dropping probabilistically from the front along with managing the average size of the queue over time may accomplish the same thing as the RED techniques that they describe. But Q management can be tricky and have unexpected results if not handled well. I wouldn't take my word for it. The authors of this RFC probably have PhDs in mathematics, computer science, etc. Could you ask them? Their e-mails may be available to someone trying to implement this. (If it's idle curiosity I wouldn't bother them, but you may be a vendor software developer, for all I know.) Priscilla > > Thanks again. > > > > Priscilla Oppenheimer wrote: > > > > bergenpeak wrote: > > > > > > When RED is running on an interface, do packets get dropped > > > before being put into the queue (at the tail, based on ave > > > queue size, etc) or do they get dropped when they reach the > > > head of the queue? > > > > Incoming packets get dropped before being queued, based on > the average queue > > size. As you probably know, this is different from the > classic "tail drop," > > however, which happens when the queue is full. (Packets at > the end or tail > > of a stream of packets get dropped because the queue is full.) > > > > RED drops arriving packets probabilistically. The probability > of drop > > increases as the estimated average queue size grows. Note > that RED responds > > to a time-averaged queue length, not an instantaneous one. > Thus, if the > > queue has been mostly empty in the "recent past", RED won't > tend to drop > > packets (unless the queue overflows, of course!). On the > other hand, if the > > queue has recently been relatively full, indicating > persistent congestion, > > newly arriving packets are more likely to be dropped. > > > > I didn't make that up. I got it from RFC 2309. :-) > > > > > > > > Is there any difference in when packets are dropped when > WRED > > > is being used (instead of RED)? > > > > Here is where it really gets interesting. > > > > >From reading descriptions of RED versus WRED in the > excellent book > > "Integrating Voice and Data Networks" by Scott Keagy, I would > say that WRED > > does muck with packets already queued. Whereas RED cares only > about the size > > of the queue, WRED also has some scheduling capabilities. > Here's what he says: > > > > "Unlike RED, which purely manages queue depth, WRED also has > some > > characteristics of a scheduling algorithm. Instead of > explicitly stating > > which packets will go next, WRED selects which packets will > not go next. > > Most scheduling algorithms are "additive" in nature, where > the final packet > > order is the result of each packet being explicitly placed in > order. WRED > > starts with a random ordering of packets, and removes packets > such that the > > desired packet ordering is approached. This "subtractive" > process offers a > > very limited scheduling functionality. The additive process > offers a much > > finer control, but the subtractive process uses far fewer > system resources." > > > > "Whereas the additive ordering mechanism must actively move > (or at least > > store a pointer for) each packet into a new reordered buffer, > the > > subtractive mechanism merely discards packets that violate > the ordering > > rules. Each packet requires less processing and less buffer > resources when > > using the subtractive ordering mechanism." > > > > Priscilla > > > > > > > > Thanks > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=51775&t=51650 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
