[adsl-qos] Re: Re: Bandwidth Management HOWTO Errors

[Andy Furniss]

Mike Perry wrote:
> Thus spake Andy Furniss (andy.furniss at dsl.pipex.com):
> 
> 
>>Mike Perry wrote:
>>
>>>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,
>>
>>I'm curious - what's wrong with it ?
> 
> 
> Pretty much the same thing.. Use of SFQ and large queuing.
> 
> 
>>>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.
>>
>>Is it OK when there is just upload traffic?
> 
> 
> Without my script, even just upload traffic hurts me because of the
> queuing on my ASDL modem. With the script, upload seems to be working
> fine. I still need to run a test to saturate the link for download
> shaping though.
> 
> 
>>It's not like that - see below. As for bittorrent, that's a special 
>>case. It uses full duplex which makes shaping downstream harder and your 
>>peers are likely to have flooded buffers. I would consider MSS clamping it.
> 
> 
> Full duplex? At the IP level we still have serialization of packets
> which can be marked and limited. The idea is to keep your downstream
> rate lower than your ASDL modem speed. When this is the case, queuing
> will occurr at your machine, and dropped packets will cause remote TCP
> connections to reduce their congestion windows, which means less
> traffic in the link while waiting for an ack, which means less
> bandwidth used. In my mind, this works very similarly to upload
> limiting.. In fact, in an identical manner, except now you're forcing
> the queue to be far from the source rather than near. But the point
> is it is local to you, and under your control, since your shaping
> router is the slowest hop.
> 
> What does MSS clamping accomplish?
> 
> 
>>I agree the default 128 packet for SFQ is too high - you can change it 
>>in net/sched/sch_sfq.c. Better still use esfq (not in kernel) you can 
>>choose length per queue with that.
> 
> 
> Do you happen to know if it's 128 packets per connection? or total?
> Casual inspection makes me think it is total.
> 
> 
>>I would rather use esfq TBH - I like the fairness and for ingress I like 
>> the idea that each tcp gets dequeued at a rate proportional to it's 
>>share, rather than near link speed.
> 
> 
> I prefer the idea of graceful backoff of TCP window sizes that RED
> provides, rather than sudden total packet loss.. SFQ and FIFO cause
> oscillation in TCP window sizes when your queues are full.
>