This assumes a sensible software system at both ends. 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. 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. 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.
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. 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.