Policing

Previous

2.11.- Policing

Policing flows before entering the domain is a very important matter when dealing with Differentiated Service architecture. In fact, the specifications employ a lot of their contents to insist about these features. Let's start by recalling the policing definition taken from the RFC 2475 [2] specification:

Policing: the process of discarding packets (by a dropper) within a traffic stream in accordance with the state of a corresponding meter enforcing a traffic profile.

Dropper: a device that performs dropping.

Dropping: the process of discarding packets based on specified rules; policing.

Well, Policing → Dropper → Dropping → Policing, again. We have a loop here, haven't we? Anyway, the explanation is clear. Using a dropper (some kind of packet's killer), we have to discard packets to enforce a traffic profile.

The policing process is better done at ingress nodes of the domain. Why? Because it doesn't have any sense to permit packets violating a traffic profile to enter the domain, because sooner than later, the profile must be respected, then the offending packets should be dropped, but now after they consume a share of our valuable resources; then, why don't kill these 'bad citizen' packets before entering our domain? This is the idea behind the policing process.

What do we need to implement a policer? First of all, we should follow the recommendation above, this means, to place our policer on ingress edge router's domain. Avoid brute flows from entering the domain by policing them before they enter. Avoid consuming ingress edge router's resources by advancing the policing process, as soon as is possible to do that.

Beginning with this principle, we need also some way to classify incoming packets to place them in behavior aggregates (do not forget that this is a basic differentiated service architecture principle). Having them in BA, we can check next our traffic profile rules to know what to do when: a.- they respect the rules, i.e., they are in-profile. b.- They do not respect the rules, i.e., they are out-of-profile.

How do we know if they respect or not the rules? We need some kind of metering device. Finally, when we are obliggated to apply the law, we need also some kind of dropper device, to drop the offending packets.

Linux has one all-in-one solution for all these requeriments we have. It's just a classifier with policing. To follow the first recommendation above, we are going to implement it on the INGRESS queuing discipline (well, just for doing this work this pet was created, wasn't it?). Ingress will be implemented in the incoming interface on any domain edge router. Ingress, as was said before, doesn't enqueue packets at all, then we are for sure that resource consumption is minimum. The attached policer filter will be in charge of:

Classifiy entering packets to put them in behavior aggregates (classes).
Apply policing rules we are going to define to fulfill the service level agreement.
Drop those packets that violate the rules.

To do all this work the edge router is going to consume resources, of course, but when remaining packets are forwarded to the outgoing interface to enter the domain, the flows are already clean, and the resource consumption in the outgoing interface queuing discipline and in the inner domain's core routers will be exactly what we need (no more) to manage the traffic we are committed to handle according to the TCAs.

What kind of classifier will we use to implement policing? Just the same we used before to explain the ingress queuing behavior when dealing with the skb->tc_index field (have a look to previous section). The fw classifier and the u32 classifier. Let's start by presenting one example taken (partially) from the Differentiated Service on Linux distribution:

This example is implemented using the fw classifier. First three command are known for us. iptables is used to mark entering packets according to their source ip address. Next four commands implement the fw classifier with policing. Let's concentrate our attention in these commands.

What are we expecting from the classifier? According to what was explained in this section, it should:

Classify entering packets to put them in behavior aggregates (classes)

This is done using iptables which is the tool in charge to classifying packets for this case. After doing the classification, it just marks the fw field in the packet's buffer to signaling the result of this. Above, in the example, packets from network 10.2/24 are marked as fw 1. Rest of packets as fw 2. Perhaps, we could think that this is a very coarse classification. But it's just a matter to use all the power behind iptables. We can rewrite the commands as we like to include on them the kind of classification we want. Final result will be that packets will pass down to the filter elements previously *fw* marked.

But, we are expecting flow aggregation too. This is done using the filter elements. Have a look above to the commands. Packets marked as fw 1 (from network 10.2/24) are placed in three different classes. Did you catch it? flowid 4:1, flowid 4:2 and flowid 4:3 are, in fact, three different classes of the same traffic, where the aggregation is done depending on actual throughput and bursty conditions of this (more about this below).

If you revise back you should remember that these instructions set the packet skb->tc_index field as 1, 2 or 3 respectively. Having the skb->tc_index field set, is just a matter of using dsmark queuing discipline to mark their DS field, or using gred queuing discipline to place them in different red virtual queues for differentiated dropping precedence treatment. Rest of packets are all placed on class 4 (flowid 4:4).

Apply policing rules we are going to define to fulfill the service level agreement

Keywords for policing are as follows:

police rate <rate> : defines the maximum rate (throughput) admitted for this type of traffic.
burst <burst> : defines the maximum burst admitted for this type of traffic.
continue : this means, packets violating this rule must be passed to the next police rule (next filter element).
drop : this means, packets violating this rule must be dropped.

For example, have a look above to the first police rule. It says:

Traffic marked by iptables as fw 1 (handle 1 fw) will be admiited and aggregated to class number 1 (flowid 4:1) up to a maximum rate of 1500kbps with a maximum burst of 90KB. Traffic that exceeds this setting must be passed to the next police rule (continue).

Second police rule says:

Traffic that is passed to this rule is those that: a.- does not match the first police rule, or, b.- has matched but exceeds the first police rule. Over this traffic the second rule is applied as follows: traffic marked by iptables as fw 1 (handle 1 fw) will be admitted and aggregated to class number 2 (flowid 4:2) up to a maximum rate of 1500kbps with a maximum burst of 90KB. Traffic that exceeds this setting must be passed to the next police rule (continue).

Third police rule says:

Traffic that is passed to this rule is those that: a.- does not match the second police rule, or, b.- has matched but exceeds the second police rule. Over this traffic the third rule is applied as follows: traffic marked by iptables as fw 1 (handle 1 fw) will be admitted and aggregated to class number 3 (flowid 4:3) up to a maximum rate of 1000kbps with a maximum burst of 60KB. Traffic that exceeds this setting must be dropped (drop).

Fourth police rule says:

Traffic that is passed to this rule is those that does not match the third police rule (neither the first and second, of course). We can't have traffic that match the three previous rules here (i.e., handle 1 fw), because all this traffic was dropped by the third rule. Traffic we have here is those that match the condition fw 2 (handle 2 fw). Over this traffic the fourth rule is applied as follows: traffic marked by iptables as fw 2 (handle 2 fw) will be admitted and aggregated to class number 4 (flowid 4:4) up to a maximum rate of 1000kbps with a maximum burst of 60KB. Traffic that exceeds this setting must be dropped (drop).

Resumimg, our service level agreement is easy: we admit traffic from network 10.2/24 up to a maximum of 4000kbps, but in three scales. First scale admits traffic from 0 up to 1500kbps, with a maximum burst of 90KB; second scale admits traffic above 1500kbps, but up to a maximum of 1500kbps more, with a maximum burst of 90KB; third scale admits traffic above 3000kbps, but up to a maximum of 1000kbps more, with a maximum burst of 60KB. Traffic from network 10.2/24 exceeding this profile is dropped. From any other network, we admit traffic from 0 up to 1000kbps, with a maximum burst of 60KB; no scales are implemented in this case. Traffic from other networks and exceeding this profile will be dropped.

You should be asking. But, what's the different between these three network 10.2/24's scales? From the point of view of the sending network, perhaps they are equal, but not from our point of view. Different network 10.2/24's scale traffic will be different treated in our domain. To do this we aggregate them using three different classes. They will receive different treatment depending of how we implement our router's queuing discipline to forward these classes within our domain.

There are two additional points that should be observed before we finish this part and jump to the next example. First is prio. Have a look to the prio keyword above. Filter elements are treated according to its prio number. In the example above, prio 4 is treated first, then prio 5, prio 6, and so on. This mechanism guarantees how our filter elements will be searched by the queuing discipline to match entering packets.

Second is burst. Be careful with this. Bursting here is not synonymous of buffering. There's no any packet buffering here because ingress queuing discipline doesn't enqueue packets. Policing filters act using a token bucket to control bandwidth. You can learn a little more about this by reading the section TBF queuing discipline. The same principle is applied here. When you define in this context 'police rate 1500kbit burst 90k', what you are saying is: when throughput is less than 1500kbit, tokens are saved (because they are injected into the bucket to a 1500kbit rate and retired to a lower rate) to be used later, when throughput increases and this saving is needed. Then, burst 90k means that you can save up to a maximum of 90KB of equivalent tokens. This setting permits to deal with bursty flows, but at the same time controlling the maximum permitted burstiness.

Our second example uses the u32 classifier instead of the fw one. This time the configuration is easier because we don't need iptables and the classifier itself is in charge of doing all the work, i.e., classifiying and policing entering packets. Let's see how this goes:

This configuration fulfills the same requeriment of the previous one, but using the u32 classifier. The u32 classifier's classification capability can be used to aggregate flows previously marked from another differentiated service capable domain. To finish this section, let's show another example where we take advantage of this capability to remark entering packets:

Matching by the packet's tos field we aggregate flows entering our domain marked as DS class AF41 (tos 0x88) into three classes according to the throughput and bursting condition. When they are already into, we can remark them using a dsmark queuing discipline (not showed here) that reads the packet skb->tc_index field. Same for packets marked as DS class AF42 (tos 0x90).

With this example we are ready with this section. Next we are going to study in detail the examples included in the Differentiated Service On Linux distribution.

Previous

Content

Next