Provided by: iproute2_4.3.0-1ubuntu3_amd64 bug

NAME

       tc-stab - Generic size table manipulations

SYNOPSIS

       tc qdisc add ... stab
           [ mtu BYTES ] [ tsize SLOTS ]
           [ mpu BYTES ] [ overhead BYTES ]
           [ linklayer { adsl | atm | ethernet } ] ...

OPTIONS

       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.

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  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.

TYPICAL OVERHEADS

       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].

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 ethtool to turn off offloading features.

SEE ALSO

       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: <net...@vger.kernel.org>

AUTHOR

       Manpage created by Michal Soltys (sol...@ziu.info)