Re: [LARTC] SEPARATING VOIP AND SURFING

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

Jason Boxman wrote:
> On Tuesday 16 November 2004 09:53, Andy Furniss wrote:
> <snip>
> 
>>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).
> 
> 
> Is it really helpful to initially prioritize all TCP handshake packets into 
> the highest priority?

Well it's easy WRT marking :-) the gain can be quite alot for browsing 
and the ones that aren't as important cost practically no bandwidth 
anyway (and I see getting all my TCPs up quickly as better - whatever 
rate/priority the traffic ends up getting allocated).


   After you walk through your list of traffic and
> reclassify flows based on your QoS policy, handshake packets for flows that 
> matter ought to be properly accounted for.  Likewise for flows that aren't 
> that interesting.  For all other flows only having the handshake prioritized 
> and all else going to a default class can't be that beneficial?

I call bulk traffic any that will try to grab bandwidth if left 
unchecked. I don't just send it to a default class, it's shared per IP 
and new connections (marked by connbytes) get their own class which 
gives prio and has a short queue so that packets get dropped quickly and 
slowstart is ended.

> 
>>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.
> 
> 
> I have not noticed in any of the available documentation I have found any 
> discussion on how to choose an appropriate queue length.  The shorter the 
> queue, the sooner applications become aware of a bandwidth bottleneck?  I 
> guess the queue just helps deal with short term busts?  What rate was sfq's 
> 128p queue originally targeted at?  100Mbps Ethernet?

I can't refer you to any docs, but I try to avoid extremes - and having 
20x128 for 512 is an extreme. 3.5 meg x 2 wasted unswappable memory - 
they could absorb about a minutes worth of data at 512kbit.

I would aim for < 1 sec each way, my ISP uses 600ms for 512 - the same 
for 1meg. As I said though, if you have many classes you have to 
compromise or each user's queue will be too short.

128 1500 byte packets will queue 1 sec at about 1.5 mbit - I don't know 
what it was designed for - but if you use alot of them it soon adds up.

> 
> <snip>
> 
>>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.
> 
> 
> The difference for that leaf with sfq versus pfifo was pretty consistent.  I 
> should test with different queue lengths for pfifo.

Maybe there is a difference - If you want to test with different packet 
sizes just set mtu on a linux box start a connection set mtu to 
something different and start another and so on. You will know you are 
comparing like with like then.

I would use sfq for P2P - On the upload side so that 56k users don't get 
squeezed out by broadband, on download so I don't go and drop the one 
and only packet that a 56k peer managed to get to me in recent seconds.

Andy.

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