Hi!
I answer to two messages from this thread (I use digest).
lartc-request@xxxxxxxxxxxxxxx wrote:
Message: 3 Date: Fri, 16 Jul 2004 10:51:37 -0700 (PDT) From: ibro tj <ibb_linux@xxxxxxxxx> Subject: Re: QoS for Voip. To: lartc@xxxxxxxxxxxxxxx, alessandro.ren@xxxxxxxxxxxxxxxxx
Hi,
the hint from Martin A Brown which I am experimenting without regret yet is that you shoul decrease the queue lenght to say 30 from the default 100 and also reduce the MTU(MAX. TRANSFER UNIT) to the size of typical voice traffic say 256 using
The MTU is Maximum Transfer Unit, if a package is smaller than the MTU, it will pass just like that. I got very good results doing something like that, but you introduce more header overhead, wich will waste bandwith. And, you can't control the MTO your ISP sends to you (at least not in my case, it would be MRU, I changed it, and nothing happened). The queue lenght will reduce the maximum delay you can get for packages without classification, if you classify them, you don't have to worry about that
ip link set dev eth0 qlen 30 ip link set dev eth0 mtu 1000
Hope it helps.
Ibrahim T.
From: Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Subject: Re: QoS for Voip. Date: Fri, 16 Jul 2004 20:38:40 +0200
Am Friday 16 July 2004 18:54 schrieb Jason Boxman:
But how well does that scale?
Would you want to do per user classifications to give SSH for each user a higher priority if you had, say, 230 users, for example? Or would each user merely need to find for himself with his slice?
I wrote something about having to many users in my mail too. :-)=20 And I made clear that this setup is what I do at home and I do not have=20 (thank god) 230 flatmates. So hopefully there were no=20 misunderstandings. :-)
The interesting question is... are the 230 users all active at the same time. You only need classes for active users. And for that many active users, you need a lot of bandwidth if each of them wants to be doing VoIP and P2P so I don't see *that* many problems there. Of course, I don't have any practical experience there.
You can "put your foot" over the p2p, I'm about to test l7filter, but I'll tell you how it works for me right now:
I have a 900 users network, and about 80% of them are always active, I have VoIP, and, off course, p2p. I also have to route traffic for local net through the same router :-S
I created a default class (30), any traffic that I didn't wanted to give priority went here. And I created others (let me look at the scripts :P ):
My max bandwith is 1024kbps.
10: Standart burst traffic (http,ftp,tftp,pop,imap,https). rate 250kbit ceil 97% of total uplink(downlink) prio 3.
14: Higher prio traffic (VoIP): rate 170kbit ceil 97% of total. prio 1.
15: ACK and these kind (SSH, and other interactive traffic, telnet). rate 170kbit ceil 97% prio 2.
20: Server traffic (we have some servers): rate 200kbit ceil 97% prio 3
30: trash (p2p, anything else): rate 90kbit ceil 70% quantum 1920 prio 4
Off course, due that there are so few classes, the ones that have fewer packets are the ones that behaves better (I think of it like "virtual" links going into a trunk). The VoIp traffic will come from only one IP, in my case, so I filter to class 14 only from this host (a filter with a higher prio than the one that sends ACK/ICMP ping and others to the 15).
I created another similar script for the other eth device (eth0 points to my local net, eth1 points to Internet), after creating the classes, I create LOTS of filters to classify the traffic by sport/dport. Due that u32 isn't statefull, one have to think that you are looking at a package and that you only "see" the header, you only care that the package is passing through and going out of the interface you installed the qdisc. That's why I have to have two scripts, and that's why the computer that is doing the traffic shaping, doesn't uses it on it's whole. I was about to use IMQ, but due that we have a dedicated computer to do the job, I just don't worry.
from the point of view of a big ISP, I'd probably make my own life easier by just providing constant (ceiled) rates, no borrowing. Global prioritization (where theoretically each user can use the whole available bandwidth) has the risk that if a user finds out a special type of traffic is being prioritized, he abuses this. For example, he could use a prioritized protocol to tunnel other stuff through it... think of P2P over VoIP. If VoIP is allowed to use all the bandwith, such a user could steal way too many bandwidth from others. The only way to prevent this sort of thing would then be to make no global prioritizations, but give each user his own sandbox (which is more or less the idea behind my home setup).
Depending on the bandwidth your clients get, you don't have to do things like prioritizing SSH and VoIP for them... my ISP doesn't do that for me either, at least not on such a close level. And I doubt I would like my ISP to decide for me which traffic to prioritize for me. I just do this kind of stuff on my own home machine.
I hope it makes sense in a way :-0 It was a rather hasty rant, sorry
Andreas
--__--__--
Hope this helped,
Ildefonso Camargo icamargo@xxxxxxxxxxx _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
