Re: [homenet] -CoDel
"David R. Oran" writes: > On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote: > >> Juliusz Chroboczek 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] -CoDel
On 15 Mar 2019, at 8:34, Toke Høiland-Jørgensen wrote: Juliusz Chroboczek 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. -Toke ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet DaveO ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
Juliusz Chroboczek 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. -Toke ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] homenet: what now? ... next?
On Fri, 15 Mar 2019, Juliusz Chroboczek wrote: PIE [...] lends itself better for implementation in existing hardware, or hardware with small modification. Could one of you please explain why? Packet accelerators work either by completely autonomously forwarding packet without CPU involvement, or it works by flow offload. This basically means that on this kind of hardware if you tcpdump packets you'll see the first TCP handshake packets and then kernel sees nothing. It's now offloaded to the packet forwarding hardware, including all queueing decisions. I am not an expert on exact implementations, but WRED is available on a lot of platforms. PIE seems to be taking a stance in WRED and adding a bit of control logic on top of it, and that's that. It means PIE has a possibility to be retrofitted onto older hardware. FQ part of FQ_CODEL means you need to have a lot of queues, and you need to L4 hash onto these different queues. That's just not possible on a lot of HW. I don't know if CODEL can be retrofitted onto WRED style HW, but I don't think so. My observation has been that the bufferbloat movement has focused on academic excellence and making this work on the platforms they have available to them. Nothing wrong with that and the results are great, it's just not applicable to a lot of equipment out there that it should be applicable to. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
