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
-----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-----
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-----
-----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-----
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-----
-----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-----