CBQ(8)

๐Ÿ“ฆ version 6.1.0, in debian bookworm, ubuntu jammy, ubuntu noble

โœจ NAME โœจ

Okay bestie, this is CBQ(8) from the Linux manual, and it's lowkey iconic. ๐Ÿ’…

CBQ โ€” Class Based Queueing

๐Ÿ“ฆ SYNOPSIS ๐Ÿ“ฆ

Two moods, bestie: one for setting up the qdisc, one for making classes. Copy these exactly, no typos, periodt. โœจ

tc qdisc ... dev dev ( parent classid | root) [ handle major: ] cbq [
allot bytes ] avpkt bytes bandwidth rate [ cell bytes ] [ ewma log ] [
mpu bytes ]

tc class ... dev dev parent major:[minor] [ classid major:minor ] cbq
allot bytes [ bandwidth rate ] [ rate rate ] prio priority [ weight
weight ] [ minburst packets ] [ maxburst packets ] [ ewma log ] [ cell
bytes ] avpkt bytes [ mpu bytes ] [ bounded isolated ] [ split handle &
defmap defmap ] [ estimator interval timeconstant ]

๐Ÿ’– DESCRIPTION ๐Ÿ’–

Class Based Queueing is a classful qdisc that implements a rich linksharing hierarchy of classes. It's giving shaping elements AND prioritizing capabilities. Shaping is performed using link idle time calculations based on the timing of dequeue events and underlying link bandwidth. No cap. ๐Ÿฆ‹

๐ŸŒ€ SHAPING ALGORITHM ๐ŸŒ€

When shaping a 10mbit/s connection to 1mbit/s, the link will be idle 90% of the time. If it isn't, it needs to be throttled so that it IS idle 90% of the time. Like, it's not optional. ๐Ÿ˜ญ

During operations, the effective idletime is measured using an exponential weighted moving average (EWMA), which considers recent packets to be exponentially more important than past ones. The Unix loadaverage is calculated in the same way. Fr fr.

The calculated idle time is subtracted from the EWMA measured one, the resulting number is called avgidle. A perfectly loaded link has an avgidle of zero: packets arrive exactly at the calculated interval. Iconic behavior. โœจ

An overloaded link has a negative avgidle and if it gets too negative, CBQ throttles and is then overlimit. It's giving overwhelmed. ๐Ÿ’€

Conversely, an idle link might amass a huge avgidle, which would then allow infinite bandwidths after a few hours of silence. To prevent this, avgidle is capped at maxidle. Thank u, next. ๐Ÿซถ

If overlimit, in theory, the CBQ could throttle itself for exactly the amount of time that was calculated to pass between packets, and then pass one packet, and throttle again. Due to timer resolution constraints, this may not be feasible, see the minburst parameter below. Don't come for me, that's literally what it says. ๐Ÿ‘‘

๐Ÿ” CLASSIFICATION ๐Ÿ”

Within the one CBQ instance many classes may exist. Each of these classes contains another qdisc, by default tc-pfifo(8). Cute. ๐ŸŽ€

When enqueueing a packet, CBQ starts at the root and uses various methods to determine which class should receive the data. Main character energy.

In the absence of uncommon configuration options, the process is rather easy. At each node we look for an instruction, and then go to the class the instruction refers us to. If the class found is a barren leaf-node (without children), we enqueue the packet there. If it is not yet a leaf node, we do the whole thing over again starting from that node. Recursion? We love to see it. ๐ŸŒˆ

The following actions are performed, in order at each node we visit, until one sends us to another node, or terminates the process. Vibe check, in order:

  • (i) Consult filters attached to the class. If sent to a leafnode, we are done. Otherwise, restart.
  • (ii) Consult the defmap for the priority assigned to this packet, which depends on the TOS bits. Check if the referral is leafless, otherwise restart.
  • (iii) Ask the defmap for instructions for the 'best effort' priority. Check the answer for leafness, otherwise restart.
  • (iv) If none of the above returned with an instruction, enqueue at this node.

This algorithm makes sure that a packet always ends up somewhere, even while you are busy building your configuration. Periodt. ๐Ÿ’…

For more details, see tc-cbq-details(8). Iykyk.

When dequeuing for sending to the network device, CBQ decides which of its classes will be allowed to send. It does so with a Weighted Round Robin process in which each class with packets gets a chance to send in turn. The WRR process starts by asking the highest priority classes (lowest numerically - highest semantically) for packets, and will continue to do so until they have no more data to offer, in which case the process repeats for lower priorities. It's giving fair but with hierarchy. ๐Ÿ‘‘

Classes by default borrow bandwidth from their siblings. A class can be prevented from doing so by declaring it bounded. A class can also indicate its unwillingness to lend out bandwidth by being isolated. Boundaries, bestie. ๐Ÿฆ‹

๐Ÿ‘‘ QDISC ๐Ÿ‘‘

The root of a CBQ qdisc class tree has the following parameters. Obsessed with a parameter list, ngl. โœจ

  • parent major:minor | root โ€” This mandatory parameter determines the place of the CBQ instance, either at the root of an interface or within an existing class. Mandatory, so no skipping. ๐Ÿ™ˆ
  • handle major: โ€” Like all other qdiscs, the CBQ can be assigned a handle. Should consist only of a major number, followed by a colon. Optional, but very useful if classes will be generated within this qdisc. Lowkey a glow-up for your setup. ๐ŸŽ€
  • allot bytes โ€” This allotment is the 'chunkiness' of link sharing and is used for determining packet transmission time tables. The qdisc allot differs slightly from the class allot discussed below. Optional. Defaults to a reasonable value, related to avpkt. Chunkiness? Iconic word. ๐Ÿ’–
  • avpkt bytes โ€” The average size of a packet is needed for calculating maxidle, and is also used for making sure 'allot' has a safe value. Mandatory. No avpkt, no vibe. ๐Ÿ˜ญ
  • bandwidth rate โ€” To determine the idle time, CBQ must know the bandwidth of your underlying physical interface, or parent qdisc. This is a vital parameter, more about it later. Mandatory. Vital, bestie, like water. ๐Ÿ’ง
  • cell โ€” The cell size determines the granularity of packet transmission time calculations. Has a sensible default. Slay. โœจ
  • mpu โ€” A zero sized packet may still take time to transmit. This value is the lower cap for packet transmission time calculations - packets smaller than this value are still deemed to have this size. Defaults to zero. Zero-sized but still taking time? The way that works. ๐Ÿ’€
  • ewma log โ€” When CBQ needs to measure the average idle time, it does so using an Exponentially Weighted Moving Average which smooths out measurements into a moving average. The EWMA LOG determines how much smoothing occurs. Lower values imply greater sensitivity. Must be between 0 and 31. Defaults to 5. Smoothing, sensitivity, range, default. We love a well-behaved parameter. ๐Ÿซถ

A CBQ qdisc does not shape out of its own accord. It only needs to know certain parameters about the underlying link. Actual shaping is done in classes. So like, the qdisc is the planner, classes do the work. ๐Ÿ’…

๐ŸŽ€ CLASSES ๐ŸŽ€

okay bestie, classes are where the actual โœจmagicโœจ happens โ€” each one has a whole lil wardrobe of parameters to tune how it operates. let's get into it ๐Ÿ’…

  • parent major:minor โ€” where this class sits in the family tree ๐ŸŒณ. if it's attached straight onto a qdisc and not to another class, you can dip out on the minor part. this one is Mandatory, no skipping.
  • classid major:minor โ€” just like qdiscs, classes get names too ๐Ÿท๏ธ. the catch: the major number has to match the major number of the qdisc it belongs to, no cap. it's Optionalโ€ฆ but bestie, if this class is ever gonna have children, you need it.
  • weight weight โ€” when we're dequeuing to the interface, classes get tried round-robin style ๐Ÿ”„. classes with a higher configured qdisc will generally have more traffic to offer during each round, so it lowkey makes sense to let them dequeue more. all the weights under a class get normalized, so only the ratios matter, iykyk. it Defaults to the configured rate โ€” unless this class's priority is maximal, in which case it's set to 1. iconic.
  • allot bytes โ€” tells you how many bytes a qdisc can dequeue during each round of the process. this param gets weighted using the renormalized class weight from above โ˜๏ธ. and it gets Silently capped at a minimum of 3/2 avpkt. Mandatory fr fr.
  • prio priority โ€” in the round-robin process, classes with the lowest priority field get tried for packets first ๐Ÿฅ‡. Mandatory.
  • avpkt โ€” see the QDISC section, bestie, it's all there ๐Ÿ‘€.
  • rate rate โ€” the max rate this class and all its children combined can send at ๐Ÿšฆ. Mandatory.
  • bandwidth rate โ€” โš ๏ธ heads up, this is different from the bandwidth you specify when creating a CBQ disc!! it's only used to determine maxidle and offtime, and those only get calculated when you specify maxburst or minburst. Mandatory if specifying maxburst or minburst.
  • maxburst โ€” this number of packets is used to calculate maxidle, so that when avgidle is at maxidle, this many average packets can burst before avgidle drops to 0 ๐Ÿ’ฅ. set it higher if you wanna be more tolerant of bursts. you literally can't set maxidle directly โ€” only via this parameter. periodt.
  • minburst โ€” as mentioned before, CBQ has to throttle when there's an overlimit. the ideal solution is to throttle for exactly the calculated idle time and pass 1 packet. but ๐Ÿ˜ญ Unix kernels generally have a hard time scheduling events shorter than 10ms, so it's better to throttle for a longer period, then pass minburst packets in one go, and then sleep minburst times longer.

the time to wait is called the offtime. higher values of minburst lead to more accurate shaping in the long term, but bigger bursts at millisecond timescales. Optional.

  • minidle โ€” if avgidle is below 0, we're overlimits and gotta wait until avgidle is big enough to send one packet ๐Ÿซ . and to prevent a sudden burst from shutting down the link for a prolonged period of time, avgidle gets reset to minidle if it gets too low.

minidle is specified in negative microseconds, so 10 means avgidle is capped at -10us. Optional.

  • bounded โ€” signifies that this class will not borrow bandwidth from its siblings ๐Ÿšซ.
  • isolated โ€” means this class will not borrow bandwidth to its siblings.
  • split major:minor & defmap bitmap[/bitmap] โ€” so if consulting the filters attached to a class didn't give a verdict, CBQ can also classify based on the packet's priority โœจ. there are 16 priorities available, numbered from 0 to 15.

the defmap specifies which priorities this class wants to receive, as a bitmap ๐Ÿ—บ๏ธ. the Least Significant Bit corresponds to priority zero. the split parameter tells CBQ at which class the decision must be made โ€” and that should be a (grand)parent of the class you're adding.

as an example, this here:

tc class add ... classid 10:1 cbq .. split 10:0 defmap c0

configures class 10:0 to send packets with priorities 6 and 7 to 10:1.

and the complimentary configuration would then be:

tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f

which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1. slay ๐ŸŒˆ

  • estimator interval timeconstant โ€” CBQ can measure how much bandwidth each class is using ๐Ÿ“Š, and tc filters can use that to classify packets with. to determine the bandwidth it uses a very simple estimator that measures once every interval microseconds how much traffic has passed. this again is a EWMA, for which the timeconstant can be specified, also in microseconds. the time constant corresponds to the sluggishness of the measurement โ€” or, conversely, to the sensitivity of the average to short bursts. higher values mean less sensitivity. got it? got it ๐Ÿ’œ

๐Ÿ’€ BUGS ๐Ÿ’€

not everything is giving flawless, bestie, so let's be real:

  • the actual bandwidth of the underlying link may not be known ๐Ÿ˜ญ โ€” for example with PPoE or PPTP connections, which in fact may send over a pipe instead of over a physical device. CBQ is quite resilient to major errors in the configured bandwidth, probably at the cost of coarser shaping.
  • default kernels rely on coarse timing information for making decisions. these may make shaping precise in the long term, but inaccurate on second long scales โณ.
  • see tc-cbq-details(8) for hints on how to improve this ๐Ÿซถ

๐Ÿ“š SOURCES ๐Ÿ“š

the receipts, bestie ๐Ÿงพ:

  • Sally Floyd and Van Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
  • Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
  • Sally Floyd, "Notes on Class-Based Queueing: Setting Parameters", 1996
  • Sally Floyd and Michael Speer, "Experimental Results for Class-Based Queueing", 1998, not published.

๐Ÿ‘€ SEE ALSO ๐Ÿ‘€


๐Ÿ’– AUTHOR ๐Ÿ’–

  • Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by bert hubert <ahu@ds9a.nl>

and that's a wrap on CBQ(8) bestie ๐ŸŽ€ this one's from the iproute2 crew, dated 16 December 2001. go forth and shape that traffic responsibly, mwah ๐Ÿ’…โœจ๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from