time variable throttling rsync traffic

[Andrew Gideon]

On Mon, 14 Sep 2009 13:09:41 -0400, Eric S. Johansson wrote:

> On 9/14/2009 9:25 AM, Andrew Gideon wrote:
> 
>> 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 approach.
>>
>> Interesting.
> 
> Exactly what I meant by "suck in different ways including those we don't
> know yet".  I think we have a couple of "low-cost options".  

I don't think you're quite getting my point; I'm sorry I'm not being 
clear.  At the moment, I see *no* good option.  I see a few different 
partial solutions, but nothing that really (1) accurately controls the 
flow while (2) taking other uses of bandwidth into account.


> As we
> discussed on the rsnapshot list, you could use the remote shell option
> to create a bandwidth limited remote shell.  

I don't see how this is any better than the --bwlimit feature.  It has 
more control than what can be done at the router or server, but it 
doesn't have the router's or server's awareness of the other uses of the 
bandwidth.  So while it can replace bwlimit, it cannot shape the traffic 
in any intelligent way.

For example, if there are two, twenty, or two hundred rsync users, the 
"bandwidth limited remote shell" wouldn't know to slow traffic down.

Or have I misunderstood you or missed something about the "bandwidth 
limited remote shell" solution?

Even if the "bandwidth limited remote shell" were built to work with an 
interceding server process to coordinate bandwidth use amongst rsync 
users, this would still only be dealing with rsyncs to that server.  It 
ignores other servers on the same network, and it ignores other users of 
the bandwidth in question.

I wonder: Is there something "smarter" than just withholding ACKs that 
the receiving router (or server) could do to slow the incoming traffic?

	- Andrew