From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6F49221F3F2; Fri, 12 Jun 2015 21:00:21 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t5D40CHB000963; Fri, 12 Jun 2015 21:00:12 -0700 Date: Fri, 12 Jun 2015 21:00:12 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Daniel Havey In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Cake] active sensing queue management X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 04:00:50 -0000 On Fri, 12 Jun 2015, Daniel Havey wrote: > On Thu, Jun 11, 2015 at 6:49 PM, David Lang wrote: >> On Wed, 10 Jun 2015, Daniel Havey wrote: >> >>> We know that (see Kathy and Van's paper) that AQM algorithms only work >>> when they are placed at the slowest queue. However, the AQM is placed >>> at the queue that is capable of providing 8 Mbps and this is not the >>> slowest queue. The AQM algorithm will not work in these conditions. >> >> >> so the answer is that you don't deploy the AQM algorithm only at the >> perimeter, you deploy it much more widely. >> >> Eventually you get to core devices that have multiple routes they can use to >> get to a destination. Those devices should notice that one route is getting >> congested and start sending the packets through alternate paths. >> >> Now, if the problem is that the aggregate of inbound packets to your >> downstreams where you are the only path becomes higher than the available >> downstream bandwidth, you need to be running an AQM to handle things. >> >> David Lang >> > > Hmmmm, that is interesting. There might be a problem with processing > power at the core though. It could be difficult to manage all of > those packets flying through the core routers. And that is the question that people are looking at. But part of the practical question is at what speeds do you start to run into problems? the core of the Internet is already doing dynamic routing of packets, spreading them across multiple parallel paths (peering points have multiple 10G links between peers), so this should be more of the same, with possibly a small variation to use more expensive paths if the cheap ones are congested. But as you move out from there towards the edge, the packet handling requirements drop rather quickly, and I'll bet that you don't have to get very far out before you can start affording to implement AQM algorithms. I'm betting that you reach that point before you get to the point in the network where you no longer have multiple paths available > David does bring up an interesting point though. The ASQM algorithm > was originally designed to solve the "Uncooperative ISP" problem. I > coined the phrase, but, you can fill in your own adjective to fit your > personal favorite ISP :^) > > The paper doesn't indicate this because I got roasted by a bunch of > reviewers for it, but, why not use an ASQM like algorithm other places > than the edge. Suppose you are netflix and your ISP is shaping your > packets? You cant do anything about the bandwidth reduction, but, you > can at least reduce the queuing...Just food for thought. :^) unfortunantly if you are trapped by the ISP/netflix peering war, you reducing the number of packets in flight for yourself isn't going to help any. It would have to happen on the netflix side of the bottleneck. David Lang