Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!wuarchive!csus.edu!ucdavis!ucbvax!quasar.intel.com!kseshadr From: kseshadr@quasar.intel.com (Kishore Seshadri) Newsgroups: comp.protocols.tcp-ip Subject: Re: When is a link saturated? Message-ID: <9101171805.AA05869@quasar> Date: 17 Jan 91 17:05:53 GMT References: <9101150900.AA08526@jerry.inria.fr> Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 30 Christian Huitema writes: > > A promising scheme, which I heard several time, is to manage one queue per > source host. The idea here is to give an even share of the network to every > station; it is also an incentive to implement decent end to end flow controls > (e.g. slow start) as the rogue TCP which use very long queues will observe very > long transit delays and thus very poor performance, while the correct TCP will > work normally. I dont know whether cisco or others plan to implement that. > This may not work well, considering that there are always hosts on a network that legitimately send and receive more network traffic than others. A fileserver for example may appear to be a network pig compared to a workstation...as might a mailserver. It seems to me that we would have to think up schemes that are somewhat more sophisticated. This scheme that you describe sounds uncomfortably close to circuit switching techniques that are so dear to our phone companies ;-) Using the priority parameter in the datagram header is probably a much better approach. I much prefer to have the communicating hosts try and prioritize their own communications. Applications that have a genuine need for high priority service should be able to provide hints to entities between source and destination, requesting higher priority. Kishore Seshadri Kishore Seshadri,(speaking for myself) Intel Corporation <..!intelca!mipos3!kseshadr> "When the only tool you own is a hammer, every problem begins to resemble a nail" -Abraham Maslow