"David R. Oran" <[email protected]> writes: > On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote: > >> Juliusz Chroboczek <[email protected]> writes: >> >>>> PIE [...] lends itself better for implementation in existing >>>> hardware, >>>> or hardware with small modification. >>> >>> Could one of you please explain why? >> >> With the caveat that I have never worked with any of this hardware, >> this >> is my understanding: >> >> Basically, you can re-use the drop mechanism from RED and use the PIE >> algorithm as a (better) way to control the setpoints. This makes it >> possible to retrofit it in existing hardware. In fact I believe you >> can >> implement PIE entirely in the (software) control plane on (a lot of) >> gear that already knows how to do RED. >> > Another factor, which as I recall was perhaps the strongest of the > original motivations for PIE, is that PIE does nearly all its work on > enqueue, whereas CoDel does most of its work on dequeue. In many > hardware interfaces, especially at a head end where there are lots of > queues and a simple hardware FIFO feeding the link, it turns out to be > difficult/expensive to insert the computations CoDel does on each > dequeue operation.
Ah, I see. I guess that makes sense. Although I have also seen someone implement CoDel in a "virtual queueing" setting where all computation is done on enqueue and the sojourn time is simulated ahead of time. You can't do this in all scenarios, but probably in more than one might think... Obviously it would require a bit of work to go from the spec (or reference implementation) to that, but it's definitely possible. -Toke _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
