<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_extra">On Fri, 12 Jun 2015, Daniel Havey wrote:</div><div class="gmail_extra">> </div><div class="gmail_extra">> > On Thu, Jun 11, 2015 at 6:49 PM, David Lang <david at <a href="http://lang.hm">lang.hm</a>> wrote:</div><div class="gmail_extra">> >> On Wed, 10 Jun 2015, Daniel Havey wrote:</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >>> We know that (see Kathy and Van's paper) that AQM algorithms only work</div><div class="gmail_extra">> >>> when they are placed at the slowest queue.  However, the AQM is placed</div><div class="gmail_extra">> >>> at the queue that is capable of providing 8 Mbps and this is not the</div><div class="gmail_extra">> >>> slowest queue.  The AQM algorithm will not work in these conditions.</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >></div><div class="gmail_extra">> >> so the answer is that you don't deploy the AQM algorithm only at the</div><div class="gmail_extra">> >> perimeter, you deploy it much more widely.</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >> Eventually you get to core devices that have multiple routes they can use to</div><div class="gmail_extra">> >> get to a destination. Those devices should notice that one route is getting</div><div class="gmail_extra">> >> congested and start sending the packets through alternate paths.</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >> Now, if the problem is that the aggregate of inbound packets to your</div><div class="gmail_extra">> >> downstreams where you are the only path becomes higher than the available</div><div class="gmail_extra">> >> downstream bandwidth, you need to be running an AQM to handle things.</div><div class="gmail_extra">> >></div><div class="gmail_extra">> >> David Lang</div><div class="gmail_extra">> >></div><div class="gmail_extra">> ></div><div class="gmail_extra">> > Hmmmm, that is interesting.  There might be a problem with processing</div><div class="gmail_extra">> > power at the core though.  It could be difficult to manage all of</div><div class="gmail_extra">> > those packets flying through the core routers.</div><div class="gmail_extra">> </div><div class="gmail_extra">> And that is the question that people are looking at.</div><div class="gmail_extra">> </div><div class="gmail_extra">> But part of the practical question is at what speeds do you start to run into </div><div class="gmail_extra">> problems?</div><div class="gmail_extra">> </div><div class="gmail_extra">> the core of the Internet is already doing dynamic routing of packets, spreading </div><div class="gmail_extra">> them across multiple parallel paths (peering points have multiple 10G links </div><div class="gmail_extra">> between peers), so this should be more of the same, with possibly a small </div><div class="gmail_extra">> variation to use more expensive paths if the cheap ones are congested.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yes and no. Spreading data across parallel links is mostly done at the MAC layer and does not show up as separate routes, thinking teaming ports for Ethernet. Routing is dynamic, but typically takes a bit for the route changes to propagate. For the most part, you can only control where you send data, but not where you receive it. The core of the Internet typically only has 2-3 routes to choose from with one primary route and the other only used for fail over. Load balancing asymmetrical routes is a very messy issue that you really don't want to do. Most of the time, the cheapest route is also the fastest. If you had to choose between a $5k/month 100Gb port at a peering location or a $30k 10Gb transit link, I'm sure you won't be doing any load balancing over the 10Gb link unless your 100Gb failed.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Routes really don't change that often. You have a default transit route and a bunch of peering routes. The peering routes take priority because they're cheaper and the transit route is for when bad things happen or you just don't have peering for that route. In the case of my ISP, everything is transit, let Level 3 worry about peering.</div><div class="gmail_extra"> </div><div class="gmail_extra">> But as you move out from there towards the edge, the packet handling </div><div class="gmail_extra">> requirements drop rather quickly, and I'll bet that you don't have to get very </div><div class="gmail_extra">> far out before you can start affording to implement AQM algorithms. I'm betting </div><div class="gmail_extra">> that you reach that point before you get to the point in the network where you </div><div class="gmail_extra">> no longer have multiple paths available</div><div class="gmail_extra">> </div><div class="gmail_extra">> > David does bring up an interesting point though.  The ASQM algorithm</div><div class="gmail_extra">> > was originally designed to solve the "Uncooperative ISP" problem.  I</div><div class="gmail_extra">> > coined the phrase, but, you can fill in your own adjective to fit your</div><div class="gmail_extra">> > personal favorite ISP :^)</div><div class="gmail_extra">> ></div><div class="gmail_extra">> > The paper doesn't indicate this because I got roasted by a bunch of</div><div class="gmail_extra">> > reviewers for it, but, why not use an ASQM like algorithm other places</div><div class="gmail_extra">> > than the edge.  Suppose you are netflix and your ISP is shaping your</div><div class="gmail_extra">> > packets?  You cant do anything about the bandwidth reduction, but, you</div><div class="gmail_extra">> > can at least reduce the queuing...Just food for thought. :^)</div><div class="gmail_extra">> </div><div class="gmail_extra">> unfortunantly if you are trapped by the ISP/netflix peering war, you reducing </div><div class="gmail_extra">> the number of packets in flight for yourself isn't going to help any. It would </div><div class="gmail_extra">> have to happen on the netflix side of the bottleneck.</div><div class="gmail_extra">> </div><div class="gmail_extra">> David Lang</div><div class="gmail_extra">> </div></div></div>