Re: [LARTC] SEPARATING VOIP AND SURFING

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Jason Boxman wrote:
> On Monday 15 November 2004 20:06, Ricardo Soria wrote:
> <snip>
> 
>>Dear Andy:
>>
>>Very thanks for your answer.  However, I need a little
>>bit more extended explanation.
>>
>>First, you say that I should "back off more from link
>>speed - total ceils to about 80% and share that
>>between interactive and bulk".  So, do you mean that
>>if I have a total 512Kbit link, and 2 child classes, I
>>should not divide the whole 512kbit between the 2
>>classes, but, I should only divide 410kbit between
>>them, and share the remaining 102kbit between them??
>>Or do you mean I should only consider 410kbit as the
>>whole link capacity??
> 
> 
> I think he meant to treat your link as if it were only 410kbit.  With some 
> testing you can verify just how close to 100% of your advertised capacity you 
> can get, but 80% is often a good place to start.

Yes that's what I meant. For uplink it's to allow for link overheads and 
with dsl you should be careful about tweaking as it may be OK at 90% in 
a test with bulk traffic - all MTU size packets, but if there are lots 
of small packets the overhead miscalculations may mean well over limits 
at 90%. You can fix this, but not perfectly, with a patch Ed Wildgoose 
sent to this list.

Incoming traffic is different - your queue is at the wrong end of the 
link. You have to set a lower limit just to have a queue at all.


> 
> 
>>Second, you say that I should not use SFQ as a
>>sub-qdisc, because of the lenght of the queue, being
>>it ESFQ (new for me) a better choice.  But later, you
>>say I should use SFQ for bulk traffic (I think you
>>refer surfing as "bulk", and voip as "interactive").
>>So, should I use SFQ for bulk classes and ESFQ for
>>interactive classes ??  Or, should I use ESFQ for all
>>leaf classes??  Or, should I use ESFQ for bulk classes
>>and default (pfifo, I think) for interactive classes??

What I meant was you could either change the sfq queue length or use 
esfq, which lets you choose length (and more).

In practise you setup HTB so that your interactive traffic - doesn't 
queue - yes you can attach what ever you like to it's class - and (e)sfq 
would be OK, but if packets actually get queued in it you marking has 
failed and bulk got in or you really have run out of bandwidth.

The point I made was that you shouldn't really send a mix of traffic to 
SFQ which will still cause long delays at low bitrates and your users 
have potentially low rates (depends on what they do).

I would do a bit more work to priorotise dns/empty acks/small tcp etc. 
as well as VOIP, then give them a class with plenty of rate spare and 
make bulk borrow. This would mean that each user would notice a bit less 
the fact they have hardly any bandwidth (if that's the case).

Choosing a queue length should really be related to link speed - but you 
can't do this if you have lots of queues whose rate are variable. What 
to choose depends on typical and I suppose worst case traffic situation 
for your LAN.

Alternatly if you were prepared to patch and use esfq you could use it 
to roughly share traffic by IP address - which is nice to save you 
marking and because you are able to set the queue length for the link. 
You do though, loose fairness per connection which may not affect you - 
again it depends on usage P2P. bittorrent etc.


> 
> 
> I am curious about this myself.  I placed a default sfq qdisc with the 128 
> queue default on a p2p class that had a rate of 144kbit and it routinely 
> spiked to about 150kbit several times a second.  If I use pfifo with a queue 
> length of 10 I find my utilization for that class at around 146kbit instead.  
> Is it the queue length causing this behavior?
> 

I think these differences are too small to be representative. One packet 
could add 12kbit to a counter instantaneously and how you measure can 
decieve. For one really low rate class the way HTB uses DRR to even out 
fairness for different sized packets could, I think cause short term 
variations. P2P traffic is mixed packet size and quite variable 
depending on peers - so recreating behavior for tests may be hard. I 
don't think queue length is involved here.

Andy.

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/