time variable throttling rsync traffic

[Andrew Gideon]

> I would think priority queuing is
> better than shaping in this case. 

I'm afraid I'm not following you here.  As I've learned it, priority
queuing is one of several tools available to achieve shaping.

No?

[...]

> 
> 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. 

I've been assuming that this isn't possible for a couple of reasons.

Since this is a remote backup application, I'm assuming that senders are
"all over".  That is, there is no one "sending router"; there are
instead many sending routers.  The only routers common to all these data
streams would be those close to the receiving server.

Next, most random users have no control over their routing
infrastructure.

> That's the only place
> where the output queue will build up. 

I did mention that delaying ACKs is less than accurate in terms of
bandwidth control, but - as far as I know - this is all the receiving
routers/server can possibly do.  In theory, at least, this will serve to
control the rate at which data is sent because it can force the sender
to pause its transmission.

I've used this myself, but only to control traffic at a very short
distance (ie. ingress policing on a VLAN's gateway interface).  In that
case, at least, it works rather well.  But I don't believe I've ever
tried this to throttle traffic inbound over a WAN link.

	- Andrew