From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lpp01m010-f43.google.com (mail-lpp01m010-f43.google.com [209.85.215.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 766FD21F0B4 for ; Fri, 18 May 2012 09:27:44 -0700 (PDT) Received: by lahg1 with SMTP id g1so5133522lah.16 for ; Fri, 18 May 2012 09:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=GrzmS57o1A7TLvhMgFpELrzjzE3EFiIQNh5hg+T+HmI=; b=wLhF1S1pGxr6DO7iTydxLX8yBM8s/QPIwoaMwzMv6KR94mhMfy2X/oOJlEvCr28CuH 25pFkHSGt6q1FzUGIwxWxwVywFbuoKbLbh41UV3vw7RR2+queYniT3SrGuTBx4k9ouzS qzjn99Le9HyOZdIP06+W81BR4uT110Gy6P3/I1t3jQ9amyGE/fIUoMWoPw4wPbpjmaUN DW8WDKA+IO8YBzjRBICXOXU01FQnHV44UP0oRS21K0B+J3yYENCIrZfa6D0hk8KHHLCC AZ2QMJS8TP7ZdraryMYAW4L48dmRGB76fJUrAwBFNYOuA16+Sei8YxOlOPnxdbWIZ21N 9MZg== Received: by 10.152.144.168 with SMTP id sn8mr11763487lab.1.1337358461858; Fri, 18 May 2012 09:27:41 -0700 (PDT) Received: from [178.55.237.94] (178-55-237-94.bb.dnainternet.fi. [178.55.237.94]) by mx.google.com with ESMTPS id n7sm7360665lbk.10.2012.05.18.09.27.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 18 May 2012 09:27:40 -0700 (PDT) References: <9C19270966BA4B0F8011BF990D7BAD5E@srichardlxp2> In-Reply-To: <9C19270966BA4B0F8011BF990D7BAD5E@srichardlxp2> Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8C148) From: Jonathan Morton Date: Fri, 18 May 2012 19:28:03 +0300 To: Richard Scheffenegger Cc: "" Subject: Re: [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:27:44 -0000 Given that one of the more subtle features in the codel algorithm is specifi= cally to achieve 100% utilisation instead of 95-98%, by keeping the queue po= pulated with one full-size packet without penalty... I would characterise PQ as being a workaround rather than a true solution. O= ne disadvantage is that it requires a good estimate of the underlying link c= apacity, which might be easy to come by in a wired switched environment but i= s far more difficult to arrange for wireless (which behaves more like bus or= hub Ethernet, only worse).=20 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 r= educing 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.=20= The key to knowledge is not to rely on others to teach you it.=20 On 18 May 2012, at 19:03, "Richard Scheffenegger" wrote: > Hi, >=20 > I assume some of the members of this list, working with AQM schemes are al= so familiar with the work at Stanford around DCTCP. >=20 > In a recent paper of Balaji Prabakhan (DCTCP/ QCN), Phantom Queues are men= tioned as another means to significantly reduce (real queue) occupancy. I th= ink the concept (as virtual queues) stems from ATM times.However, phantom qu= eues 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 t= han the real queue (i.e. at 95-98 of the link capacity - when there is a def= ined link capacity). >=20 > The idea, if I can repeat it properly, is that any standing queue would fo= rm in the phantom queue first, before that standing queue would actually sho= w on the real queue. >=20 > I was wondering if phantom queues and CoDel would work synergistically tog= ether. Or if Phantom Queues should rather be regarded as a workaround for t= he (so far) poor AQM schemes proposed. >=20 > As you are probably aware, DCTCP achieves more than an order of magnitude b= etter network delays by adjusting both the end host TCP stack (alike ECN(alp= ha,beta) to adjust the CWnd dynamically based on the signaled congestion / q= ueue depth), and by utilizing a step-function marking scheme in the network,= instead of a probabilistic marking scheme. >=20 > According to the latest paper, http://www.stanford.edu/~balaji/papers/nsdi= 12-final187.pdf, the utilization of Phantom Queues in a DCTCP environment cu= t the network latency once more by one order of magnitude. Effectively, all b= uffers run virtually empty (except for slow-start / initial window) bursts, a= t only a very minuscle loss of effective network capacity. >=20 > I would like to learn your thoughts around that! > If anyone has a proper ns2 / ns3 environment (mine is currently broken) wh= ere Phantom Queues plus CoDel can be simulated, if any odd interactions aris= e... >=20 > Best regards,=20 > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel