[Codel] CoDel and Phantom Queues?

[Jonathan Morton]

Given that one of the more subtle features in the codel algorithm is specifically to achieve 100% utilisation instead of 95-98%, by keeping the queue populated with one full-size packet without penalty...

I would characterise PQ as being a workaround rather than a true solution. One disadvantage is that it requires a good estimate of the underlying link capacity, which might be easy to come by in a wired switched environment but is far more difficult to arrange for wireless (which behaves more like bus or hub Ethernet, only worse). 

By contrast what codel requires is a first-order estimate of the typical RTT, which can be more than an order of magnitude wrong without significantly reducing performance. So we say 100ms for general purpose because it is close to reality for the Internet and it still works okay for most LAN traffic. 

The key to knowledge is not to rely on others to teach you it. 

On 18 May 2012, at 19:03, "Richard Scheffenegger" <rscheff at gmx.at> wrote:

> Hi,
> 
> I assume some of the members of this list, working with AQM schemes are also familiar with the work at Stanford around DCTCP.
> 
> In a recent paper of Balaji Prabakhan (DCTCP/ QCN), Phantom Queues are mentioned as another means to significantly reduce (real queue) occupancy. I think the concept (as virtual queues) stems from ATM times.However, phantom queues are only a logical (accounting) entitiy, and unlike VQs they are set in series with the real queue, but drained at a rate (1-eps), slightly slower than the real queue (i.e. at 95-98 of the link capacity - when there is a defined link capacity).
> 
> The idea, if I can repeat it properly, is that any standing queue would form in the phantom queue first, before that standing queue would actually show on the real queue.
> 
> I was wondering if phantom queues and CoDel would work synergistically together.  Or if Phantom Queues should rather be regarded as a workaround for the (so far) poor AQM schemes proposed.
> 
> As you are probably aware, DCTCP achieves more than an order of magnitude better network delays by adjusting both the end host TCP stack (alike ECN(alpha,beta) to adjust the CWnd dynamically based on the signaled congestion / queue depth), and by utilizing a step-function marking scheme in the network, instead of a probabilistic marking scheme.
> 
> According to the latest paper, http://www.stanford.edu/~balaji/papers/nsdi12-final187.pdf, the utilization of Phantom Queues in a DCTCP environment cut the network latency once more by one order of magnitude. Effectively, all buffers run virtually empty (except for slow-start / initial window) bursts, at only a very minuscle loss of effective network capacity.
> 
> I would like to learn your thoughts around that!
> If anyone has a proper ns2 / ns3 environment (mine is currently broken) where Phantom Queues plus CoDel can be simulated, if any odd interactions arise...
> 
> Best regards, 
> _______________________________________________
> Codel mailing list
> Codel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel