On Fri, Jun 21, 2002 at 01:59:38AM -0400, Steven J. Dovich wrote:
> The underlying problem is that of apportioning each consumer a
> "fair" share of some resource.  For process scheduling, that resource
> is the processor across time. For I/O, the resource is device/bus
> bandwidth. BSD has had decent bandwidth management facilities for
> well over a decade.  Van Jacobsen and Mike Karels made the fundamental
> advance in dealing with detecting and responding to network congestion
> by identifying algorithms which converged on the fair-share allocation
> of network bandwidth.
> 
> What we are looking at here is I/O congestion.  With a means of
> determining the available bandwidth, detecting channel saturation,
> and a means of throttling the requestors, there is no reason why
> TCP congestion avoidance algorithms can't contribute to effective
> management of I/O bandwidth.

I've been thinking about this, and I don't think I agree with your
reasoning.  TCP congestion avoidance works decently, but it's a
different problem domain: a fundamental characteristic of IP is
the heterogenous network, and there's no telling at the source
how much throughput is available for traffic.  That's not the case
with device I/O, except for network-mounted devices.  I also think
that TCP congestion avoidance still doesn't deal very well with
interactive sessions.  Try connecting to the Internet using a 56K
modem, connecting to a remote host using telnet or ssh, and starting
a large download at the same time.  See what happens to your telnet
session, and you're approaching a problem closer to what we'd be
trying to solve with an I/O scheduler.

--aidan