time variable throttling rsync traffic

[Phil Vandry]

On Mon, 14 Sep 2009 13:25:55 +0000 (UTC), Andrew Gideon wrote:
> If a router is involved, it can do egress shaping on the local side.  
> That's best.  If a router is not involved, then the server must do 

I don't think that's best at all. I would think priority queuing is
better than shaping in this case. Shaping is much more
resource-intensive, many routers (including Linux) do a poor job of it
or don't support it at all, and it's not attacking the problem
directly anyway.

> can police the inbound traffic but not prioritize it.  That means that 
> one cannot do as I originally wrote: let the backup traffic use as much 
> bandwidth as available, but let anything else steal traffic from it.  To 
> do that requires shaping at the router.

If there is one or more bottleneck link in the network (places where
traffic feeds from one or more links with aggregate larger capacity
into a link with smaller capacity) then it makes sense that this work
has to be done on the router that is on the sending side of the
bottleneck link(s), not on the receiving side. That's the only place
where the output queue will build up. On the receiving side, it's too
late: the other router has already made a bad decision and chosen low
priority traffic over high priority traffic from its outbound queue.

> Shaping is best on the router also because it knows more.  It can balance 

Yes, the router that sits in front of the bottleneck knows the most:
it's the only one that knows, based on the size of its output queue,
whether or not congestion is present. But shaping doesn't take advantage
of that information. Priority queuing does.

-Phil