time variable throttling rsync traffic

Andrew Gideon c182driver1 at gideon.org
Mon Sep 14 07:25:55 MDT 2009

On Mon, 14 Sep 2009 14:45:02 +1200, Nathan Ward wrote:

> Unless you do it properly, and do your QoS on routers in the middle.

This is true.  But there are considerations.  I became curious about 
this, so I did some reading to refresh my memory.

First, keep in mind that we're talking about controlling the packets of a 
remote backup.  That is, the largest volume of traffic is inbound to the 
network/server in question.  There's limited ability to control the 
traffic, therefore.  That is one advantage of bwlimit: it exercise 
control exactly where it does the most good.

On the other hand, that control is clearly *not* where the most 
information is available.

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 
ingress filtering.  I did some reading about this last night, and 
assuming that what I read is not out of date or otherwise inaccurate, one 
cannot attach class-full queues to the ingress filter.  Given that, one 
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.

Shaping is best on the router also because it knows more.  It can balance 
traffic between inbound traffic to multiple servers.  The receiving rsync 
server can only balance amongst traffic to that server.  The server knows 
more than a single sending rsync, but less than the router.

As mentioned above, the router and server have limited ability to 
actually control the flow of remote backup traffic.  What they can do is 
delay the return of TCP ACK packets.  In theory, this slows the inbound 
traffic.  But it is not ideal, as it can also cause "excess" traffic via 
retries.  Since the idea is to let non-backup traffic have use of the 
inbound link, this is less than ideal.

So control is most effective at the sending rsync, which suggests that 
bwlimit is a good approach.  But the most information is available at the 
receiving router, suggesting that shaping at the router is also a good 


	- Andrew

More information about the rsync mailing list