Investigating the LTM TCP Profile: Quality of Service
- Nagle's Algorithm
- Max Syn Retransmissions & Idle Timeout
- Windows & Buffers
- Timers
- QoS
- Slow Start
- Congestion Control Algorithms
- Acknowledgements
- Extended Congestion Notification & Limited Transmit Recovery
- The Finish Line
The LTM supports setting priority at layer 2 with Link QoS and at layer 3 with IP ToS. This can be configured on a pool, a virtual server’s TCP/UDP profile, and in an iRule. The Link QoS field is actually three bits within the vlan tag of an Ethernet frame, and the values as such should be between zero and seven. The IP ToS field in the IP packet header is eight bits long but the six most significant bits represent DSCP. This is depicted in the following diagram:
The precedence level at both layers is low to high in terms of criticality: zero is the standard “no precedence” setting and seven is the highest priority. Things like print jobs and stateless web traffic can be assigned lower in the priority scheme, whereas interactive media or voice should be higher. RFC 4594 is a guideline for establishing DSCP classifications. DSCP, or Differentiated Services Code Point, is defined in RFC 2474. DSCP provides not only a method to prioritize traffic into classes, but also to assign a drop probability to those classes. The drop probability is high to low, in that a higher value means it will be more likely the traffic will be dropped. In the table below, the precedence and the drop probabilities are shown, along with their corresponding DSCP value (in decimal) and the class name. These are the values you’ll want to use for the IP ToS setting on the LTM, whether it is in a profile, a pool, or an iRule. You'll note, however, that the decimal used for IP::tos is a multiple of 4 of the actual DSCP value. The careful observer of the above diagram will notice that the DSCP bits are bit-shifted twice in the tos field, so make sure you use the multiple instead of the actual DSCP value.
Precedence | Type of Service | DSCP Class | DSCP Value | IP::tos Value |
---|---|---|---|---|
0 | 0 | none | 0 | 0 |
1 | 0 | cs1 | 8 | 32 |
1 | 1 | af11 | 10 | 40 |
1 | 10 | af12 | 12 | 48 |
1 | 11 | af13 | 14 | 56 |
10 | 0 | cs2 | 16 | 64 |
10 | 1 | af21 | 18 | 72 |
10 | 10 | af22 | 20 | 80 |
10 | 11 | af23 | 22 | 88 |
11 | 0 | cs3 | 24 | 96 |
11 | 1 | af31 | 26 | 104 |
11 | 10 | af32 | 28 | 112 |
11 | 11 | af33 | 30 | 120 |
100 | 0 | cs4 | 32 | 128 |
100 | 1 | af41 | 34 | 136 |
100 | 10 | af42 | 36 | 144 |
100 | 11 | af43 | 38 | 152 |
101 | 0 | cs5 | 40 | 160 |
101 | 11 | ef | 46 | 184 |
110 | 0 | cs6 | 48 | 192 |
111 | 0 | cs7 | 56 | 224 |
As indicated above, the Link QoS and IP ToS settings can be applied globally to all traffic hitting a pool, or all traffic hitting a virtual to which the profile is applied, but they can also be applied specifically by using iRules, or just as cool, they can be retrieved to make a forwarding decision. In this example, if requests arrive marked as AF21 (decimal 18), forward the request to the platinum server pool, AF11 to the gold pool, and all others to the standard pool.
when CLIENT_ACCEPTED {
if { [IP::tos] == 72 } {
pool platinum
} elseif { [IP::tos] == 40 } {
pool gold
} else {
pool standard
}
}
In this example, set the Ethernet priority on traffic to the server to three if the request came from IP 10.10.10.10:
when CLIENT_ACCEPTED {
if { [IP::addr [IP::client_addr]/24 equals "10.10.10.0"] }
LINK::qos serverside 3
}
}
Note that by setting the Link QoS and/or IP ToS values you have not in any way guaranteed Quality of Service. The QoS architecture needs to be implemented in the network before these markings will be addressed. The LTM can play a role in the QoS strategy in that the marking can be so much more accurate and so much less costly than it will be on the router or switch to which it is connected. Knowing your network, or communicating with the teams that do, will go a long way to gaining usefulness out of these features.