Differences

This shows you the differences between two versions of the page.

doc:howto:packet.scheduler:packet.scheduler.theory [2012/11/17 07:00]
uvray313
doc:howto:packet.scheduler:packet.scheduler.theory [2013/08/10 12:22] (current)
lorema
Line 1: Line 1:
-====== Packet Scheduling ======+===== Linux Packet Scheduling =====
 +  * Packet Scheduler, Queueing Discipline(QDisc),  queueing algorithm and packet scheduler algorithm are all names for the same thing. Usually contained in distinct kernel modules, one of multiple schedulers can be loaded into the kernel and utilized to make scheduling decisions.
 +  * The packet scheduler is integral to the network parts of the Kernel - embedded in the network stack and the network driver. You can find the source code in: [[http://lxr.free-electrons.com/source/net/sched/|net/sched]]
 +  * The packet scheduler is configured with the program ''tc''.
-  * "Queueing Discipline(QDisc)" = "queueing algorithm" = "packet scheduler algorithm". Usually contained in distinct kernel modules, one of multiple schedulers can be loaded into the kernel and utilized to make the scheduling decisions. 
-  * The packet scheduler is integral to the network parts of the Kernel - embedded in the network stack and the network driver. You can find its source code in: [[http://lxr.free-electrons.com/source/net/sched/|net/sched]] 
-  * The packet scheduler contains //classifiers//: ''cls_*'',  //extended matches// ''ematch_*'', //schedulers// ''sched_*'' and //packet actions// ''act_*'' and is configured with the user space tool ''tc''. 
-===== Theory =====+  * http://lca2013.linux.org.au/schedule/30118/view_talk 
 +    * [[http://www.youtube.com/watch?v=y5KPryOHwk8|Video: lca2013 Bufferbloat from a Plumber's point of view 41min]] ([[http://r1---sn-35cxacf-935e.c.youtube.com/videoplayback?title=%5BLinux.conf.au%202013%5D%20-%20Bufferbloat%20from%20a%20Plumber%27s%20point%20of%20view&itag=44&mv=m&ipbits=8&fexp=916602%2C902903%2C919318%2C935800%2C932304%2C909546%2C906397%2C929117%2C929121%2C929906%2C929907%2C929127%2C929129%2C929131%2C929930%2C925720%2C925722%2C925718%2C925714%2C929917%2C929919%2C912521%2C932306%2C904830%2C919373%2C904122%2C929609%2C911423%2C909549%2C935006%2C900816%2C912711%2C935802%2C904494%2C906001&ms=au&sver=3&cp=U0hWS1FQUl9FTkNONl9JSlZIOjAtaFg4NkJmSldF&ip=37.209.1.176&upn=-gFRS1tnMuA&mt=1376129826&sparams=cp%2Cid%2Cip%2Cipbits%2Citag%2Cratebypass%2Csource%2Cupn%2Cexpire&ratebypass=yes&expire=1376154704&key=yt1&source=youtube&id=cb928faf2387c24f&signature=67DE7167FCEF80A35CA7E3CFEC4C7506A11E05A0.936390E1B9B03E6D46EB5F8C61F03111FF343675|Download link]]) 
 +  * http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos
-This document outlines what the terms "traffic control", "traffic shaping", "Quality of Service (QoS)", "Type of Service (ToS)" mean. QoS may be the single most important feature of a router. It the basis for //bandwidth management// and accurate //packet prioritization//. 
==== Packets ==== ==== Packets ====
Line 16: Line 17:
These chunks are more commonly referred to as packets, so network communication is packet-based. These chunks are more commonly referred to as packets, so network communication is packet-based.
-These packets begin their lives as data on a computing device that needs to get from where it presently resides to another device somewhere on the local area network or internet. +These packets begin their lives as data on a computing device that needs to get from where it presently resides to another device somewhere on the local area network or a different network.
-This data first needs to be broken into packets. Then a header and sometimes a footer are added with delivery instructions and other information relevant to the packet and its contents. This process is repeated each time the packet traverses an application or device that uses a different format for handling packets.+This data is first broken into packets. Then a header and sometimes a footer are added with delivery instructions and other information. This process is repeated each time the packet traverses an application or device that uses a different format for handling packets.
-The opposite takes place as the packet nears its destination. The various headers and footers are removed and the data reaches the end of it's journey as it began - the same chunk of data we started with.  When combined with all the other chunks, in the correct order, we end up with the same data we started with only that data is in a new location. A [[http://www.tcpipguide.com/free/t_UnderstandingTheOSIReferenceModelAnAnalogy.htm|real world analogy]].+The opposite takes place as the packet nears its destination. The various headers and footers are removed and the packet reaches the end of it's journey as it began - the same chunk of data we started with.  When combined with all the other chunks, in the correct order, we end up with the same data we started with only that data is in a new location. A [[http://www.tcpipguide.com/free/t_UnderstandingTheOSIReferenceModelAnAnalogy.htm|real world analogy]].
-What we are concerned with when using QoS is ensuring this data gets to it's destination in a timely fashion and that it's journey is not delayed unnecessarily by lower priority data.  While we don't have much control of what happens to packets outside of our own network, there are QoS options available that allow us to control and prioritize packets within our local area network, at each interface and particularly as the traffic passes leaves the router on its way to another network, usually the Internet.+We use QoS to ensure packets get to their destination in a timely fashion and that they are not delayed by lower priority traffic.  While we don't have much control of what happens to packets outside of our own network, there are QoS options that allow us to drop or reorder packets at each of our own network interfaces.  The most important of these is usually the WAN port of our router.
-Why the router?+Why?
-Well, the router is where faster LAN traffic, often coming from multiple sources, queues up waiting to be transported to the internet over a lower capacity connection. The same as traffic backs up on a busy freeway when multiple lanes merge into one, packets are backed up in the interface queue waiting for their turn to pass through the bottleneck.+Well, this where LAN traffic converges to be transferred to another network, often over a lower capacity connection. Similar to the way traffic backs up on a busy freeway when multiple lanes merge into one, packets are either dropped or backed up in the interface queue waiting for their turn to pass through the bottleneck.
-==== Queues ====+In fact unless there is traffic congestion there is no need for QoS.  By itself QoS does not increase bandwidth or make packets travel faster.  It queues, or drops packets in cases where there is less bandwidth available than needed. We could also eliminate the congestion by increasing the bandwidth of the connection, but this is not always possible or practical. 
 + 
 +==== Network Interfaces ==== 
 + 
 +Network interfaces can drop, forward, queue, delay and re-order packets. 
 + 
 +=== Queues ===
Every network interface has two queues, also referred to as a buffers, where packets reside briefly before being transmitted.  The queue for incoming packets is called the **ingress queue**. The queue for outgoing packets is called the **egress queue**. Every network interface has two queues, also referred to as a buffers, where packets reside briefly before being transmitted.  The queue for incoming packets is called the **ingress queue**. The queue for outgoing packets is called the **egress queue**.
-=== Egress Queue ====+== Egress Queue ==
Let us look at the **egress queue** of a typical [[doc:networking:network.interfaces|network interface]]. Let us look at the **egress queue** of a typical [[doc:networking:network.interfaces|network interface]].
-We can determine the size of the queue using the ''ifconfig'' command and referring to the number following ''txqueuelen:'' in the response+We can determine and change the size of the queue using the ''ifconfig'' command. The ''txqueuelen:'' in the response indicates the capacity of the queue.
- +
-This is the capacity of the buffer. +
Queue capacity is not measured in bytes or bits as you might expect, but by the number of packets it can hold. When the queue is full, any further incoming packets will "overflow".  They are dropped and never reach the intended recipient. Queue capacity is not measured in bytes or bits as you might expect, but by the number of packets it can hold. When the queue is full, any further incoming packets will "overflow".  They are dropped and never reach the intended recipient.
-QoS is not necessary with Linux as it is already active by default. The kernel can manipulate both queues. It identifies packets by looking at their header or content.+Activating QoS is not necessary with Linux as it is already active by default. The standard packet scheduler that manages egress queues in Linux, is "pfifo_fast", which means "prioritized first in first out". It is based on the QoS/TOS flags in the packet headers.
-The standard packet scheduler that manages egress queues in Linux, is "pfifo_fast", which means "prioritized first in first out". It is active by default and it is based on the QoS/TOS flags in the packet headers.+Network interfaces are serial devices.  Packets leave the queue one a time, and are transmitted one after the other, single file. The task of the scheduler is to decide which packet leaves next. It does this by ordering the packets according to an algorithm and its configuration.  In the case of "pfifo_fast", the first packet to the enter the buffer is the first to leave.
-Network interface are serial devices.  Packets leave the queue one a time, and are transmitted one after the other, single file. The task of the scheduler is to decide which packet leaves next. It does this by ordering the packets according to an algorithm and its configuration.  In the case of FIFO, the first packet to the enter the buffer is the first to leave.+== Ingress Queue ==
-Now that you have a basic understanding of packet-based communication, you only have to learn a bit about ''tc'' and the version of the packet scheduler you are going to use.+Unlike the egress queue, the ingress queue has limited control over the packets it receives.  Other than forwarding packets as they are received it's only other capability is to drop packets.  This can be used to advantage though with the TCP protocol which uses flow and congestion control. Dropping TCP "ACK" packets will imply congestion to the transmission source which will reduce it's transmission rate.  There is no similar mechanism available for UDP packets however.
-=== Ingress Queue === 
-Unlike the egress buffer, the ingress queue has limited no control over the packets it receives.  Other than forwarding packets as they are received it's only other capability is to drop packets.  This can be used to advantage though with TCP traffic which uses flow and congestion control. 
-==== Buckets ====+==== Putting it all together ====
-Network interface queues can be partitioned into smaller, virtual queues referred to as "buckets" with the following properties: +A basic QoS setup.
- +
-  * A bucket can contain a packet or a representation of a packet. +
- +
-  * Together buckets can never contain more packets than the size of the egress queue. +
- +
-  * You give the buckets a priority. +
- +
-  * Buckets can overflow, meaning that additional packets will be dropped.  +
- +
-==== Putting it all together ==== +
-Below is a nice ASCII art diagram to illustrate the fact that the entire QoS problem is nothing but the reordering of IP packets before transmission. We want to prioritize packets on Line_X can only reorder packets outgoing:+
<code> <code>
-                                                                          ____ +                                                              ____ 
-User1==============\                                                 ___(    )__ +User1==============\                                       ___(    )__ 
-        Line_A    \                                               _(          )_ +        Line_A    \                                   _(          )_ 
-User2===============[ROUTER]·············[provider_modem]≡≡≡≡≡≡≡≡≡≡(_  Internet  __) +User2===============[ROUTER]·············[ISP]≡≡≡≡≡≡≡≡≡≡(_  Internet  __) 
-        Line_B    /          Line_X                     Line_Z  (_        __) +        Line_B    /          Line_X           Line_Z  (_        __) 
-User3==============/                                                 (______)+User3==============/                                       (______)
        Line_C         Line_C
Line 82: Line 74:
Line_Z 10 Gigabit fiber Line_Z 10 Gigabit fiber
-We wish to implement QoS on our [ROUTER].+We implement QoS at the [ROUTER] WAN interface.
--->-->--[egress]-->-->--[interface output]-->-->--Internet +-->-->--[egress queue]-->-->--[interface output]-->-->--Internet 
-         \    / +           \    / 
-         \  / +           \  / 
-         QDisc  +           QDisc 
-1. Drop packets that exceed configured bandwidth (regardless of priority) +1. Drop packets exceeding available bandwidth. 
-2. Reorder all packets currently in the buffer +2. Reorder packets currently in the buffer.
--->-->--[ingress]-->--[bridge check]-->-->--intranet +-->-->--[ingress queue]-->--[bridge check]-->-->--intranet 
-         \    / +           \    / 
-         \  / +             \  / 
-         QDisc  +             QDisc 
1. Drop packets that exceed configured bandwidth ("policing") 1. Drop packets that exceed configured bandwidth ("policing")
Line 103: Line 95:
</code> </code>
-Outgoing packets enter the egress queue, are reordered and then handed off to the output interface.+  * We limit outgoing traffic to a rate slightly below the capacity of the outgoing connection.  This moves the traffic bottleneck upstream to the router where we can control congestion instead of downstream where we cannot.
-<code> +  * We drop incoming packets that exceed bandwidth. TCP recognizes this as a sign of traffic congestion and reduces the transmission rate at the source.
-ifconfig pppoe-dsl txqueuelen 100 +
-</code> +
- +
-There already are buffers in the devices in which the packets get congested, if more comes in then can get out. The basic idea is to limit the traffic that can get in to a rate that is slightly smaller than the rate of the outgoing line. That way, no congestion can occur. It is important to note that no matter how wide the connection, **we only can send one packet at a time**. +
-At this point we apply the second idea, the reordering of packet transmission. Below are some resources for packet reordering.+Below are some articles about packet reordering.
-  * [[http://linux.die.net/man/8/tc| manpage for userspace application tc]] +  * [[http://linux.die.net/man/8/tc| tc command manual]] 
-  * [[http://lartc.org/howto/index.html | Linux Advanced Routing & Traffic Control HOWTO]]+  * [[http://lartc.org/howto/index.html | Linux Advanced Routing & Traffic Control HowTo]]
    * [[http://lartc.org/howto/lartc.qdisc.html| 9. Queueing Disciplines for Bandwidth Management]]     * [[http://lartc.org/howto/lartc.qdisc.html| 9. Queueing Disciplines for Bandwidth Management]]
    * [[http://lartc.org/howto/lartc.netfilter.html| 11. Netfilter & iproute - marking packets]]     * [[http://lartc.org/howto/lartc.netfilter.html| 11. Netfilter & iproute - marking packets]]
Line 122: Line 110:
-===== OpenWrt packages ===== 
-As of fall 2010 there are at least three QoS/Traffic Shaping packages available for OpenWrt: ''qos-scripts'', ''dsl-qos-queue'' and ''wshaper''.  
-DO NOT install them at the same time.  
- 
-Take a closer look on how to configure them, and if the results satisfy you, you're done. If not, this page should provide the help you need to set up your own implementation of a traffic shaping/link-sharing/qos solution. 
- 
- 
- 
-===== Step by step ===== 
-==== QoS Options ==== 
-Depending of what you want to achieve, there are differing setups. Chose the easiest one. 
- 
-  * A single user wants to use VoIP and do large ftp uploads at the same time.  
-    * You want guaranteed real-time and adaptive best-effort. Try some quick and simple classless QDisc, and mind the filters. Do not bother with htb/hfsc. 
-  * Several PCs are sharing the same line. They all do ftp-uploads only and you want to fairly distribute the available bandwidth among them.  
-    * You want hierarchical link-sharing services. Set up a single QDisc with HTB and configure the rates. Don't bother with real QoS and latency. 
-  - Many users doing all sorts of things. You want guaranteed real-time, adaptive best-effort and hierarchical link-sharing services at the same time. DO NOT bother with this, if you are alone! 
- 
-==== tc (traffic control) ==== 
-<code> 
-$ tc -help 
-Usage: tc [ OPTIONS ] OBJECT { COMMAND | help } 
-      tc [-force] -batch filename 
-where  OBJECT := { qdisc | class | filter | action | monitor } 
-      OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -p[retty] | -b[atch] [filename] } 
-</code> 
- 
- 
-===== Linux/TC Terminology ===== 
-==== Queueing Discipline (QDisc) ==== 
-An algorithm that manages the queue of a device, either incoming (ingress) or outgoing (egress). 
- 
-==== root QDisc ==== 
-The qdisc attached to the device. 
- 
-==== Classless QDisc ==== 
-A QDisc with no configurable internal subdivisions.  
- 
-==== Classful QDisc ==== 
-Contains multiple classes. Some of these classes contains a further QDisc, which may again be classful, but need not be. According to the strict definition, pfifo_fast *is* classful, because it contains three bands which are, in fact, classes. However, from the user's configuration perspective, it is classless as the classes can't be touched with the tc tool.  
- 
-==== Classes ==== 
-A classful qdisc may have many classes, each of which is internal to the qdisc. A class, in turn, may have several classes added to it. So a class can have a QDisc as parent or an other class. This class has 1 QDisc attached to it. This QDisc is responsible to send the data from that class. When you create a class, a fifo QDisc is attached to it. When you add a child class, this QDisc is removed. For a leaf class, this fifo QDisc can be replaced with an other more suitable QDisc. You can even replace this fifo QDisc with a classful QDisc so you can add extra classes. 
- 
-==== Leaf Class ==== 
-This is a class without any child classes. 
- 
-==== Classifier ==== 
-Each classful QDisc needs to determine to which class it needs to send a packet. This is done using the classifier. 
- 
-==== Filter ==== 
-Classification can be performed using filters. A filter contains a number of conditions which if matched, make the filter match. 
- 
-==== Scheduling ==== 
-A QDisc may, with the help of a classifier, decide that some packets need to leave earlier than others. This process is called Scheduling, and is performed for example by the pfifo_fast QDisc mentioned earlier. 
- 
-==== Shaping ==== 
-The process of delaying packets before they go out to make traffic confirm to a configured maximum rate. Shaping is performed on egress. Colloquially, dropping packets to slow traffic down is also often called Shaping. 
- 
-==== Policing ==== 
-Delaying or dropping packets in order to make traffic stay below a configured bandwidth. In Linux, policing can only drop a packet and not delay it - there is no 'ingress queue'. 
- 
-==== Work-Conserving ==== 
-A work-conserving qdisc always delivers a packet if one is available. In other words, it never delays a packet if the network adaptor is ready to send one (in the case of an egress qdisc). 
- 
-==== Non-Work-Conserving ==== 
-Some queues, like the Token Bucket Filter, may need to hold on to a packet for a certain time in order to limit the bandwidth. This means that they sometimes refuse to pass a packet, even though they have one available. 
- 
-**''Rules:''** 
-  * qdiscs and classes:  classles qdiscs vs. classful qdiscs 
-    * a qdisc can bla bla 
-    * a class can never bla bla 
-  * nesting: 
-    * a qdisc can inherit to its children 
-    * a class cannot ... 
-  * interfaces: 
-    * you should configure the packet scheduler for each interface in its own script file, see [[#Hotplug]] 
-    * the most important parameter of a network interface is its tx-queuelen! the txqueuelen can be viewed with ''[[man>ifconfig]]''. Set it with <code>ifconfig pppoe-dsl txqueuelen 100</code> 
- 
- 
-In this guide following is appropriate: 
- 
-  * child class = a class that has another class or a QDisc as parent and has other classes nested. 
-  * leaf class = an end class, always has a QDisc attached to it! In case you not configure one, the default is taken! \\ 
-To understand the differences between a QDisc and a class, see [[packet.scheduler.example1|theoretical background]]. The differences exist to allow for a finer granulated configuration. 
- 
- 
- 
-=== Class === 
-Why do we need classes at all? Why not simply use QDiscs and be done with it? As you will see, the difference between classes and QDiscs is not obvious. Classes were created in order to be able to configure the "traffic shaping" further. Classes are attached to QDiscs. They can have their own sub-classes which are then called leaf-classes. Inner classes, are classes which contain leaf-classes. Non inner classes, always get a QDiscs attached to them. The default is the pfifo_fast QDisc. Classes do, what QDiscs aren't supposed to do: 
-  * leaf-classes give unused bandwidth back to their parent class 
-  * parent classes can dynamically inherit bandwidth to leaf-classes 
-  * classes do not have their own buffer, thus do not store anything 
-  * classes do not contain any network packets 
-  * classes cannot have filters attached to them 
-A class is like sub-qdisc, it belongs to a QDisc. Further classes are called //**leaf classes**//. Sometimes classes are called bands. 
- 
-=== Filter === 
-A filter is used by a classfull QDisc to determine to which class a packet will be enqueued. 
- 
- 
-===== Implementation of classfull with 2 levels ===== 
- 
-:!: The attentive Reader will notice that we actually have three levels and not two. But since level_0 (class 1:1) is only there because it is needed to actually be able to share excess bandwidth between the leaf-classes, I do not count it. If you were to implement this example (Four Users with prioritization) without Level0, each user would have his guaranteed quota, but unused quota would not be allotted amongst the other three users. 
- 
-Directly in the theory stage, we will notice, that we have two possibilities of implementing this: 
- 
-=== Implementation 1 === 
-First the bandwidth sharing, then the prioritization. Remember level_0 (class 1:1) is only for being able to share unused bandwidth. Each user gets a class on level_1 (class 1:10, class 1:20, class 1:30 and class 1:40) which itself contains three leaf-classes for the prioritization. 
-<code> 
-root 1:0 -- class 1:1 (100%) --+--> User_Alan (25%) 
-                              |              +--> High Prio (10%) 
-                              |              +--> Normal Prio (10%) 
-                              |              +--> Low Prio (5%) 
-                              | 
-                              +--> User_Brad (25%) 
-                              |              +--> High Prio 
-                              |              +--> Normal Prio 
-                              |              +--> Low Prio 
-                              | 
-                              +--> User_Carl (25%) 
-                              |              +--> High Prio 
-                              |              +--> Normal Prio 
-                              |              +--> Low Prio 
-                              | 
-                              +--> User_Dave (25%) 
-                                              +--> High Prio 
-                                              +--> Normal Prio 
-                                              +--> Low Prio 
-</code> 
-Advantages: In this Scenario a user would not gain any advantage by filtering all packets into the High_Prio band. 
- 
-=== Implementation 2 === 
-First the prioritization, then bandwidth sharing. Remember level_0 (class 1:1) is only for being able to share unused quota. Each traffic priority gets a class on level_1 (class 1:10, class 1:20 and class 1:30). Then on level_2 each of the users gets a sub-class for each priority class (class 1:101 to 1:104, 1:201 to 1:204 and 1:301 to 1:304). 
-<code> 
-root 1:0 -- class 1:1 (100%) --+--> High Prio (40%) 
-                              |              +--> User_Alan (10%) 
-                              |              +--> User_Brad (10%) 
-                              |              +--> User_Carl (10%) 
-                              |              +--> User_Dave (10%) 
-                              | 
-                              +--> Normal Prio (40%) 
-                              |              +--> User_Alan (10%) 
-                              |              +--> User_Brad (10%) 
-                              |              +--> User_Carl (10%) 
-                              |              +--> User_Dave (10%) 
-                              | 
-                              +--> Low Prio (20%) 
-                                              +--> User_Alan (5%) 
-                                              +--> User_Brad (5%) 
-                                              +--> User_Carl (5%) 
-                                              +--> User_Dave (5%) 
-</code> 
-Advantages: 
-  * this partitioning could make it easier for the QDisc to maintain low delay. Whether or not is dependent on the QDisc. But testing is needed. 
-Disadvantages: 
-  * a user would gain an advantage by filtering all packets, even bulk traffic, into the High_Prio band. 
-  * cannot be implemented with HFSC. With HFSC rt-Service Curves are not allowed in inner classes! 
- 
-=== Implementation 3 === 
-Instead of using Classes only, we nest QDiscs: 
- 
-<code> 
-root 1:0 -- class 1:1 (100%) --+--> High Prio (10%) ----> PFIFO 
-                              | 
-                              +--> High Prio (10%) ----> SFQ 
-                              | 
-                              +--> High Prio (40%) ----> TBF 
-                              | 
-                              +--> High Prio (40%) ----> HTB --+ 
-                                                                |--> User_Alan (10%) 
-                                                                |--> User_Brad (10%) 
-                                                                |--> User_Carl (10%) 
-                                                                |--> User_Dave (10%) 
- 
-</code> 
- 
- 
- 
----- 
-Here is a short example, this configuration would not allow the classes 1:10 and 1:20 to share bandwidth between each other. This is because root classes (any class with = parent 1:) cannot borrow from each other (you will have to accept that, this is the way things work): 
-<code> 
-tc qdisc add dev pppoe-dsl root handle 1: hfsc default 10 
-tc class add dev pppoe-dsl parent 1: classid 1:10 hfsc ls rate 750kbit ul rate 1000kbit #-- 75% 
-tc class add dev pppoe-dsl parent 1: classid 1:20 hfsc ls rate 250kbit ul rate 1000kbit #-- 25% 
-</code> 
- 
-Here is another example that actually does //not work//: 
-<code> 
-tc qdisc add dev pppoe-dsl root handle 1: hfsc default 10 
-tc class add dev pppoe-dsl parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit 
-tc class add dev pppoe-dsl parent 1:1 classid 1:10 hfsc ls rate 750kbit ul rate 1000kbit 
-tc class add dev pppoe-dsl parent 1:1 classid 1:20 hfsc ls rate 250kbit ul rate 1000kbit 
-tc class add dev pppoe-dsl parent 1:10 classid 10:101 hfsc ls rate 250kbit ul rate 1000kbit 
-</code> 
-The classid //must not// be 10:101 in this example. If you make such a mistake, your config won't work, and ''tc'' in contrary to ''iptables'' gives lousy error messages. To avoid a long search for the mistake, write only short parts of the script and test. 
----- 
-A very basic classfull set up could look like this: 
-<code> 
-insmod sch_hfsc 
-tc qdisc add dev pppoe-dsl root handle 1: hfsc default 20 
-tc class add dev pppoe-dsl parent 1: classid 1:1 hfsc sc rate 1000kbit ul rate 1000kbit 
-tc class add dev pppoe-dsl parent 1:1 classid 1:10 hfsc ls rate 750kbit ul rate 1000kbit #-- 75% 
-tc class add dev pppoe-dsl parent 1:1 classid 1:20 hfsc ls rate 250kbit ul rate 1000kbit #-- 25% 
-</code> 
-The first line sets up a new QDisc for the device pppoe-dsl. By default this command will replace the old qdisc. The second line defines a class, note that classes have a classid instead of a handle, as child of the QDisc. The third and forth lines define further classes as leaf classes of classid 1:1. Have a look at [[packet.scheduler.example1|theoretical background]] for further understanding. You can nest classes and QDiscs, and all have different behavior. Just keep in mind, that you configure the buffer for all the outgoing packets on one interface, and all of this is to decide the order (or just the rate) in which packets are sent. 
----- 
-==== Sorts of traffic ==== 
-Basicaly there are only two types of traffic: real-time and best-effort. The first, wants it packets to arive with as steady and little delay as possible. Usually it does not need much bandwith. The latter doesn't mind any delay, but want to utilize as much bandwidth as possible. Before QoS, you either had to stop your upload in order to have a chat over VoIP, or to at least strongly cut the upload rate. Basically you squander your available bandwidth. 
-  - real-time: VoIP, Games, Chat, Consoles (telnet, ssh, X) 
-  - adaptive best-effort: http, ftp, torrent, mail, samba 
-  - hierarchical link-sharing: the point here is only to guarantee, that every user/customer gets a minmum % of the conjointly used (and paid for) bandwidth. 
-==== In theory ... the scheduler ==== 
-Have a look at the different queueing discipline algorithms (or "packet schedulers") available, pick the one that suits your needs best, and bear in mind that you can nest them. Actually you don't nest the schedulers (Qdiscs) but you nest classes and apply different algorithms to each. Although you could nest a clas to a Qdisc attached to a Class. 
-==== In theory ... the filter ==== 
-Each QDisc has it's own list of filters, which is consulted during the enqueueing to classify the packets. Look at the graphics to know when this exactly takes place. 
-Now you need to concern yourself with _ALL_ the packets passing your router and how to prioritize them. The simplest solution is to rely on the QoS. 
-As seen in [[http://lartc.org/howto/lartc.adv-filter.html|LARTC Chapter 12]], ''tc filter'' has quite some capabilities. You could of course also use ''iptables'' to match any sort of packet (even apply [[http://l7-filter.sourceforge.net/|Layer 7 filters]]) and mark it. ''tc filter'' can then classify the packet depending of it's mark. 
-===== Virtual LAN ===== 
-On most devices running OpenWrt there is only one NIC. We simulate two, in conjunction with the subdivision of the build-in switch. But what exactly happens? 
-eth0.1 --- eth0 ---> eth0.2 
-one real buffer, and two virtual buffers. Then again, you spawn pppoe-dsl to eth0.2. There is another buffer. 

Back to top

doc/howto/packet.scheduler/packet.scheduler.theory.1353132053.txt.bz2 · Last modified: 2012/11/17 07:00 by uvray313