On Sun, Jul 30, 2006 at 11:09:04PM +0200, Daniel Musketa wrote: > Hello, > > I just found the great howto and started shaping my internet connection. The > howto's last update is a liitle in the past now so I have some questions > about how things are done the best way nowadays ;-) > > > To ensure a stable and low latency voip communication I added an HFSC qdisc to > device ppp0 (1 Mbit SDSL). There are two classes (by now): One for SIP and > RTP and one for the rest. > > Question 1: I defined the voip qdisc as > > tc class add dev ppp0 parent 1:1 classid 1:11 \ > hfsc sc umax 1500b dmax 30ms rate 500kbit ul rate 900kbit > > but "tc -s class show dev ppp0" shows > > class hfsc 1:11 parent 1:1 sc m1 0bit d 6.0ms m2 500000bit \ > ul m1 0bit d 0us m2 900000bit > > Where does the "0bit d 6.0ms" come from, (what does the other stuff exactly > mean) and what would be a good setting for voip traffic? > > > > > This qdisc only affects outgoing traffic. But I also want to control incoming > packets and keep the isp's queue empty. > > Question 2: What is the best solution for doing this: ingress qdisc, IMQ, ... > (thers's only one link to isp)? > If you don't want to patch the kernel and your machine has only two network interfaces you can shape the outgoing traffic to the internal interface instead of the incoming traffic to the internal interface. I have an example script here: http://downloads.angulosolido.pt/QoS/HTB_shaper_adv.sh It uses HTB for shapping though. > > > Much traffic on this line is UDP traffic (OpenVPN). > > Question 3: If I do policing on incoming traffic, do UDP transmissions care > about dropping and reduce transmit speed? > > I don't think so, unless that is implemented at the application level. The UDP packets shouldn't be dropped unless that's acceptable to a certain extend (VoIP) or the application resends as necessary. > > > If I begin to control incoming traffic I only want to drop packets that are > non voip traffic. > > Question 4: Is it possible to control what packets are dropped? > Depends if you know the ports they use. If you know it, you just have to mark them accordingly. For example with skype it's a pain in the ass, as it seems not to respect the port chosen on the configuration. I solved that by reserving bandwidth per workstation, so that each one get's TOTAL/N, extensible to TOTAL of the others don't request it. For each workstation there is also a priority rank, but for cases like skype, whose ports we can't control, it ends up being up to each user to ensure there's enough bandwidth on her share for skype to work. Take a look at the link I pasted above. > > > I always want to have enough bandwith for incoming voip traffic. But limiting > the other stuff to static 180 kbit only because voip packets could sometimes > reach a maximum of 800 kbit sounds not so good. > Sure! > My idea: A script that periodically (or even better: triggered by asterisk) > controls the parameters for the ingress shaper (depending on the actual > upload traffic produced by voip which could easily be measured with tc). > > Question 5: Is that possible? Is this necessary at all? Is there already a > solution? > I don't think you need this. A setup with HTB solves this problem, since each traffic class has a defined RATE as well as a defined CEIL rate, which it will take whenever available. I can't comment about HFSC as I never used it. Best regards Gustavo > > > Regards > Daniel > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc -- Angulo Sólido - Tecnologias de Informação http://angulosolido.pt _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
