> > We should (IMHO) note that it's many years since its use in congestion > control could possibly be "the same as packet drop" -- and by the nature > of AQM, packets need to be ECN-marked before anything must be dropped > due to buffer overflow. > > Obviously (IMHO), an ECN-capable packet which encounters buffer > overflow needs to be dropped: not held until it can be ECN-marked and > forwarded. >
John, Couldn't agree more. That was sort of the whole idea behind the PI controller - something that predicts onset of congestion by observing the derivative in the queue length as well as the absolute value of the queue. One of the failings of RED that we identified in a companion paper to the PI one (http://dna-pubs.cs.columbia.edu/citation/paperfile/22/hollot01control.pdf) was that RED used _averaged_ queue length as the congestion indicator. That introduced a further delay to the feedback loop - by the time your average rose and you to decided to "mark" a packet the buffer was already close to overflowing. With a PI(E) like scheme you can proactively ECN mark packets, keep the delays low but still keep the pipe fully utilized without needing to drop any packets. You can also use ECN marks with DiffServ and handle multiclass traffic (voice/real time streaming vs video downloads etc.) much more efficiently. -Vishal -- http://www.cs.columbia.edu/~misra/ _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
