| .TH STAB 8 "31 October 2011" iproute2 Linux |
| . |
| .SH NAME |
| tc\-stab \- Generic size table manipulations |
| . |
| .SH SYNOPSIS |
| .nf |
| tc qdisc add ... stab |
| .RS 4 |
| [ \fBmtu\fR BYTES ] [ \fBtsize\fR SLOTS ] |
| [ \fBmpu\fR BYTES ] [ \fBoverhead\fR BYTES ] |
| [ \fBlinklayer\fR { adsl | atm | ethernet } ] ... |
| .RE |
| .fi |
| |
| .SH OPTIONS |
| For the description of BYTES \- please refer to the \fBUNITS\fR |
| section of \fBtc\fR(8). |
| |
| .IP \fBmtu\fR 4 |
| .br |
| maximum packet size we create size table for, assumed 2048 if not specified explicitly |
| .IP \fBtsize\fR |
| .br |
| required table size, assumed 512 if not specified explicitly |
| .IP \fBmpu\fR |
| .br |
| minimum packet size used in computations |
| .IP \fBoverhead\fR |
| .br |
| per\-packet size overhead (can be negative) used in computations |
| .IP \fBlinklayer\fR |
| .br |
| required linklayer specification. |
| .PP |
| . |
| .SH DESCRIPTION |
| . |
| 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 \fBtc\fR tool using \fBmtu\fR and |
| \fBtsize\fR parameters. The algorithm sets each slot's size to the smallest |
| power of 2 value, so the whole \fBmtu\fR is covered by the size table. Neither |
| \fBtsize\fR, nor \fBmtu\fR have to be power of 2 value, so the size |
| table will usually support more than is required by \fBmtu\fR. |
| |
| For example, with \fBmtu\fR\~=\~1500 and \fBtsize\fR\~=\~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 \fBlinklayer\fR 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, \fBoverhead\fR 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): |
| |
| .IP ethernet 4 |
| .br |
| This is basically 1\-1 mapping, so following our example from above |
| (disregarding \fBmpu\fR for a moment) slot 0 would have 8, slot 1 would have 16 |
| and so on, up to slot 127 with 2048. Note, that \fBmpu\fR\~>\~0 must be |
| specified, and slots that would get less than specified by \fBmpu\fR will get |
| \fBmpu\fR instead. If you don't specify \fBmpu\fR, the size table will not be |
| created at all (it wouldn't make any difference), although any \fBoverhead\fR |
| value will be respected during calculations. |
| .IP "atm, adsl" |
| .br |
| 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 \fBmtu\fR and \fBtsize\fR create 4\~bytes sized slots. |
| .PP |
| . |
| .SH "TYPICAL OVERHEADS" |
| The following values are typical for different adsl scenarios (based on |
| \fB[1]\fR and \fB[2]\fR): |
| |
| .nf |
| LLC based: |
| .RS 4 |
| 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) |
| .RE |
| |
| VC Mux based: |
| .RS 4 |
| 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) |
| .RE |
| .fi |
| There are a few important things regarding the above overheads: |
| . |
| .IP \(bu 4 |
| IPoA in LLC case requires SNAP, instead of LLC\-NLPID (see rfc2684) \- this is |
| the reason why it actually takes more space than PPPoA. |
| .IP \(bu |
| 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 \fBmpu\fR accordingly for that. |
| .IP \(bu |
| 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 \fB[1]\fR and \fB[2]\fR. |
| . |
| .SH "ETHERNET CARDS CONSIDERATIONS" |
| . |
| 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 \fBethtool\fR to turn off offloading features. |
| . |
| .SH "SEE ALSO" |
| . |
| \fBtc\fR(8), \fBtc\-hfsc\fR(7), \fBtc\-hfsc\fR(8), |
| .br |
| \fB[1]\fR http://ace\-host.stuart.id.au/russell/files/tc/tc\-atm/ |
| .br |
| \fB[2]\fR http://www.faqs.org/rfcs/rfc2684.html |
| |
| Please direct bugreports and patches to: <net...@vger.kernel.org> |
| . |
| .SH "AUTHOR" |
| . |
| Manpage created by Michal Soltys (sol...@ziu.info) |