[LARTC] Re: [PATCH 0/2] NET: Accurate packet scheduling for ATM/ADSL
On Fri, 2006-07-07 at 10:00 +0200, Patrick McHardy wrote: Russell Stuart wrote: Unfortunately you do things in the wrong order for ATM. See: http://mailman.ds9a.nl/pipermail/lartc/2006q1/018314.html for an overview of the problem, and then the attached email for a detailed description of how the current patch addresses it. It is a trivial fix. Actually that was the part I didn't understand, you keep talking (also in that comment in tc_core.c) about an unknown overhead. What is that and why would it be unknown? The mail you attached is quite long, is there an simple example that shows what you mean? The unknown overhead is just the overhead passed to tc using the tc ... overhead xxx option. It is probably what you intended to put into your addend attribute. It is unknown because the kernel currently doesn't use it. It is passed in the tc_ratespec, but is ignored by the kernel as are most fields in there. The easy way to fix the ATM problem described in the big comment is simply to add the overhead to the packet length before doing the RTAB lookup. (Identical comments apply to STAB). If you don't accept this or understand why, then go read the long emails which attempt to explain it in detail. Jesper's initial version of the patch did just that, BTW. However if you do that then you have to adjust RTAB for all cases (not just ATM) to reflect that the kernel is now adding the overhead. Thus the RTAB tc sends to the kernel now changes for different kernel versions, making modern versions of tc incompatible with older kernels, and visa versa. I didn't consider that acceptable. My solution to this to give the kernel the old format RTAB (ie the one that assumed the kernel didn't add the overhead) and a small adjustment. This small adjustment is called cell_align in the ATM patch. You do the same thing with cell_align as the previous solution did with the overhead - ie add it in just before looking up RTAB. This is in effect all the kernel part of the ATM patch does - make the kernel accept the cell_align option, and add it to skb-len before looking up RTAB. The difference between cell_align and overhead is that cell_align is always 0 when there is no packetisation, and even when non zero it is small (less than 1cell_log, ie less than 8 for typical MTU's). So for anything bar ATM it is zero which means old kernels are completely unaffected, and even for ATM not sending it produces a small error which means older kernels still benefit from the ATM user space patch. This makes the proposed ATM version of tc both forward and backward compatible. One other point arises here. The fields in tc_ratespec that tc fills and the kernel ignores are there so tc show will work. The essence of the problem is tc compiles the stuff you give it into a single RTAB. That RTAB can't be reverse compiled into the original numbers the user provided. So if tc show is to work, tc has to save that information somewhere. I don't think the tc_ratespec was the best choice for two reasons. Firstly, having the fields show up in tc_ratespec makes it seem like the kernel can use them. It can't, as the overhead example above shows. Secondly, from tc's point of view it is inflexible. Over time new features have been be added to tc, and each time a new way of encoding it in the existing tc_ratespec has to be invented. Thus we now have hacks like the storing the overhead in the upper bits of the MPU figure. A better solution would be to provide a TLV (ie a TCA_XXX constant) for TC's private use. From the kernels point of view it would be an opaque structure which just saves and echos back when asked. This would solve both problems. However, now you lot have made me go away and think, I have another idea on how to attack this. Perhaps it will be more palatable to you. It would replace RTAB and STAB with a 28 byte structure for most protocol stacks - well all I can think of off the top of my head, anyway. RTAB would have to remain for backwards compatibility, of course. Can you describe in more detail? OK, but first I want to make the point that the only reason I suggest this is to get some sort of ATM patch into the kernel, as the current patch on the table is having a rough time. Alan Cox made the point earlier (if I understood him correctly) that this tabling lookup probably isn't a big win on modern CPU's - we may be better off moving it all into the kernel. Thinking about this, I tried to come up with a way of describing the mapping between skb-len and the on the wire packet length for every protocol I know. This is what I came up with. Assume we have a packet length L, which is to be transported by some protocol. For now we consider one protocol only, ie: TCP, PPP, ATM, Ethernet or whatever. I will generalise it to multiple protocols later. I think a generalised transformation can be made using using 5 numbers which are applied in this order:
[LARTC] Can i attach another qdisc under classes or root qdisc?
thank you so much for your reply, but i doubt about "If I understand your question correctly, the answer is "yes". It ispossible to have nested qdiscs. Note that you can nest qdiscs ifyou are using a classful qdisc [0]. See also my list at the bottomof this message." you mean we can define "nested qdisc" but algorithm in nested qdiscmust same as parent class i'm not clear it andIs we can define nested qdisc with algorithm different from parent class?like this example tc command and At step 4 about your advise" 4. Now, you may attach a brand-new classful or classless qdisc to one of your existing classes. Repeat from step 1 for each new qdisc." tc qdisc add dev eth0 root handle 1: htb//this left node hierachy for manage general packagetc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps//this right node hierachy for manage real time packagetc class add dev eth0 parent 1: classid 1:2 htb rate 100kbps ceil 100kbps// from your adivse at step 4, attach brand-new after define class but Is it true??? because algorithm new qdisc are different from class algorithmthat qdisc attach it.tc qdisc add dev eth0 parent 1:2 classid 10:11 hfsc rate 100kbpstc class add dev eth0 parent 10:11 classid 1:111 hfsc rate 100kbps ceil 100kbpstc class add dev eth0 parent 10:11 classid 1:112 hfsc rate 100kbps ceil 100kbps please adivse me about my assumption, :) and Can somebody advise me about HOW TO do later in this topic.i want to have got traffic shaper and my solotion is ...i want to manage different traffic package (general package use and real time package)so now i think about have got a problem with tc command, ... i think it can't settingto manage different package with different algorithm HTB and HFSCDo you have any idea about how to setting tc command example thank you - Greetings, : now, i'm learning and try to read a lot of article about tc : command in linux for setting traffic shaper. but i'm doubt about : In the theory about tc command ... In general, we define class : under root qdisc but Is it can be possible If we define : another qdisc under root qdisc, Can i do it? because i have just : read tc command syntax and i found this point ...[ snip mangled "tc qdisc help" output ] : from above syntax at [handle][root /ingress/ parent CLASSID] : Is "parent CLASSID" mean we can define qdisc under class so : this is my assumption about that. and Could you advise me about : Is it can do for realIf I understand your question correctly, the answer is "yes". It is possible to have nested qdiscs. Note that you can nest qdiscs if you are using a classful qdisc [0]. See also my list at the bottom of this message. : //first .. define root qdisc : : tc qdisc add dev eth0 root handle 1: fifoBzzzt! Sadly, you can't do this. A fifo qdisc is a classless qdisc, meaning that it cannot have any children. (Poor barren thing!) : //second ... define class under root qdisc but algorithm's not same like rootqdisc algorithm : : tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps : tc class add dev eth0 parent 1: classid 1:2 hfsc rate 100kbps ceil 100kbpsWell, you can't quite mix and match classes without having a parent qdisc of the type you want. An HTB parent qdisc can have any number of children arranged in a tree structure below the parent.Similarly, an HFSC class structure needs to attach to an HFSC qdisc itself. Note, though, you cannot simply change the class name from htb to hfsc and supply the same parameters. HTB uses the rate and ceil parameters, but HFSC uses different parameters (rt, sc and ul). : //later attach qdisc to those classes : : tc qdisc add dev eth0 parent 1:1 classid 10:11 htb rate 100kbps ceil 100kbps : tc qdisc add dev eth0 parent 1:2 classid 10:21 hfsc rate 100kbps ceil 100kbpsOK, now, let's pretend that you have a classful qdisc (e.g. HTB) with two classes, 1:1 and 1:2, AND that you have a good reason for adding a nested qdisc to one of these classes. If that were the case, then you could add the qdiscs to the parent classes in the following fashion: # -- create a new qdisc, attached inside an existing class # hierarchy below class 1:1 # $qdisc_add parent 1:1 handle 10:0 htb # # -- add a class to our newly created qdisc, and set the # rate and ceil parameters # $class_add parent 10:0 classid 10:1 htb rate 100kbps ceil 100kbpsNote, that you'd still need filters.If I were you, I'd review the documentation for both HTB and HFSC after understanding the entire Linux traffic control model. Here's a crash course, starting at the root qdisc: 1. The qdisc can be - classless (e.g., FIFO, SFQ, ESFQ, TBF, GRED) - classful (e.g., HTB, HFSC, CBQ, PRIO) 2. If the qdisc is classful, keep reading. If the root qdisc is classless, stop here. 3. You may add classes to your classful qdisc. If your qdisc is HTB, you can only add HTB
[LARTC] simple TOS based setup vs more complex ones
Hi, After reading section 9 of LARTC it seemed to me that a pure TOS based QoS setup with be sufficient for a small newtork. Interactive packets could have the highest priority, second highest for DNS and small HTTP packets and lowest prio for all others. The advantage is that, the setup would be simply a couple of iptables lines, because the default pfifo_fast qdisc already implements priorities. Questions: For this case, what is the recommended way to limit the outgoing rate to ensure that nothing is queued on the modem? Can this be done with pfifo_fast? Best regards Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] learning iptables
Hi I am currently learning iptables and would like to see the output of shorewall rules in iptables format, as I would like to make a script for the rules instead of using shorewall. Kind Regards William ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] learning iptables
Hello, William, You can take a look at the man page of iptables-save. On Mon, 10 Jul 2006 11:41:53 - William Bohannan [EMAIL PROTECTED] wrote: Hi I am currently learning iptables and would like to see the output of shorewall rules in iptables format, as I would like to make a script for the rules instead of using shorewall. Kind Regards William -- Поздрави, Никола pgpkQ0cGiPbmB.pgp Description: PGP signature ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] simple TOS based setup vs more complex ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gustavo, : After reading section 9 of LARTC it seemed to me that a pure TOS : based QoS setup with be sufficient for a small newtork. : Interactive packets could have the highest priority, second : highest for DNS and small HTTP packets and lowest prio for all : others. : : The advantage is that, the setup would be simply a couple of : iptables lines, because the default pfifo_fast qdisc already : implements priorities. In your proposed system, is still possible for a flood of DNS queries to cause queue depths upstream (and queue depths translate directly to queue backups and delays). : For this case, what is the recommended way to limit the outgoing : rate to ensure that nothing is queued on the modem? The answer depends on what you are trying to do. Consider HTB and/or HFSC. Although you might find that TBF is sufficient, you are already talking about ToS, so TBF probably won't cut the mustard in your situation. : Can this be done with pfifo_fast? Not really. Although, the actual qdisc proposed is different, please see this recent exchange [0] about prio qdisc. If you are using a work-conserving qdisc (i.e., a qdisc that performs no shaping), you'll not really be able to guarantee anything about the quality of traffic from one point to another. In order to offer some sort of guarantees on any link, your device must be the bottleneck. This requires shaping or, at least, some sort of non-work-conserving qdisc. Good luck, - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q2/019130.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019143.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019158.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsryFHEoZD1iZ+YcRAmUAAKDb74IxaBWmCgHA8sd1Sy1SVXS4ZACfYkvD 5NhD00yJMOG5CeFTTFPPk+s= =RmHf -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] simple TOS based setup vs more complex ones
Hi Martin, On Mon, Jul 10, 2006 at 03:45:49PM -0500, Martin A. Brown wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Gustavo, : After reading section 9 of LARTC it seemed to me that a pure TOS : based QoS setup with be sufficient for a small newtork. : Interactive packets could have the highest priority, second : highest for DNS and small HTTP packets and lowest prio for all : others. : : The advantage is that, the setup would be simply a couple of : iptables lines, because the default pfifo_fast qdisc already : implements priorities. In your proposed system, is still possible for a flood of DNS queries to cause queue depths upstream (and queue depths translate directly to queue backups and delays). Sure, but I am talking about a simple setup that works for small networks. In such cases there won't be DNS floods, unless someone really wants to generate one. : For this case, what is the recommended way to limit the outgoing : rate to ensure that nothing is queued on the modem? The answer depends on what you are trying to do. Consider HTB and/or HFSC. Although you might find that TBF is sufficient, you are already talking about ToS, so TBF probably won't cut the mustard in your situation. : Can this be done with pfifo_fast? Not really. So the priorities are useless in real world with pfifo_fast, is that it? This is bit surprising, IIUC. This is why I asked. Although, the actual qdisc proposed is different, please see this recent exchange [0] about prio qdisc. If you are using a work-conserving qdisc (i.e., a qdisc that performs no shaping), you'll not really be able to guarantee anything about the quality of traffic from one point to another. In order to offer some sort of guarantees on any link, your device must be the bottleneck. This requires shaping or, at least, some sort of non-work-conserving qdisc. What I was initially looking for was just TOS marking + plus simple interface throtlling, i.e, the simplest form of shapping. If it can't be done with pfifo_fast, my next idea was something like: tc qdisc add dev eth0 root handle 1: htb default 10 tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps tc class add dev eth0 parent 1:1 classid 1:10 prio + iptables rules for setting TOS values Is this right? This seems to be similar to what you proposed here: http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html For a not so simple approach but which seems to be working well, I have an adaption of Dan Singletary's script here: http://downloads.angulosolido.pt/QoS/ It uses directly HTB on both directions, for a setup with only 2 network interfaces which is very common (no kernel patching is needed). Do you want to comment? Still, I want to test the simplest possible solution and see how far one can go with only a few lines of bash, for both practical and pedagogical purposes. I think it's important to have a simple solution that works for typical scenarios (2 interfaces, linux router with NAT) on stock kernels. ** Best regards Gustavo ** nothing wrong about patching and compiling kernels, but it brings maintenance overhead everytime there is system upgrade for whatever reason -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt Good luck, - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q2/019130.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019143.html http://mailman.ds9a.nl/pipermail/lartc/2006q2/019158.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsryFHEoZD1iZ+YcRAmUAAKDb74IxaBWmCgHA8sd1Sy1SVXS4ZACfYkvD 5NhD00yJMOG5CeFTTFPPk+s= =RmHf -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] simple TOS based setup vs more complex ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gustavo, : Sure, but I am talking about a simple setup that works for small : networks. In such cases there won't be DNS floods, unless someone : really wants to generate one. Well, perhaps you could give it a try in your example network and see how it fares. It might fare very well 90% of the time. If so, then you have an OK solution. : So the priorities are useless in real world with pfifo_fast, is : that it? This is bit surprising, IIUC. This is why I asked. Priorities are useless in the real world on a link that we expect to be congested (e.g. an ADSL link). If the link is not congested, there's no problem with using priorities. The question is not whether priorities are useless, but rather, how often do you expect your link to be congested? : What I was initially looking for was just TOS marking + plus : simple interface throtlling, i.e, the simplest form of shapping. : If it can't be done with pfifo_fast, my next idea was something : like: : : tc qdisc add dev eth0 root handle 1: htb default 10 : tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps : tc class add dev eth0 parent 1:1 classid 1:10 prio : : + : : iptables rules for setting TOS values : : Is this right? This seems to be similar to what you proposed : here: : : http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html Well, indeed, I did post that! While that may solve the problem of the bottleneck, I have to confess, it's not a very good solution either! I'll post a follow-up to that thread shortly. : For a not so simple approach but which seems to be working well, : I have an adaption of Dan Singletary's script here: : : http://downloads.angulosolido.pt/QoS/ : : It uses directly HTB on both directions, for a setup with only 2 : network interfaces which is very common (no kernel patching is : needed). HTB in both directions is probably the best way to go (shaping upload and shaping download). I haven't examined the HTB_shaper.sh assiduously, but from a quick review, it seems quite reasonable (and better than my off the cuff remark in the earlier thread). I'm not crazy about the dropping of the MTU, but otherwise, the script seems to make sense. Basically divide up link capacity into components and limit the total transmission rate to the link capacity (so we are the bottleneck). Then, put some packets in each class. It's so far the best (and most general) solution in this thread. : Still, I want to test the simplest possible solution and see how : far one can go with only a few lines of bash, for both practical : and pedagogical purposes. I think it's important to have a simple : solution that works for typical scenarios (2 interfaces, linux : router with NAT) on stock kernels. ** : : ** nothing wrong about patching and compiling kernels, but it :brings maintenance overhead everytime there is system upgrade :for whatever reason Understood on the kernel patching/compiling business. That's not usually something you want to throw at beginners. Well, if the goal is practical administration and pedagogy, I'd suggest tcng [0], since the beauty of tc is hidden from the user. The language of tcng feels more like a programming language than the arcana of tc. Good luck, - -Martin [0] http://tcng.sourceforge.net/ - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEswsEHEoZD1iZ+YcRAhwGAJkBlygjpO6dfT9s+1/yHq91pSAJCQCg8E2a LRjKTkGjSvQHTLaFReomSlk= =ikoL -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] simple TOS based setup vs more complex ones
Hello again Martin, More comments below: : So the priorities are useless in real world with pfifo_fast, is : that it? This is bit surprising, IIUC. This is why I asked. Priorities are useless in the real world on a link that we expect to be congested (e.g. an ADSL link). If the link is not congested, there's no problem with using priorities. The question is not whether priorities are useless, but rather, how often do you expect your link to be congested? Good point... and the answer is: allways. With the low DSL uploads available a single connection will saturate it - we currently have 20Mbs/400kbps (!) services, for example. : What I was initially looking for was just TOS marking + plus : simple interface throtlling, i.e, the simplest form of shapping. : If it can't be done with pfifo_fast, my next idea was something : like: : :tc qdisc add dev eth0 root handle 1: htb default 10 :tc class add dev eth0 parent 1: classid 1:1 htb rate 7000kbps ceil 7000kbps :tc class add dev eth0 parent 1:1 classid 1:10 prio : :+ : :iptables rules for setting TOS values : : Is this right? This seems to be similar to what you proposed : here: : : http://mailman.ds9a.nl/pipermail/lartc/2006q2/019138.html Well, indeed, I did post that! While that may solve the problem of the bottleneck, I have to confess, it's not a very good solution either! I'll post a follow-up to that thread shortly. Great. Meanwhile, I just finished my first trial on this approach. The result is here: http://downloads.angulosolido.pt/QoS/PRIO_shaper.sh For SSH interactive traffic and Web Browsing while uploading and downloading, seems to work as well as HTB_shaper, it tested on a single machine. Of course there is no fairness on each prio band, so tests with multiple workstations should reveal the advantadges of HTB_shaper. : For a not so simple approach but which seems to be working well, : I have an adaption of Dan Singletary's script here: : : http://downloads.angulosolido.pt/QoS/ : : It uses directly HTB on both directions, for a setup with only 2 : network interfaces which is very common (no kernel patching is : needed). HTB in both directions is probably the best way to go (shaping upload and shaping download). I haven't examined the HTB_shaper.sh assiduously, but from a quick review, it seems quite reasonable (and better than my off the cuff remark in the earlier thread). I'm not crazy about the dropping of the MTU, but otherwise, I found that it was causing problems, so that part is gone. the script seems to make sense. Basically divide up link capacity into components and limit the total transmission rate to the link capacity (so we are the bottleneck). Then, put some packets in each class. It's so far the best (and most general) solution in this thread. : Still, I want to test the simplest possible solution and see how : far one can go with only a few lines of bash, for both practical : and pedagogical purposes. I think it's important to have a simple : solution that works for typical scenarios (2 interfaces, linux : router with NAT) on stock kernels. ** : : ** nothing wrong about patching and compiling kernels, but it :brings maintenance overhead everytime there is system upgrade :for whatever reason Understood on the kernel patching/compiling business. That's not usually something you want to throw at beginners. And I also don't like to throw it at myself, if it's not really necessary. (OT: I wonder, if the kernel team doesn't want to include IMQ, what's their recommended solution for this problem, on a router with more than 2 interfaces) Well, if the goal is practical administration and pedagogy, I'd suggest tcng [0], since the beauty of tc is hidden from the user. The language of tcng feels more like a programming language than the arcana of tc. Thank you for the link. I wasn't aware of this project. Best regards Gustavo -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt Good luck, - -Martin [0] http://tcng.sourceforge.net/ - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEswsEHEoZD1iZ+YcRAhwGAJkBlygjpO6dfT9s+1/yHq91pSAJCQCg8E2a LRjKTkGjSvQHTLaFReomSlk= =ikoL -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: VoIP using just prio qdisc? No. was [ [LARTC] Sanity Check ]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello all, : So, instead of trying to use a prio qdisc alone, try using a : single HTB class to limit your traffic to a given rate and then : embed your prio qdisc inside that. There are many other possible : options for nested qdiscs, and maybe somebody on this list will : make a recommendation to you for how s/he solved this problem. This is a correction/clarification for posterity. There is still a problem with the above, and I'd like to correct it and thank Gustavo Homem [0] for pointing out my possibly misleading advice here. Mike indicated that he was willing to let VoIP traffic out regardless of the cost to other flows. This means that the above solution might work acceptably for his needs in this situation... However, this is not a good general solution! When evaluating a traffic control mechanism for a particular solution, there are a number of different network characteristics that we need to keep in mind. The big three are throughput, delay and jitter. Each traffic control mechanism that we might employ affects at least one (and almost always more than one) of the above network characteristics. Selecting the correct mechanism for a given application depends on what we are willing to trade. Some people are willing to trade total throughput for delay (those of us who like responsive ssh sessions, for example). Some people MUST trade delay and jitter for throughput (VoIP applications). So, to return to the problem of a single PRIO qdisc (a work-conserving queuing discipline), how can we add some sort of non-work-conserving mechanism (shaping) and still take advantage of some prioritization. There are a number of ways to solve this problem, but let's look at the following options (+ = good, - = not-so-good): A. HTB qdisc, one class, with child PRIO qdisc + HTB shapes total dequeued traffic rate to the specified maximum rate. + PRIO qdisc ensures that traffic you classify as high priority always has preferential access to full link bandwidth (as limited by HTB's rate) - high priority flows can completely starve low priority flows B. PRIO qdisc, each class contains a TBF qdisc specifying transmisison rate + each class gets up to its TBF of throughput before it gets shaped. + each class gets is completely isolated from the other classes so if the sum of the rates of the TBF qdiscs does not exceed link bandwidth, you should see predictable delay and jitter - any given class could become backlogged easily and there's no sharing between classes C. HTB qdisc, HTB children classes[, children sfq or fifo qdiscs] + HTB shapes total dequeued traffic rate to the specified maximum rate. + HTB children classes can borrow from parent classes, if some bandwidth goes unused - must write filters to specify which class receives which packets The above is just an outline to point out some of the tradeoffs that need to be examined and understood when choosing a traffic control mechanism for any particular situation. I was probably a bit facile in my answer to Mike, so I hope this post clears up the ambiguity of the recommendation. Good luck and happy QoS! - -Martin [0] http://mailman.ds9a.nl/pipermail/lartc/2006q3/019232.html - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsxDdHEoZD1iZ+YcRAormAJsGkouYrqoM0q8Zgw0aCaXpZTMKkQCfbc+E UruTl/GvAVMHqGRqzUwwc0Q= =Sk64 -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Re: [LARTC] simple TOS based setup vs more complex ones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's a tennis-game on the LARTC list, Gustavo! :) : The question is not : whether priorities are useless, but rather, how often do you expect : your link to be congested? : : Good point... and the answer is: allways. : : With the low DSL uploads available a single connection will : saturate it - we currently have 20Mbs/400kbps (!) services, for : example. Strange ratio--20 to 1, but I don't know a great deal about DSL provisioning. : Meanwhile, I just finished my first trial on this approach. The : result is here: : : http://downloads.angulosolido.pt/QoS/PRIO_shaper.sh : : For SSH interactive traffic and Web Browsing while uploading and : downloading, seems to work as well as HTB_shaper, it tested on a : single machine. : : Of course there is no fairness on each prio band, so tests with : multiple workstations should reveal the advantadges of : HTB_shaper. Well, good luck with it. You could consider following the lartc.org HOWTO on PRIO qdiscs with embedded SFQs [0]. : I'm not crazy about the dropping of the MTU, but otherwise, : : I found that it was causing problems, so that part is gone. While it's not a bad idea from a traffic control perspective, there are so many ramifications of changing the MTU that I don't find it worthwhile. : (OT: I wonder, if the kernel team doesn't want to include IMQ, : what's their recommended solution for this problem, on a router : with more than 2 interfaces) The developers have recently been working on something called ifb, which is intended to be a replacement for IMQ. I don't know too much about it, but there are snippets of documentation about the 'net if you are on good terms with google. - -Martin [0] http://lartc.org/howto/lartc.qdisc.classful.html#AEN903 - -- Martin A. Brown http://linux-ip.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/) iD8DBQFEsxPRHEoZD1iZ+YcRAsmrAJ9TkcLnQ2TpzJCxHtdk2ACHHN/D+QCfcBof 3aOuyJi5+ZWjlq45ES9xjfE= =CpY+ -END PGP SIGNATURE- ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] A multi-isp with priority routing and GRE tunneling network problem.
Hey guys, i have a problem with building a multi-isp gateway using a GNU/Linux box with priority routing enalbed and after all. any ideas what should i do? maybe a step by step intro? thanks in advanced. Deslay ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
[LARTC] re-routing network traffic.
Hello All, The following is what I was trying to do: A packet [Dest: 10.10.10.2, Src: 10.10.10.30] has a route through tunl0. The bigger problem is that tunl0 is a tunnel between 10.10.10.2 and 10.10.10.20... Which means that after encapsulation takes place, the packet would look like [Dest: 10.10.10.2, Src: 10.10.10.20 [Dest: 10.10.10.2, Src: 10.10.10.30]]. Thing to be noted is that the destination of the packet before and after encapsulation is same! This is what I plan to do: 1. Create a route such that all packets to 10.10.10.2 go through tunl0 2. In POSTROUTING, if destination is 10.10.10.2 and the packet is not marked, mark it. 3. Create another route for the packets that are marked. Is this approach the right one, and is it possible to do such a thing - I am specially doubtful about the second step!! Thanks, Prasad ___ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
