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
