Previous

Content

Next 

3.10. efhtb

  

Google
The example's script is as follows:

#!/bin/bash

# - Main dsmark & classifier
tc qdisc add dev eth1 handle 1:0 root dsmark indices 64 set_tc_index
tc filter add dev eth1 parent 1:0 protocol ip prio 1 tcindex mask 0xfc shift 2

 # - Main htb qdisc & class
tc qdisc add dev eth1 parent 1:0 handle 2:0 htb
tc class add dev eth1 parent 2:0 classid 2:1 htb rate 10Mbit ceil 10Mbit

# - EF Class (2:10)
tc class add dev eth1 parent 2:1 classid 2:10 htb rate 1500Kbit ceil 10Mbit
tc qdisc add dev eth1 parent 2:10 pfifo limit 5
tc filter add dev eth1 parent 2:0 protocol ip prio 1 handle 0x2e tcindex \
classid 2:10 pass_on

# - BE Class (2:20)
tc class add dev eth1 parent 2:1 classid 2:20 htb rate 5Mbit ceil 10Mbit
tc qdisc add dev eth1 parent 2:20 red limit 60KB min 15KB max 45KB \
burst 20 avpkt 1000 bandwidth 10Mbit probability 0.4
tc filter add dev eth1 parent 2:0 protocol ip prio 2 handle 0 tcindex \
mask 0 classid 2:20 pass_on 
This is a very simple implementation of the Expedited Forwarding (EF) class using an htb queuing discipline. To begin with a dsmark queuing discipline is configured. dsmark will be in charge of copying the DS field from entering packets to the skb->tc_index field. The dsmark's main filter reads this value and applies over it the bitwise operation DS & 0xfc >> 2. This operation returns back the class value 0x2e for packets marked as EF, this means, having the DS field set to 0xb8 when entering the discipline. This class id value is then copied back onto the skb->tc_index field by the dsmark queuing discipline.
 
A htb queuing discipline is configured having as parent the dsmark queuing discipline. The htb 2:0 queuing discipline is configured with two classes (besides the 2:1 main class):  the first class, class 2:10, is selected to place on it the packets belonging to the DS EF class. Because these packets, having the skb->tc_index field set to 0x2e are matched against the first classifier element (prio 1 handle 0x2e), the class id 2:10 is returned and the packets are finally placed on it.
 
In the htb class 2:10, a pfifo queuing discipline is configured. The maximum throughput for EF traffic is controlled through the htb class 2:10, up to a maximum of 1.5 Mbps, avoiding this way starvation over low priority traffic (BE) going through class 2:20 (see below). We need to limit as much as possible the length of this pfifo queue to avoid long queue of EF packets that could increase latency in case of congestion; the pfifo queue is configured with five packets length.
 
Best effort (BE) packets are matched with the second classifier element (prio 2 handle 0), being then assigned to htb class 2:20. On this class a red queuing discipline is configured. Red is the best solution for BE traffic not subjugated to any kind of additional preemptive queuing control. It avoids phase effects, allows moderate bursting, doesn't impose any bias to well behaved flows and is as fair as is possible when dropping packets is a necessity. Have a look to Red queuing discipline for more information about this.
 
Some similar as the previous ef-prio scheme, we are just implemeting a simple way for EF packets to kick them out as soon as is possible from the router to avoiding them to loss their time traveling through it. This scheme is normally used for real-time traffic where any delay in the transmission time affect the behavior quality. However the ef-prio scheme works a little better than this, being simpler and faster.
 
Well, fellows!!  We are ready with all the examples of the original Linux Diffserv distribution; our next step in this study will be trying to configure some testbed to check the theoretical part. Then, let's go on.
 
   

 
 
 
Sorry, this work is yet in progress. I will try to add a little everyday as soon as I can steal some time from my schedule...
   

Previous

Content

Next