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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
