> On Mar 28, 2017, at 1:25 AM, Jonathan Morton <[email protected]> wrote: > > >> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) <[email protected]> wrote: >> >>> Q1. What were the reasons for introducing such a frequent suppression of >>> the PI algorithm (the RFC just says what this code does, not why)? >> >> To be work conserving and avoid any unnecessary drops are the main reasons >> behind it. >> Cisco had a not so successful algorithm before that is not work >> conserving. So we are extra cautious about being work conserving... > > AQM algorithms are by definition *not* work-conserving, because they can drop > packets. By *definition*. I therefore think you’re chasing a non-goal here, > and you’re going to have to justify it much more clearly if it’s going to > make it into an RFC. > > By all means, avoid dropping packets when the queue is actually empty - that > is, when you’re delivering the last packet in the queue. In that case, there > is no congestion to signal for. But there really is no need to have any > complex state-switching logic for that. If your underlying algorithm is > sound, it will naturally decay to zero packet drops if the empty-queue > condition persists.
I'm not convinced I understand the definitions of "work conserving" and "non work conserving" in this context. A "work conserving" scheduling algorithm keeps an interface transmitting as long as there is data in the queue, while a non-work-conserving algorithm reduces the effective rate of the interface by spacing packets out. _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
