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]
