[adsl-qos] Re: Bandwidth Management HOWTO Errors

[Mike Perry]

Thus spake Andy Furniss (andy.furniss at dsl.pipex.com):

> Mike Perry wrote:
> It's not me - So I won't comment on the detail (ie. I haven't read it 
> for a while :-) ). There are other HowTos though, mainly the LARTC at 
> http://lartc.org there is also a LARTC mailing list - normally several 
> posts/day (but it seems to be broken since friday).

Hrmm.. THis seems to be more of a shotgun approach to documenting all
routing options. Though I suppose its section on NAT would be what I
want to modify, it's unlikely to be found by people looking to just do
load balancing. This ASDL shaping howto far outranks it for those
types of google queries. It would be nice to fix it.

> >Also, the queue size for outgoing traffic should be set at your
> >bandwith-delay product, which is the optimal balance such that TCP
> >backoff does not hamper throughput, and such that the queue does not
> >introduce needless latency. This should also be documented.
> 
> Maybe, but if you want to have several classes share the bandwidth, 
> choosing a queue length for a class is harder because it's variable rate.

Well in my setup I only have 2 queues. Pretty much all interactive
traffic in one, then all unknown/P2P traffic in the other. My problem
is P2P interference with my interactive and web surfing. I don't
typically have problems with non-P2P traffic hurting other non-P2P
traffic. So as long as I keep the interactive queue at the BDP, I'm
ok. If the P2P traffic queue is a bit long, it's not really a big
deal, as longer queues only add latency.

It is my opinion that having 6 queues in the HOWTO is overkill and
confusing to people anyways. It was to me.

Do you have a different experience?

> >Furthermore, fair queuing is not really fair. It is unclear from the
> >tc documentation how Linux manages queue sizes for fair queuing,
> 
> I don't really understand what you mean by fair queuing not being fair.

When you have lots of connections (like bit torrent), each connection
(roughly) is assigned to its own queue. The problem is, these queues
are ALL the same length as the interface queue (at least this is what
I've been told.. I haven't examined the src). Thus, your total amount 
of queuing is proportional to the number of connections. More queuing 
= more latency.

> You can choose your queue size and type in Linux.

You cannot choose your queue size per connection for SFQ. In fact,
tc-sfq has no queue size parameter at all.

My point is using SFQ in the HOWTO isn't optimal. I am currently
testing a RED setup for both upload and download. I've based the
parameters from the bottom of this document: 
http://www.opalsoft.net/qos/DS-26.htm

My script calculates all the RED paramaters for you based on the
RATEUP and RATEDN parameters from the previous script, plus a latency
parameter. I'll post it once I'm sure it's working correctly.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs