tc-stab - Generic size table manipulations
tc qdisc add ... stab
[ mtu BYTES ] [ tsize SLOTS ]
[ mpu BYTES ] [ overhead BYTES ]
[ linklayer { adsl | atm | ethernet } ] ...
For the description of BYTES - please refer to the
UNITS section of
tc(8).
- mtu
-
maximum packet size we create size table for, assumed 2048 if not specified
explicitly
- tsize
-
required table size, assumed 512 if not specified explicitly
- mpu
-
minimum packet size used in computations
- overhead
-
per-packet size overhead (can be negative) used in computations
- linklayer
-
required linklayer specification.
Size tables allow manipulation of packet sizes, as seen by the whole scheduler
framework (of course, the actual packet size remains the same). Adjusted
packet size is calculated only once - when a qdisc enqueues the packet.
Initial root enqueue initializes it to the real packet's size.
Each qdisc can use a different size table, but the adjusted size is stored in an
area shared by whole qdisc hierarchy attached to the interface. The effect is
that if you have such a setup, the last qdisc with a stab in a chain
"wins". For example, consider HFSC with simple pfifo attached to one
of its leaf classes. If that pfifo qdisc has stab defined, it will override
lengths calculated during HFSC's enqueue; and in turn, whenever HFSC tries to
dequeue a packet, it will use a potentially invalid size in its calculations.
Normal setups will usually include stab defined only on root qdisc, but
further overriding gives extra flexibility for less usual setups.
The initial size table is calculated by
tc tool using
mtu and
tsize parameters. The algorithm sets each slot's size to the smallest
power of 2 value, so the whole
mtu is covered by the size table.
Neither
tsize, nor
mtu have to be power of 2 value, so the size
table will usually support more than is required by
mtu.
For example, with
mtu = 1500 and
tsize = 128, a table with 128 slots will be created,
where slot 0 will correspond to sizes 0-16, slot 1 to 17 - 32,
..., slot 127 to 2033 - 2048. Sizes assigned to each slot depend
on
linklayer parameter.
Stab calculation is also safe for an unusual case, when a size assigned to a
slot would be larger than 2^16-1 (you will lose the accuracy though).
During the kernel part of packet size adjustment,
overhead will be added
to original size, and then slot will be calculated. If the size would cause
overflow, more than 1 slot will be used to get the final size. This of course
will affect accuracy, but it's only a guard against unusual situations.
Currently there are two methods of creating values stored in the size table -
ethernet and atm (adsl):
- ethernet
-
This is basically 1-1 mapping, so following our example from above
(disregarding mpu for a moment) slot 0 would have 8, slot 1 would
have 16 and so on, up to slot 127 with 2048. Note, that
mpu > 0 must be specified, and slots that would
get less than specified by mpu will get mpu instead. If you
don't specify mpu, the size table will not be created at all (it
wouldn't make any difference), although any overhead value will be
respected during calculations.
- atm, adsl
-
ATM linklayer consists of 53 byte cells, where each of them provides 48
bytes for payload. Also all the cells must be fully utilized, thus the
last one is padded if/as necessary.
When the size table is calculated, adjusted size that fits properly into
lowest amount of cells is assigned to a slot. For example, a 100 byte long
packet requires three 48-byte payloads, so the final size would require 3
ATM cells - 159 bytes.
For ATM size tables, 16 bytes sized slots are perfectly enough. The
default values of mtu and tsize create 4 bytes sized
slots.
The following values are typical for different adsl scenarios (based on
[1] and
[2]):
LLC based:
PPPoA - 14 (PPP - 2, ATM - 12)
PPPoE - 40+ (PPPoE - 8, ATM - 18, ethernet 14, possibly FCS - 4+padding)
Bridged - 32 (ATM - 18, ethernet 14, possibly FCS - 4+padding)
IPoA - 16 (ATM - 16)
VC Mux based:
PPPoA - 10 (PPP - 2, ATM - 8)
PPPoE - 32+ (PPPoE - 8, ATM - 10, ethernet 14, possibly FCS - 4+padding)
Bridged - 24+ (ATM - 10, ethernet 14, possibly FCS - 4+padding)
IPoA - 8 (ATM - 8)
There are a few important things regarding the above overheads:
- •
- IPoA in LLC case requires SNAP, instead of LLC-NLPID (see
rfc2684) - this is the reason why it actually takes more space than
PPPoA.
- •
- In rare cases, FCS might be preserved on protocols that
include Ethernet frames (Bridged and PPPoE). In such situation, any
Ethernet specific padding guaranteeing 64 bytes long frame size has to be
included as well (see RFC2684). In the other words, it also guarantees
that any packet you send will take minimum 2 atm cells. You should set
mpu accordingly for that.
- •
- When the size table is consulted, and you're shaping
traffic for the sake of another modem/router, an Ethernet header (without
padding) will already be added to initial packet's length. You should
compensate for that by subtracting 14 from the above overheads in this
case. If you're shaping directly on the router (for example, with
speedtouch usb modem) using ppp daemon, you're using raw ip interface
without underlying layer2, so nothing will be added.
For more thorough explanations, please see [1] and [2].
It's often forgotten that modern network cards (even cheap ones on desktop
motherboards) and/or their drivers often support different offloading
mechanisms. In the context of traffic shaping, 'tso' and 'gso' might cause
undesirable effects, due to massive TCP segments being considered during
traffic shaping (including stab calculations). For slow uplink interfaces,
it's good to use
ethtool to turn off offloading features.
tc(8),
tc-hfsc(7),
tc-hfsc(8),
[1] http://ace-host.stuart.id.au/russell/files/tc/tc-atm/
[2] http://www.faqs.org/rfcs/rfc2684.html
Please direct bugreports and patches to: <
[email protected]>
Manpage created by Michal Soltys (
[email protected])