rfc59.txt

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

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


The advantages of demand allocation using the "cease on link" flow con-
trol method are pretty much the converse of the disadvantages of fixed
allocation. There is much greater resource utilization, flexibility,
bandwidth, and less overhead, primarily because flow control restric-
tions are imposed only when needed, not on normal flow.


One would expect very good performance under light and moderate load,
and I won't belabor this point.


The real test is what happens under heavy load conditions. The chief
disadvantage of this demand allocation scheme is that the "cease on
link" IMP message can not quench flow over a link soon enough to prevent
an NCP's buffers from filling completely under extreme overload.

This is true. However, it is not a critical disadvantage for three rea-
sons:


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

Let's examine the operation of an NCP employing demand allocation and
using "cease on link" for flow control. The following discussion is
based on a flow control algorithm in which the maximum permissible queue
length (MQL) is calculated to be a certain fraction (say 10%) of the
total empty buffer space currently available. The NCP will block a con-
nection if the input queue length exceeds the MQL. This can happen
either due to new input to the queue or a new calculation of the MQL at
a lower value. Under light load conditions, the MQL is reasonably high,
and relatively long input queues can be maintained without the connec-
tion being blocked.

As load increases, the remaining available buffer space goes down, and
the MQL is constantly recalculated at a lower value. This hardly affects
console communications with short queues, but more queues for high
volume connections are going above the MQL. As they do, "cease on link"
messages are being sent out for these connections.

If the flow control algorithm constants are set properly, there is a
high probability that flow over the quenched links will indeed cease
before the scarcity of buffer space reaches critical proportions.



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


However, there is a finite probability that the data still coming in
over the quenched links will fill the buffers. This is most likely under
already heavy load conditions when previously inactive links start
transmitting at at once at high volume.

Once the NCP's buffers are filled it must stop taking all messages from
its IMP. This is serious because now the NCP can no longer receive con-
trol messages sent by other NCP's, and because the IMP may soon be
forced to stop accepting messages from the NCP. (Fortunately, the NCP
already has sent out "cease on link" messages for virtually all of the
high volume connections before it stopped taking data from the IMP.)

In most cases input from the IMP remains stopped for only a few seconds.
After a very short interval, some process with data queued for input is
likely to come in and pick it up from the NCP's buffers. The NCP immedi-
ately starts taking data from the IMP again. The IMP output may stop and
start several times as the buffers are opened and then refilled. How-
ever, more processes are now reading data queued for their receive sock-
ets, and the NCP's buffers are emptying at an accelerating rate. Soon
the reading processes make enough buffer space to take in all the mes-
sages still pending for blocked links, and normal IMP communications
resume.

As the reading processes catch up with the sudden burst of data, the MQL
becomes lower, and more and more links become unblocked. The crisis can
not immediately reappear, because each link generally becomes unblocked
at a different time. If new data suddenly shoots through, the link
immediately goes blocked again. The MQL goes up, with the result that
other links do not become unblocked.

The worst case appears at a HOST with relatively small total buffer
space (less than 8000 bits per active receive link) under heavy load
conditions. Suppose that high volume transmission suddenly comes in over
more than a half-dozen links simultaneously, and the processes attached
to the receive links take little or none of the input. The input buffers
may completely fill, and the NCP must stop all input from the IMP. If
some processes are reading links, buffer space soon opens up. Shortly it
is filled again, this time with messages over links which are not being
read. At this point the NCP is blocked, and could remain so indefin-
itely. The NCP waits for a time, hoping that some process starts reading
data. If this happens, the crisis may soon ease.

If buffer space does not open up of its own accord, after a limited
interval the NCP must take drastic action to get back into communication
with its IMP. It selects the worst offending link on the basis of amount
of data queued and interval since data was last read by this process,
and totally deletes the input queue for this link. This should break the
logjam and start communications again.

This type of situation is expected to occur most often when a process
deliberately tries to block an NCP in this manner. The solution has
serious consequences only for "bad" processes: those that flood the net-
work with high volume transmission over multiple links which are not
being read by the receiving processes.



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


Because of the infrequency and tolerability of this situation, the
overall performance of the network using this scheme of demand alloca-
tion should still be much superior to that of a network employing a
fixed allocation scheme.

       [ This RFC was put into machine readable form for entry ]
         [ into the online RFC archives by William Lewis 6/97 ]


















































                                                                [Page 7]