Re: What's the best configuration for this setup?

On Sat, 23 Nov 1996, Ross Wheeler wrote:

> Limiting write() will not help if you don't have control of the upstream
> proxy, so it would be better to control it at the receiver (IMO).

No, it helps the owner of the upstream proxy throttle what they send to
you. You would want to limit read()s.
 
> On my proxy, if I set a PPP link to the main host via RS232 (a 12"
> cable), but set the RS232 link speed to 38K or 56K, set the route to the
> upstream proxy to go via THAT interface, but the local users on the ethernet
> port of the proxy, I can throttle by simply adjusting the RS232 speed.
> Regardless of number of proxy hits, the main upstream link can't get
> flooded if the RS232 speed is less than the uplink, but then that may not
> be entirely ideal either. If _all_ traffic on the link at that time is
> for the proxy, why _not_ let it have it all?

You need to limit traffic coming in to you from upstream, rather than the
packets you send to the upstream site. Other than that, it works,
provided you are not overly bombarded with requests. I had a problems
with *lots* of greedy users that I tried to fix with a null modem link -
ended up with "out of buffer space" errors.
  
> A complex, but perhaps ideal solution, would be to set thresholds on the
> link. Tell squid it's allowed "X" Kb/sec minimum, but to "back off" if
> link activity is high. This could be measured by parent response time
> perhaps? For instance, we ping our upstream proxy in typically 35-40ms
> under light load. If that suddenly blows out to 100-200ms, the link is
> getting busy, and at 300+ it's getting flogged.
>
> If squid could start throttling at say, 100ms and linearly drop to the
> specified minimum at 300ms, I'd be wrapped. (These figures would need to
> be site-selected).
>
> Pipe dream?

Nice idea. Not impossible to implement, but it will take some serious
thought before coding.

Danny
Received on Fri Nov 22 1996 - 19:35:23 MST