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. _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
