[LARTC] simple TOS based setup vs more complex ones

[Gustavo Homem]

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