[LARTC] Re: QoS for Voip.

[LARTC] Re: QoS for Voip.

[José Ildefonso Camargo Tolosa]

Hi!

I answer to two messages from this thread (I use digest).

lartc-request@mailman.ds9a.nl wrote:
> 
> Message: 3
> Date: Fri, 16 Jul 2004 10:51:37 -0700 (PDT)
> From: ibro tj <ibb_linux@yahoo.com>
> Subject: Re: [LARTC] QoS for Voip.
> To: lartc@mailman.ds9a.nl, alessandro.ren@opservices.com.br
> 
> 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@metamorpher.de>
> To: lartc@mailman.ds9a.nl
> Subject: Re: [LARTC] 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. :-) 
> And I made clear that this setup is what I do at home and I do not have 
> (thank god) 230 flatmates. So hopefully there were no 
> 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@unet.edu.ve
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/