rfc59.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

                          Edwin W. Meyer, Jr.
                            MIT Project MAC
                              27 June 1970


The method of flow control described in RFC 54, prior allocation of
buffer space by the use of ALL network commands, has one particular
advantage. If no more than 100% of an NCP's buffer space is allocated,
the situation in which more messages are presented to a HOST then it can
handle will never arise.

However, this scheme has very serious disadvantages:


(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.

Several people from Project MAC and Lincoln Laboratories have discussed
this topic, and we feel that the "cease on link" flow control scheme
proposed in RFC 35 by UCLA is greatly preferable to this new plan for
flow control.

The method of flow control proposed in RFC 46, using BLK and RSM control
messages, has been abandoned because it can not guarantee to quench flow
within a limited number of messages.


The advantages of "cease on link" to the fixed allocation proposal are
that:

(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.

Its single disadvantage is that under rare circumstances an NCP's input
buffers can become temporarily overloaded. This should not be a serious
drawback for network operation.

The "cease on link" method of flow control operates in the following



                                                                [Page 1]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation


manner.  IMP messages for a particular "receive" link may be coming in
to the destination HOST faster than the attached process is reading them
out of the NCP's buffers. At some point the NCP will decide that the
input queue for that link is too large in relation to the total amount
of free NCP buffer space remaining. At this time the NCP initiates
quenching by sending a "cease on link" IMP message to its IMP. This does
nothing until the next message for that link comes in to the destination
IMP. The message still gets transmitted to the receiving HOST. However,
the RFNM returned to the transmitting HOST has a special bit set. This
indicates to the originating NCP that it should stop sending over that
link. As a way of confirming the suspension, the NCP sends an SPD <link>
"suspended" NCP control message to the receiving HOST, telling it that
it indeed has stopped transmitting. At a future time the receiving pro-
cess will have cut the input queue for the link down to reasonable size,
and the NCP tells the sending NCP to begin sending messages by issuing a
RSM <link> "resume" NCP control message.

The flow control argument is based on the following premises:


(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]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation


(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.



Based on the preceding premises, I see the following disadvantages in
the flow control proposed in RFC 54:


(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]

NWG/RFC 59   Flow Control - Fixed Versus Demand Allocation


(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.