[Cake] active sensing queue management
Benjamin Cronce
bcronce at gmail.com
Fri Jun 12 16:51:29 EDT 2015
> 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
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.
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20150612/def1a9d4/attachment-0002.html>
More information about the Cake
mailing list