Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!bbn!bbn.com!wbe From: wbe@bbn.com (Winston B Edmond) Newsgroups: comp.protocols.tcp-ip Subject: Re: PSN 7 End-to-End question. Message-ID: <20469@bbn.COM> Date: 3 Feb 88 20:41:31 GMT References: <920@thumper.bellcore.com> <8802030045.AA01518@spam.istc.sri.com> Sender: news@bbn.COM Reply-To: wbe@BBN.COM (Winston B Edmond) Organization: BBN Laboratories Incorporated, Cambridge MA Lines: 59 Robert Allen @ SPAM.ISTC.SRI.COM writes: > >> Yes, transport protocol behavior is important, but there's no reason why >> the "best effort" network can't have defense mechanisms that activate >> only when the network is congested. For example, the network might >> normally run in a pure datagram mode, with no network bandwidth wasted >> on edge-to-edge acknowledgements. However when the network becomes >> congested, the internal equivalent of "source quench" packets are sent >> to the entry node, telling it to stop injecting so much traffic into the >> network. > > If everything is fine and dandy then there shouldn't be a > need for ETE. It should only activate when needed, ... One must be careful about such things. Maybe for a LAN it makes sense to say "when *the network* becomes congested", but for a widely distributed network, such as the ARPANET, with many independent communication paths, the question should really be rephrased as: Can delay caused by congestion controls be avoided when all the paths and nodes between the message's source and destination, including whatever multiple and alternate paths might be used, are relatively uncongested? That would require enough timely information about the path to decide, and the cost of that decision would have to be weighed against the performance improvement to be gained. Once upon a time, the ARPANET had no preallocation of space in the destination IMP, and still does not use it for short-enough messages. Suffice it to say that its absence was enough of a problem to be worth putting it in. If performance in the uncongested case is currently a problem, perhaps the source IMP could estimate the likelihood of congestion along its selected path and then choose between sending multi-packet messages with or without preallocation, with the destination accepting either. ------------------------------ I would strongly recommend against building a system that activated and deactivated a congestion control system, if by that one means sometimes ceasing to use network processing and communication resources to exchange congestion information. Instead, the congestion control system should always be running, with an option to note that a particular network path is uncongested at the moment. Congestion avoidance requires that information about the state of the network be propagated throughout the network. Perfect knowledge would require that predictions at the source node be accurate for the transit time of the packet. Decreasing the amount or timeliness of the information increases the likelihood of congestion and packet loss. If a disableable congestion control system were used, the network nodes would have to be careful to kick in the congestion controls BEFORE congestion actually occurs, or else there would be a catastrophe point in the network's ability to handle traffic. That point would occur as IMPs switch from sending just user traffic to sending user traffic PLUS congestion control traffic. -WBE Disclaimer: these are personal remarks and should not be taken as official statements of BBN Laboratories Incorporated.