<div dir="ltr"><div>> On Wed, 10 Jun 2015, Daniel Havey wrote:</div><div>> </div><div>> > We know that (see Kathy and Van's paper) that AQM algorithms only work</div><div>> > when they are placed at the slowest queue.  However, the AQM is placed</div><div>> > at the queue that is capable of providing 8 Mbps and this is not the</div><div>> > slowest queue.  The AQM algorithm will not work in these conditions.</div><div>> </div><div>> so the answer is that you don't deploy the AQM algorithm only at the perimeter, </div><div>> you deploy it much more widely.</div><div>> </div><div>> Eventually you get to core devices that have multiple routes they can use to get </div><div>> to a destination. Those devices should notice that one route is getting </div><div>> congested and start sending the packets through alternate paths.</div><div>> </div><div>> Now, if the problem is that the aggregate of inbound packets to your downstreams </div><div>> where you are the only path becomes higher than the available downstream </div><div>> bandwidth, you need to be running an AQM to handle things.</div><div>> </div><div>> David Lang</div><div><br></div><div>Dynamically load balancing routes is a hard problem because you can only load balance on which routes you send, not on which routes you receive. You also want to make sure the same flows take the same routes in a stateless way. This works fine if your routes all have the same bandwidth, but breaks down as soon as they are not the same.</div><div><br></div><div>Generally you don't want AQMs on core routers. The term "core router" gets used generally as whichever router is at the core of your network, but there is an actual class of routers called "core routers" that are meant to handle the core of the internet. Depending on which group you mean, AQMs may not work. Core routers that are handling ten of gigabits could use AQMs, but real core routers where you're using 100Gb, 400Gb, or soon to be 1Tb/s ports, they can not do AQMs. Many times they cannot do basic QoS without taking a huge penalty to routing speed, like losing 50%-80% of their routing speed. These routers are running up against the laws of physics and any increase in processing comes directly as a cost against performance.</div><div><br></div><div>For me this topic is kind of a sore spot of why I loath many ISPs. Transit provides like Level 3 handle this stuff very well. They deal with lots of routes and lots of peering. They specialize in making sure you get reliable bandwidth to/from anywhere. When a non-transit ISP, even big ones like Comcast, try to handle their own peering and routing, they do a horrible job. Yeah, they can provide you some bandwidth and slap a CDN on their network and now YouTube is decent, but when it comes to long haul transit and peering, they fail horribly.</div><div><br></div><div>Level 3 has stated that their rule of thumb for maintaining nearly non-existent congestion is when a port reaches a 95th percentile above 50% of the link rate, it's time for an upgrade. Even if that link is only at 50% utilization for 1.5 hours a day and near 0% the other 22.5 hours, that port should be upgraded.</div></div>