Janto wrote:

>
> I don't think I can use a rate limit on its own. There's an initial
> burst from the sender side that saturates the link and interferes with
> the voice traffic.

Shaping from the wrong end of a bottleneck is a pain, and I agree
slowstart is slower than getting the whole window, but it is somewhat
exponential and will soon bork up the far buffer (esp. as browsers/web
servers may use several concurrent TCPs and start new ones as soon as
they finish).

Depends on how fast your link is as to what you can acheive -
sacrificing bandwidth will be requiired.

Just throttling (ie. having a queue after the ISP queue, but going a bit
slower) doesn't save you from the bursts).

Policing (not buffering but using a virtual buffer and then dropping
when it would be full) is better in someways as at least when you drop
the other end gets to know sooner - ie if you you tail drop from a
queue, the other end doesn't know for a while and if in slowstart will
still be ramping up.

In some ways using queues is better - ie in Linux you get more choice of
queue type/classification. You must keep the queues short, though and
drop packets, wastefull as it may seem.

When I had a 512kbit link I used to use iptables connbytes to send new
connections to an extra short sfq to drop early and get them out of
slowstart (small packets were exempted so the connections got started
OK). Then after XKB they went to slightly longer queues. I also used to
have a hacked esfq that (I think - I am crap at reading code) head
dropped - only bulk packets from established connections were sent to it.

As for messing with windows - I think packeteer does that (but then I've
read it didn't handle scaling well) If you want to do it you will need
to code something that keeps alot of state about every connection (and
possibly not by chance use their patented algorithm what ever that is -
maybe only worry if you live in the usa).

Even if you do create something that dynamically messes with window
sizes you still would be screwed if by chance alot of connections with
different rtts all sent their one packet at the same time etc. There are
alot of things just not in your control when you are at the wrong end of
the bottleneck. I think you may also hurt yourself when in competition
for others maxed egress bandwidth by using a smaller window - TCP is not
very fair.

Saying all that (trying to) shape downloads is still alot better than
doing nothing.

Andy.