> On 28 Mar, 2017, at 04:04, Rong Pan (ropan) <ro...@cisco.com> 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. - Jonathan Morton _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
