[LARTC] Alternative section to the HOWTO...

[Andy Furniss]

Javier Ors wrote:
>  IMHO, the priomap explanation in the 9.2.1.1. of the LARTC HOWTO is not
> clear enough. I only understood it's real behavior until I read this
> document from Russell Stuart:
> http://ace-host.stuart.id.au/russell/files/tc/doc/tc/priority.txt So, based
> in this information, I've prepared an alternative priomap explanation for
> this section of the HOWTO, if you like it as it is I could try to do the
> modifications to the .db file. If not, just take what you want from it or
> forget it... It is possibly full plenty of techical mistakes and also
> linux-centered, as long as I have no idea how this goes on other operating
> systems. I'm not a professional, so please don't be hard with the
> criticism...
>    priomap
> 
> Determines how packet priorities, as assigned by the kernel, map to bands.
> 
> The kernel assigns a generic priority to every packet which enters or is
> generated in the machine, this priority is an 8-bit integer, and higher
> value means higher priority. The priomap defines how all the 16 possible
> values of the linux priority are mapped to the bands.
> 
> For example, on the command line, the default priomap looks like this; 1 2 2
> 2 1 2 0 0 1 1 1 1 1 1 1 1. This means the following mapping:
> 
> Linux priority       Default Band (priomap)
> --------------       ----------------------
> 0 (Best Effort)      1
> 1 (Filler)           2
> 2                    2
> 3 (Bulk)             2
> 4 (Interactive Bulk) 1
> 5                    2
> 6 (Interactive)      0
> 7                    0
> 8                    1
> 9                    1
> 10                   1
> 11                   1
> 12                   1
> 13                   1
> 14                   1
> 15                   1
> 
> Some of the linux priority values have a symbolic name, but on the table
> above only five of them are shown. For IPv4 packets we will only care about
> the bands assigned to those five named values. This is beacause for packets
> using this protocol, the priority is assigned based on the ToS octet of the
> packet, which looks like this:
> 
>    0     1     2     3     4     5     6     7
> +-----+-----+-----+-----+-----+-----+-----+-----+
> |                 |                       |     |
> |   PRECEDENCE    |          ToS          | MBZ |
> |                 |                       |     |
> +-----+-----+-----+-----+-----+-----+-----+-----+
> 
> The four ToS bits (the 'ToS field') are defined as:
> 
> Binary Decimal  Meaning
> -----------------------------------------
> 1000   8         Minimize delay (md)
> 0100   4         Maximize throughput (mt)
> 0010   2         Maximize reliability (mr)
> 0001   1         Minimize monetary cost (mmc)
> 0000   0         Normal Service
> 
> As the MBZ must be zero, the actual value of the ToS field is double the
> value of the ToS bits. Tcpdump -v -v shows you the value of the entire ToS
> field, not just the four bits. It is the value you see in the first column
> of the following table, which shows how the ToS values are mapped to the
> five linux priority values mentioned above:
> 
> ToS     Bits  Means                    Linux Priority
> ------------------------------------------------------
> 0x0     0     Normal Service           0 (Best Effort)
> 0x2     1     Minimize Monetary Cost   1 (Filler)
> 0x4     2     Maximize Reliability     0 (Best Effort)
> 0x6     3     mmc+mr                   0 (Best Effort)
> 0x8     4     Maximize Throughput      2 (Bulk)
> 0xa     5     mmc+mt                   2 (Bulk)
> 0xc     6     mr+mt                    2 (Bulk)
> 0xe     7     mmc+mr+mt                2 (Bulk)
> 0x10    8     Minimize Delay           6 (Interactive)
> 0x12    9     mmc+md                   6 (Interactive)
> 0x14    10    mr+md                    6 (Interactive)
> 0x16    11    mmc+mr+md                6 (Interactive)
> 0x18    12    mt+md                    4 (Int. Bulk)
> 0x1a    13    mmc+mt+md                4 (Int. Bulk)
> 0x1c    14    mr+mt+md                 4 (Int. Bulk)
> 0x1e    15    mmc+mr+mt+md             4 (Int. Bulk)
> 
> This mapping is hard-coded and can not be adjusted, only the default priomap
> can be changed, to clarify, the whole process for an IPv4 packet would be:
> 
> ToS value ------mapping------> Linux Priority ------priomap ------> Band
> 
> A few extra comments:
> 
>    - The ToS-to-Linux_Priority mapping is made at the very beggining of
>    the routing process, even before the packet enters in the iptables chains.
>    This means that changing the ToS field of the packet with iptable's "-j
>    TOS --set-tos" flags, will not change neither its linux priority nor
>    the band it will be assigned to.
>    - Also notice that this mapping is not one-to-one, for expample, by
>    only adjusting the priomap, it is impossible to assign a packet with ToS
>    value 0x00 (Normal Service), to a different band than a packet with ToS 0x02
>    (Maximize reliability), as both values are mapped to linux priority 0 (Best
>    Effort).
>    - At the moment of writing this, the ToS octet of the IPv4 protocol
>    has been superseded by the Diffserv Code Point. But the default linux
>    priority mapping, and most common applications (ssh, ftp servers, etc...)
>    are still using the ToS scheme, however, this may change in the future.
> 

I don't know if bert has time to read the list anymore, as you say LARTC 
hasn't been updates for ages.

If mailing bert doesn't get anywhere there was talk of a QOS  wiki being 
started on

http://linux-net.osdl.org/

Andy.