From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by huchra.bufferbloat.net (Postfix) with SMTP id AE9F521F0B8 for ; Fri, 18 May 2012 09:07:52 -0700 (PDT) Received: (qmail invoked by alias); 18 May 2012 16:07:50 -0000 Received: from unknown (EHLO srichardlxp2) [213.143.107.142] by mail.gmx.net (mp072) with SMTP; 18 May 2012 18:07:50 +0200 X-Authenticated: #20720068 X-Provags-ID: V01U2FsdGVkX1+TM+NXLTaTjw6qYnE2FkATtzkLr64Kr+jYISLc/q Phj4McVCBgDUsK Message-ID: <9C19270966BA4B0F8011BF990D7BAD5E@srichardlxp2> From: "Richard Scheffenegger" To: Date: Fri, 18 May 2012 18:03:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Y-GMX-Trusted: 0 Subject: [Codel] CoDel and Phantom Queues? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 16:07:53 -0000 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,