Traffic Engineering 2015/2016. Fernando M. Silva. Instituto Superior Técnico. QoS, Scheduling & priority queues.

Transcription

1 Traffic Engineering 2015/2016 QoS, Scheduling & priority queues Instituto Superior Técnico Trafffic Engineering 2015/16 1

2 Outline Traffic optimization & QoS Scheduling Queuing disciplines Implementations Trafffic Engineering 2015/16 2

3 Traffic optimization & QoS Traffic optimization is a major goal of Traffic Engineering Traffic optimization can be analyzed at different levels Routing optimization End to end optimization (delay, bandwidth and/or number of hops) Flow optimization by traffic prioritization Traffic prioritization is a major requirement of critical flows demanding strict QoS conditions e.g. real time streams Trafffic Engineering 2015/16 3

4 Packet interference In practice, queuing occurs because there is packet interference: packets arrive before the previous one is processed If packets arrive spaced, no queuing occurs When packets spacing decreases, λ increases, and queuing increases. And QoS decreases Traffic burstiness contributes to packet interference Trafffic Engineering 2015/16 4

5 Traffic burstiness Different burstiness levels with the same packet rate: From top left to bottom right: H = {0.6, 0.7, 0.8, 0.9} (H - Hurst parameter) Trafffic Engineering 2015/16 5

6 Different approaches to QoS support Identify critical flows and increase priority Identify unfair usage and decrease flow priority Traffic shaping Often applied to p2p traffic Increase the bandwidth!! Leaves everybody happy Expensive Unsustainable above a given level For the first two solutions, the process requires Traffic classification Traffic prioritization / scheduling Trafffic Engineering 2015/16 6

7 Scheduling In the general case, scheduling is a common approach to distribute limited resources by a number of users / consumers of resources On traffic engineering, scheduling refers to distribution of the outgoing bandwidth (the limited resource) by a number of incoming flows (the users / consumers) Usual approach to scheduling in IP networks: Distribute incoming traffic by different queues Distribute outgoing bandwidth by the different queues adopting some fair criteria Trafffic Engineering 2015/16 7

8 Multiple queues When any queue fills up, packet drops occur, increasing delay and reducing observed bandwidth By servicing the several queues following different disciplines/policies, it is possible to reduce the probability of packet drops on a given queue or to keep the delay below a given threshold Trafffic Engineering 2015/16 8

9 Scheduling and fairness Scheduling defines service order Packet drop policy defines how and which packets are dropped IF a given queue fills up Scheduling should achieve a fair bandwidth distribution But what means fair? Trafffic Engineering 2015/16 9

10 Fair distribution of resources: Max-Min Fair allocation Resources are distributed by increasing requirement order Using this approach, flows with higher requirements may make use of spare (unused) capacity of lower requirement flows No flow receives a capacity higher than the required one All flows have a minimum equal guaranteed distributed capacity which is the total capacity divided by the number of flows. Trafffic Engineering 2015/16 10

11 Fair Share of a Resource Example reproduced from Ivan Marsic, Rutgers University. Trafffic Engineering 2015/16 11

12 Max-Min Fair Share (1) Trafffic Engineering 2015/16 12

13 Max-Min Fair Share (2) Trafffic Engineering 2015/16 13

14 Max-Min Fair Share (3) Trafffic Engineering 2015/16 14

15 Max-Min Fair Share Trafffic Engineering 2015/16 15

16 Max-min fair bandwidth allocation C: Channel capacity, N flows Bandwidth requirements: x 1 x 2 x 3... x N Min guaranteed capacity per flow: C/N Max min distribution: Flow 1 may use c 1 = C/N Spare capacity: s 1 = max(c 1 x 1, 0) if C/N < x 1 there is no spare capacity from flow 1) Flow 2 may use its min guaranteed plus its share of the spare from 1 (if any): c 2 = C/N + s 1 /(N 1) Spare capacity: s 2 = max(c 2 x 2, 0) Flow 3 may use c 3 = C/N + s 1 /(N 1) + s 2 /(N 2), s 3 = max(c 3 x 3, 0) Flow N may use C/N + N 1 k=1 s k/(n k) Trafffic Engineering 2015/16 16

17 Weighted max-min fair bandwidth allocation Weighted max-min bandwidth allocation is similar to the max-min above, but channel capacity is distributed according to the relative channel weight (instead of being equal for all) More precisely If the weights are w 1, w 2,.., w N, being k w k = 1, each weight translates to the percentage of bandwidth allocated to each flow The minimum guaranteed bandwidth of flow k is w k C Note: if w 1 = w 2 =... = w N, the minimum bandwidth of flow k is w k C = C/N Trafffic Engineering 2015/16 17

18 Implementing MMFS with Packets Problem: Packets are of different length, arrive randomly, and must be transmitted atomically, as a whole Packets cannot be split in pieces to satisfy the MMFS bandwidth allocation Solution: Try to approximate MMFS with different queuing disciplines. Trafffic Engineering 2015/16 18

19 Generalized Processor Sharing (GPS) Optimal algorithm Can not be implemented in TE since is defined considering continuous resources and requirements Often used as a reference (how near to GPS is a practical algorithm?) Ideally, all flows should be served at the same time, in proportion to a given weight and the total channel capacity, C. If the N queues have relative weights w 1, w 2,..., w N, with N j=1 w j = 1 the minimum guaranteed rate to each flow is r j = w j C Since some flows may not have packets to be served, the real bandwidth distributed to channel j is w j b j = C active i w i Trafffic Engineering 2015/16 19

20 Queueing disciplines There are several queue polices And anyone may create new ones Queues must obey to some optimality criteria Some disciplines try to approximate the Generalized Processor Sharing policy Can not be matched exactly Some practical common disciplines FIFO Priority Queuing Round robin Deficit round robin Weighted fair queing Trafffic Engineering 2015/16 20

21 FIFO Simple first in first out policy There is no priority distribution By nature, bandwidth is distributed in proportion to flow bandwidth It gives more bandwidth to flows with more traffic There is no selective packet drop: packet drop occur when the buffer queue fills up, irrespective of which flow is being dropped (and independently of which flow is causing service saturation) Important note: It is too simple, but it is the default policy in most routers! Trafffic Engineering 2015/16 21

22 Priority queuing In the strict priority queue discipline, packets on higher priority queues are allways served before lower priority queues In practice, it only guarantees service to the higher priority queue Lower priority queues may never be served Trafffic Engineering 2015/16 22

23 Round Robin In the Round-Robin discipline, one packet is served from each queue in a fixed sequence order Discussion: features vs limitations? Trafffic Engineering 2015/16 23

24 Round robin - features & limitations All flows are served No priority between flows / all flows equal Since each cycle serves one packet, this policy favors flows with larger packets Reasonable if all flows have equal size packets Trafffic Engineering 2015/16 24

25 Weighted Round Robin In the weighted Round Robin scheme, in each cycle it is served a number of bytes from each queue proportional to the relative weight of the queue Assume that the weights are w 1, w 2,.., w N, with k w k = 1 If all queues have packets of equal size, one must find a set of integers n 1, n 2, n 3,..., n N that must be served from each cycle from each queue in proportion to the weights: n k N j=1 n j w k, n k w k N n j j=1 Usually, there is not an exact match, and an approximation must be used Trafffic Engineering 2015/16 25

26 Weighted Round Robin (WRR) If the average length q k of the packets in each queue k is different, one must adjust the service according to this length In fact, if we are concerned with effective bandwidth distribution between queues, we must think in bits instead of packets How? Take into account the average packet size in each queue!! More specifically, the n k must now verify the relation N n k q k w k j=1 q j n j Trafffic Engineering 2015/16 26

27 WRR with different queue sizes: alternative approach Start by normalizing the weight: w j = w j /q j w i are the new weights, weighted by the relative (averages) queue sizes Decreases the relative weight of large packets sizes Apply WRR as usual (but recall j w j 1) n k N j=1 n j w k N, n k w k N j=1 w j j=1 w j N j=1 n j Trafffic Engineering 2015/16 27

28 Weighted Round Robin - Implementation Approximate implementation of the WRR algorithm: for each flow f: f.norm_weight = f.weight / f.mean_packet_size min = findsmallestnormalizedweight for each flow f f.packets_to_be_served = f.normalized_weight / min loop for each non-empty flow queue f repeat min(f.packets_to_be_served, f.packets_waiting): servepacket f.getpacket Discuss: limitations/problems of the algorithm? Trafffic Engineering 2015/16 28

29 Limitations of WRR implementations Number of packets is almost always an approximation Average packet size per queue must be known in advance The server may stay in the same flow for a large time Trafffic Engineering 2015/16 29

30 Deficit Round Robin (DRR) The DRR algorithm enables an approximate implementation of WRR without requiring to know the average packet size in each queue Algorithm Assign at each queue an initial credit c j ; this is a variable parameter Assign at each queue a threshold L j. L j only depends on the queue. Larger L j higher priority Loop on the queues On each visit to queue j If n j > 0, c j = c j + L j If n j = 0, c j = 0 For each packet p i in queue j if(len(p i ) < c j ), process p i, c j = c j len(p i ) Trafffic Engineering 2015/16 30

31 Fair queuing This scheduling method is inspired by the most fair of methods: Attempts to implement GPS Also known as Packet Generalized Processor Sharing Transmit one bit from each queue in cyclic order (bit-by-bit round robin) Skip queues that are empty To approximate the bit-by-bit processing behavior, for each packet Calculate upon arrival its finish time under bit-by-bit round robin assuming all other queues are continuously busy, and transmit by FIFO within each queue Transmit next the packet with the minimum finish time Important properties: Priority is given to short packets Equal bandwidth is allocated to all queues that are continuously busy Trafffic Engineering 2015/16 31

32 Weighted fair queuing Fair queuing cannot be used to implement bandwidth allocation and soft priorities Weighted fair queuing is a variation that corrects this deficiency Let w k be the weight of the kth queue Think of round-robin with queue k transmitting w k bits upon its turn If all queues have always something to send, the kth queue receives bandwidth equal to a fraction w k / i w i of the total bandwidth Fair queuing corresponds to w k = 1, k Priority queuing corresponds to the weights being very high as we move to higher priorities Again, to deal with the segmentation problem, we approximate as follows: For each packet: We calculate its finish time (under the weighted bit-by-bit round robin scheme) We next transmit the packet with the minimum finish time Trafffic Engineering 2015/16 32

33 Fair Queueing (FQ): Implementation Think on an integer time, bit by bit RR Definitions: Round Robin Number (RN) - Current cycle number Finish Number (FN) - Cycle Number considering a bit by bit RR The final number of an arriving packet k to queue i and length L k is given by If there are packets on queue i: F N i,k = F N i,k 1 + L k If the queue i is empty F N i,k = RN + L k Select for transmission the pack on the queue with smallest F N But recall that in practice all packet is transmitted at once, and not in a bit by bit scheme Trafffic Engineering 2015/16 33

34 FQ in practice Round is a complete cycle through all queues sending one bit per cycle The time duration of a round depends on the number of active connections RN and FN work on a virtual time and can be fractional If the system can send C bits per second and there are N active flows RN(t + t) = RN(t) + C N act t Considering this definition and the channel capacity, the Finish Numbers in this virtual time basis are Non empty queue F N i,k = F N i,k 1 + L k Empty queue F N i,k = RN + L k Trafffic Engineering 2015/16 34

35 FQ in practice (2) Considering or F N i,k = F N i,k 1 + L k F N i,k = RN + L k The two equations above can be combined in a single one: F N i,k = max(f N i,k 1, RN) + L k RN(t) is reset to zero when the system is empty Trafffic Engineering 2015/16 35

36 FQ: Conceptual (simplified) Trafffic Engineering 2015/16 36

37 Weighted Fair Queuing (WFQ) We follow FQ, but conveniently weighted by the relative weight of each queue C RN(t + t) = RN(t) + j active w j t F N i,k = F N i,k 1 + L k w i F N i,k = RN + L k w i F N i,k = max(f N i,k 1, RN) + L k w i qualitative analysis: larger w i, means that L k /w i will be smaller, and therefore F N i,k will also be (realtively) smaller, increasing the possibility of queue i to be selected for packet transmission Trafffic Engineering 2015/16 37

38 WFQ: Conceptual (simplified) Trafffic Engineering 2015/16 38

39 Weighted fair queuing Discussion: features vs limitations? w 1 = 3, w 2 = w 3 = 1 Trafffic Engineering 2015/16 39

40 Scheduling disciplines: classification Work conserving The output channel is always used if there are packets on the queue Non-work conserving The output channel may not be used even if there are packets on the queue, depending on the scheduling discipline Trafffic Engineering 2015/16 40

41 Stop and go In short, on stop and go scheduling each flow can only use a pre-defined reserved amount of bandwidth, irrespective of the to available bandwidth Similar to time multiplexing Computationally simple Provides strict QoS, but makes an inefficient use of the overall channel Trafffic Engineering 2015/16 41

42 Packet drop policy When the system capacity is exceeded, packet drops occur The packet drop policy can be classified in four categories Aggregation level Packet to drop depends on the aggregation level: flow, queue, etc... It may be the last arrived packet or the last packet of the flow Priority Some packets may be marked with increased priority These packet should be protected Early drop Implements a preventive drop when some buffer is almost full Packet position Tail of the queue (default) Head of the queue Queue drop is proportional to channel use Random Fair distribution... Trafffic Engineering 2015/16 42

43 Traffic scheduling on Linux Linux implementation of scheduling disciplines is possibly one of the most obscure topics of Linux :-) Maybe not obscure, but surely complex... Most of the traffic shaping in linux is performed using the tc (traffic control) command We will only describe here some generic features; this does not intend to be a manual For more information, check the TC howto and iprtoute2 howto available from LDP (Linux Documentation Project). Trafffic Engineering 2015/16 43

44 Bandwidth control in Linux Bandwidth control is always performed on the outgoing traffic For example, if one wants to limit the D/L bandwidth from the Internet for a given user: There must be at least a router that receives packets from the internet and distributes them on the LAN side Traffic control shall be applied on the inner interface of the router, on the packets that are being sent over the LAN Trafffic Engineering 2015/16 44

45 Traffic Control command - overview [root@ist]# tc Usage: tc [ OPTIONS ] OBJECT { COMMAND help } where OBJECT := { qdisc class filter } OPTIONS := { -s[tatistics] -d[etails] -r[aw] } Trafffic Engineering 2015/16 45

46 Traffic Control command - variants tc qdisc [ add change replace link ] dev DEV [ parent qdisc-id root ] [ handle qdisc-id ] qdisc [ qdisc specific parameters ] tc class [ add change replace ] dev DEV parent qdisc-id [ classid class-id ] qdisc [ qdisc specific parameters ] tc filter [ add change replace ] dev DEV [ parent qdisc-id root ] protocol protocol prio priority filtertype [ filtertype specific parameters ] flowid flow-id tc [-s -d ] qdisc show [ dev DEV ] tc [-s -d ] class show dev DEV tc filter show dev DEV Trafffic Engineering 2015/16 46

47 Traffic Control command - Example Example [root@ist# tc qdisc add \ A - Add a queuing discipline > dev eth0 \ B - Specify the device > root \ C - means "egress/outgoing" > handle 1:0 \ D - major:minor number, user define > htb E Discipline HTB=Hierarchical Token Bucket Trafffic Engineering 2015/16 47

48 Types of queuing disciplines Classless queuing disciplines Queing disciplines that are applied to all the traffic Classless disciplines apply to all traffic, irrespective of its source Classless disci. accept data and only reschedule, delay or drop it Classful queing disciplines Classfull disciplines apply when there are different kinds of traffic which should have differing treatment Trafffic Engineering 2015/16 48

49 Classless: pfifo fast pfifo fast is a somewhat sophisticated version of the simple FIFO queue Traffic is divided in three bands : 0, 1 and 2 Bands are strictly prioritized: traffic in band 1 is only processed when 0 is empty; the same applies to band 1 and 2 Band classification is based upon the TOS field TOS bits Binary Decimal Meaning Minimize delay (md) Maximize throughput (mt) Maximize reliability (mr) Minimize monetary cost (mmc) Normal Service Note: RFC2474 re-defined the TOS field with DiffServ bits and Congestion Notification... but it is seldom used. Trafffic Engineering 2015/16 49

50 pfifo fast bands TOS Bits Means Linux Priority Band x0 0 Normal Service 0 Best Effort 1 0x2 1 Minimize Monetary Cost 1 Filler 2 0x4 2 Maximize Reliability 0 Best Effort 1 0x6 3 mmc+mr 0 Best Effort 1 0x8 4 Maximize Throughput 2 Bulk 2 0xa 5 mmc+mt 2 Bulk 2 0xc 6 mr+mt 2 Bulk 2 0xe 7 mmc+mr+mt 2 Bulk 2 0x10 8 Minimize Delay 6 Interactive 0 0x12 9 mmc+md 6 Interactive 0 0x14 10 mr+md 6 Interactive 0 0x16 11 mmc+mr+md 6 Interactive 0 0x18 12 mt+md 4 Int. Bulk 1 0x1a 13 mmc+mt+md 4 Int. Bulk 1 0x1c 14 mr+mt+md 4 Int. Bulk 1 0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1 Trafffic Engineering 2015/16 50

51 pfifo scheme Note: priomap is a user defined alternative to default TOS bands; not considered here Trafffic Engineering 2015/16 51

52 Token Bucket Filter (TBF) Adjusts outgoing packet rate to a given administrative set rate implementation consists of a buffer (bucket), constantly filled by some virtual pieces of information called tokens, at a specific rate (token rate) Outgoing packets are sent at a rate defined by the available tokens Trafffic Engineering 2015/16 52

53 TBF diagram Trafffic Engineering 2015/16 53

54 TBF operation The data arrives in TBF at a rate that s equal to the rate of incoming tokens. In this case each incoming packet has its matching token and passes the queue without delay. The data arrives in TBF at a rate that s smaller than the token rate. Only a part of the tokens are deleted at output of each data packet that s sent out the queue, so the tokens accumulate, up to the bucket size. The unused tokens can then be used to send data at a speed that s exceeding the standard token rate, in case short data bursts occur. The data arrives in TBF at a rate bigger than the token rate. This means that the bucket will soon be devoid of tokens, which causes the TBF to throttle itself for a while. This is called an overlimit situation. If packets keep coming in, packets will start to get dropped. Trafffic Engineering 2015/16 54

55 TBF parameters limit or latency Limit is the number of bytes that can be queued waiting for tokens to become available. burst/buffer/maxburst mpu rate Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. The Minimum Packet Unit determines the minimal token usage for a packet. Output rate. Trafffic Engineering 2015/16 55

56 TBF example Limit outgoing traffic on a ppp (serial) interface in order to improve interactive sessions: # tc qdisc add dev ppp0 root tbf rate 220kbit \ latency 50ms burst 1540 Trafffic Engineering 2015/16 56

57 SFQ (Stochastic Fair Queuing Traffic is divided into a large number of FIFO queues, one for each flow. Traffic is then sent in a round robin fashion, giving each flow the chance to send data in turn. Flows are distributed by queues based on hash algorithm In order to avoid bias and improve distribution, the hash is changed regularly, hence the name stochastic Trafffic Engineering 2015/16 57

58 SFQ Diagram Trafffic Engineering 2015/16 58

59 Parameters perturb Reconfigure hashing once this many seconds. Typical: 10 seconds quantum Amount of bytes a stream is allowed to dequeue before the next queue gets a turn. Defaults to 1 maximum sized packet (MTU-sized). limit The total number of packets that will be queued (after that it starts dropping them). Trafffic Engineering 2015/16 59

60 SFQ Example # tc qdisc add dev ppp0 root sfq perturb 10 Trafffic Engineering 2015/16 60

61 When to use each classless Slow down outgoing traffic - TBF Saturated link, one wants to give fair use to ALL sessions - SFQ Limiting incoming traffic (not forwarded): ingress policer (incoming control is called policing, not shaping) Trafffic Engineering 2015/16 61

62 Overview of TC in linux Userspace programs ˆ Y > IP Stack Y Y ˆ / > Forwarding -> ˆ / / Y ˆ Y /-qdisc1-\ Egress /--qdisc2--\ --->->Ingress Classifier ---qdisc > Qdisc \ qdisc4 / \-qdiscn_/ Trafffic Engineering 2015/16 62

63 Classful disciplines When traffic enters a classful qdisc, it needs to be sent to any of the classes within Implies packet classification. Classification is provided by filters, which are consulted Filters are called from within a qdisc, and not the other way around! The filters attached to that qdisc return a decision; qdisc uses this to enqueue the packet into one of the classes. Each subclass may try other filters to see if further instructions apply. If not, the class enqueues the packet to the qdisc it contains. Besides containing other qdiscs, most classful qdiscs also perform shaping. Trafffic Engineering 2015/16 63

64 Qdisc / class hierarchy Each qdisc have classes Each class has a qdisc The handle of a qdisc is always x:0 or x: Each disc or class may have further sub-classes 1: root qdisc 1:1 child class / \ / \ / \ / \ 1:10 1:11 1:12 child classes 11: leaf class 10: 12: qdisc / \ / \ 10:1 10:2 12:1 12:2 leaf classes Trafffic Engineering 2015/16 64

65 Handles As stated before, handles are user defined references in the form major:minor that designate classes and qdisc x: is a shorthand for x:0 The qdisc has always a minor 0 (x:0) Each class has a major equal to his parent Each major must be unique Each interface has one egress/outgoing root qdisc by default, this is a fifo fast qdisc A packet might be classified down the tree or sent directly to the leaf class Both situations can occur: 1 : 0 1 : 1 1 : : 0 12 : 2 1 : 0 12 : 2 Trafffic Engineering 2015/16 65

66 Dequeuing When packets are to be dequeued, the root 1: receives a dequeue request This dequeue request is passed to 1:1, which is in turn passed to 10:, 11: and 12:, each of which queries its siblings, and tries to dequeue() from them. Nested classes only talk to their parent qdiscs, never to an interface Trafffic Engineering 2015/16 66

67 PRIO qdisc Implements strict priority queueing :1 is tried before :2, before :3... PRIO is work conserving Parameters: bands - number of bands priomp - defines relative band priority Trafffic Engineering 2015/16 67

68 Sample PRIO qdisc 1: root qdisc PRIO / \ / \ / \ 1:1 1:2 1:3 classes 10: 20: 30: qdiscs sfq tbf sfq band # tc qdisc add dev eth0 root handle 1: prio ## This *instantly* creates classes 1:1, 1:2, 1:3 # tc qdisc add dev eth0 parent 1:1 handle 10: sfq # tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit \ buffer 1600 limit 3000 # tc qdisc add dev eth0 parent 1:3 handle 30: sfq Trafffic Engineering 2015/16 68

69 CBQ, Class Based Queuing CBQ performs shaping CBQ works by making sure that the link is idle just long enough to bring down the real bandwidth to the configured rate. CBQ also acts like the PRIO queue in the sense that classes can have differing priorities and that lower priority numbers will be polled before the higher priority ones. Trafffic Engineering 2015/16 69

70 HTB Hierarchical Token Bucket CBQ replacement/improvement Hierarchical version of TBF Enables nested versions of TBF Mostly applied to shaping transmitted traffic As in standard TBF, tokens are used to regulate/limit traffic Each class has a rate (guaranteed minimum bw) and a ceil (the maximum rate; more will not be available even if spare capacity is available) Borrowing Children classes borrow tokens from their parents once they have exceeded rate and if there siblings are not using it By other words parent classes may lend spare capacity to child classes When all child classes use more than the minimum guaranteed bandwidth (defined rate), the available excess is divided in proportion to the nominal rate of each one Trafffic Engineering 2015/16 70

71 HTB Borrowing scheme Trafffic Engineering 2015/16 71

72 HTB class parameters rate ceil Used to set the minimum desired speed to which to limit transmitted traffic. This can be considered the guaranteed bandwidth for a given leaf class. Used to set the maximum desired speed to which to limit the transmitted traffic. This can be considered the equivalent of burstable bandwidth. Excess bandwidth results from borrowing burst This is the size of the rate bucket. HTB will dequeue burst bytes before awaiting the arrival of more tokens. cburst This is the size of the ceil bucket. HTB will dequeue cburst bytes before awaiting the arrival of more ctokens. Trafffic Engineering 2015/16 72

73 Example 1: intended shaping, overall tree Trafffic Engineering 2015/16 73

74 Example 1: tc configuration for the previous slide # define root qdisc and default handle for non-classified traffic 1:30 # tc qdisc add dev eth0 root handle 1: htb default 30 # tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit \ ceil 10mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit \ ceil 10mbit burst 15k # tc class add dev eth0 parent 1:1 classid 1:30 htb rate 2mbit\ ceil 10mbit burst 15k # SFQ for beneath these classes is optional, but guarantees # better equity between flows # tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10 # tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10 # tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10 #Add the filters which direct traffic to the right classes: # U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32" # $U32 match ip dport 80 0xffff flowid 1:10 # $U32 match ip sport 25 0xffff flowid 1:20 Trafffic Engineering 2015/16 74

75 Example 2: intended shaping example from devik/qos/htb/manual/userg.htm Problem: We have two customers, A and B, both connected to the internet via eth0. We want to allocate 60 kbps to B and 40 kbps to A. Next we want to subdivide A s bandwidth 30kbps for WWW and 10kbps for everything else. Any unused bandwidth can be used by any class which needs it (in proportion of its allocated share). HTB ensures that the amount of service provided to each class is at least the minimum of the amount it requests and the amount assigned to it. When a class requests less than the amount assigned, the remaining (excess) bandwidth is distributed to other classes which request service. Trafffic Engineering 2015/16 75

76 Example 2: commands Parametrization tc qdisc add dev eth0 root handle 1: htb default 12 tc class add dev eth0 parent 1: classid 1:1 \ htb rate 100kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:10\ htb rate 30kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:11\ htb rate 10kbps ceil 100kbps tc class add dev eth0 parent 1:1 classid 1:12\ htb rate 60kbps ceil 100kbps Classification / filters tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip src match ip dport 80 0xffff flowid 1:10 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip src flowid 1:11 Now we can optionally attach queuing disciplines to the leaf classes. If none is specified the default is pfifo. tc qdisc add dev eth0 parent 1:10 handle 20: pfifo limit 5 tc qdisc add dev eth0 parent 1:11 handle 30: pfifo limit 5 tc qdisc add dev eth0 parent 1:12 handle 40: sfq perturb 10 Trafffic Engineering 2015/16 76

77 Results Trafffic Engineering 2015/16 77

78 More information See htb manual and examples See iproute2 howto A nice and well described example of a complex, but simply explained, HTB application Trafffic Engineering 2015/16 78