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]
