|
Edwin W. Meyer, Jr. |
(i) chronic underutilization of resources,
(ii) highly restricted bandwidth,
(iii)considerable overhead under normal operation,
(iv) insufficient flexibility under conditions of increasing load,
(v) it optimizes for the wrong set of conditions, and
(vi) the scheme breaks down because of message length indeterminacy.
(i) it permits greater utilization of resources,
(ii) does not arbitrarily limit transmission bandwidth,
(iii)is highly flexible under conditions of changing load,
(iv) imposes no overhead on normal operation, and
(v) optimizes for the situations that most often occur.
[Page 1]
(1) Most network transmission falls into two categories:
Type 1 - short messages (<500 bits) at intervals of several seconds
or more. (console communication)
Type 2 - a limited number (10 - 100) of full messages (8000 bits)
in rapid succession. (file transmission)
(2) Most processes are ready to accept transmitted data when it arrives at the destination and will pick it up within a few seconds (longer for large files). Thus, at any particular instant the great major- ity of read links have no data buffered at the destination HOST. This assumes a sensible software system at both ends.
(3) Flow control need be imposed only rarely on links transmitting Type 1 messages, somewhat more frequently for Type 2 messages.
(4) Both the total network load and that over a single connection fluc- tuate and can not be adequately predicted by either the NCP or the process attached to an individual connection.
(5) Assuming adequate control of wide bandwidth transmission (Type 2), the probability that an NCP will be unable to accept messages from the IMP due to full buffers is quite small, even if the simultane- ous receipt of moderately small messages over all active links would more than fill the NCP's input buffers.
(6) In the event that an NCP's buffers do fill completely, it may refuse to accept any transmission from the IMP for up to a minute without utter catastrophe.
[Page 2]
(7) Under cases of extreme input load, if an NCP has large amounts of data buffered for input to a local process, AND that process has not read data over that connection for more than a minute, the NCP may delete that data to make space for messages from the IMP. This is expected to happen extremely rarely, except in cases where the process is the main contributor to the overload by maintaining several high volume connections which it is not reading.
(1) Chronic Underutilization of Resources - A fixed allocation of buffer space dedicated to a single Type 1 connection will go perhaps 90% unused if we actually achieve responsive console interaction through the network. This is because it is empty most of the time and is very seldom more than partially filled. Stated conversely, a scheme of demand allocation might be expected to han- dle several times as many console connections using the same buffer resources. (It has been suggested that this problem of underutili- zation could be alleviated by allocating more than 100% of the available buffer space. This is in fact no solution at all, because it defeats the basic premise underlying this method of flow con- trol: guaranteed receptivity. True, it might fail in less than one case in 1000, but that is exactly the case for which flow control exists.)
(2) Highly Restricted Bandwidth - At the same time that all that buffer space dedicated to low volume connections is being wasted (and it can't be deallocated - see below), high volume communication is unnecessarily slowed because of inadequate buffer allocation. (Because of the inability to deallocate, it is unwise to give a large allocation.) Data is sent down the connection to the alloca- tion limit, then stops. Several seconds later, after the receiving process picks up some of the data, a new allocation is made, and another parcel of data is sent. It seems clear that even under only moderately favorable conditions, a demand allocation scheme will allow several times the bandwidth that this one does.
(3) Considerable Overhead During Normal Operation - It can be seen that flow control actually need be imposed relatively rarely. However, this plan imposes a constant overhead for all connections due to the continuing need to send new allocations. Under demand alloca- tion, only two RFC's, two CLS's, and perhaps a couple of SPD and RSM control messages need be transmitted for a single connection. Under this plan, a large fraction of the NCP control messages will be ALL allocation requests. There will probably be several times as many control messages to be processed by both the sending and receiving NCP's, as under a demand allocation scheme.
[Page 3]
(4) Inflexibility Under Increasing Load Conditions - Not only is this plan inflexible as to different kinds of load conditions on a sin- gle link, there is potential inflexibility under increasing total load. The key problem here is that an allocation can not be arbi- trarily revoked. It can be taken back only if it is used. As an example of the problem that can be caused, assume the case of a connection made at 9 AM. The HOST controlling the receiving socket senses light load, and gives the connection a moderately large allocation. However, the process attached to the send socket intends to use it only to report certain special events, and doesn't normally intend to send much at all down this connection. Comes 12 noon, and this connection still has 90% of its original allocation left. Many other processes are now using the network, and the NCP would dearly love to reduce its allocation, if only it could. Of course it can't. If the NCP is to keep its part of the flow control bargain, it must keep that space empty waiting for the data it has agreed to receive.
This problem can't really be solved by basing future allocations on past use of the connection, because future use may not correlate with past use. Also, the introduction of a deallocation command would cause synchrony problems.
The real implication of this problem is that an NCP must base its allocation to a link on conditions of heavy load, even if there is currently only light network traffic.
(5) Wrong Type of Optimization - This type of flow control optimizes for the case where every connection starts sending large amounts of data almost simultaneously, exactly the case that just about never occurs. As a result the NCP operates almost as slowly under light load as it does under heavy load.
(6) Loss of Allocation Synchrony Due to Message Length Indeterminacy - If this plan is to be workable, the allocation must apply to the entire message, including header, padding, text, and marking, oth- erwise, a plethora of small messages could overflow the buffers, even though the text allocation had not been exceeded. Thomas Bar- kalow of Lincoln Laboratories has pointed out that this also fails, because the sending HOST can not know how many bits of padding that the receiving HOST's system will add to the message. After several messages, the allocation counters of the sending and receiving HOSTs will get seriously out of synchrony. This will have serious consequences.
It has been argued that the allocation need apply only to the text portion, because the header, padding, and marking are deleted soon after receipt of the message. This imposes an implementation res- triction on the NCP, that it must delete all but the text part of the message just as soon as it gets it from the IMP. In both the TX2 and Multics implementations it is planned to keep most of the message in the buffers until it is read by the receiving process.
[Page 4]
(i) An overload that would fill an NCP's buffers is expected to occur at infrequent intervals.
(ii) When it does occur, the situation is generally self-correcting and lasts for only a few seconds. Flow over individual connections may be temporarily delayed, but this is unlikely to be serious.
(iv) In a few of these situations radical action by the NCP may be needed to unblock the logjam. However, this will have serious consequences only for those connections directly responsible for the tie-up.
[Page 5]
[Page 6]
[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by William Lewis 6/97 ]
[Page 7]