rfc852.txt

RFC 相关的技术文档

     Request for Comments: 852






                    The ARPANET Short Blocking Feature



                                  RFC 852





                              Andrew G. Malis
                       ARPANET Mail: malis@bbn-unix





                       Bolt Beranek and Newman Inc.
                              50 Moulton St.
                           Cambridge, MA  02238





                                April 1983





     This RFC specifies the ARPANET Short Blocking Feature, which will
     allow ARPANET hosts to optionally shorten the IMP's host blocking
     timer.  This Feature is a replacement of the ARPANET non-blocking
     host   interface,  which  was  never  implemented,  and  will  be
     available to hosts using either the 1822  or  1822L  Host  Access
     Protocol.   The  RFC is also being presented as a solicitation of
     comments on the Short  Blocking  Feature,  especially  from  host
     network software implementers and maintainers.










     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     1  INTRODUCTION


     This RFC specifies the ARPANET Short Blocking Feature, which will

     allow a host to shorten the amount of time that it may be blocked

     by its IMP after it presents a message to the network (currently,

     the  IMP  can  block  further input from a host for up to fifteen

     seconds).


     The Feature is an addition to the ARPANET  1822  and  1822L  Host

     Access  Protocols,  and  replaces the non-blocking host interface

     described in section 3.7 of BBN Report 1822 [1], which was  never

     implemented.   This  Feature  will  be available to hosts on C/30

     IMPs only.  This will not present a problem on the ARPANET, which

     only  has  C/30 IMPs, but hosts on non-C/30 IMPs in networks that

     mix C/30 and non-C/30 IMPs will not be  able  to  use  the  Short

     Blocking Feature.


     The RFC's terminology is consistent  with  that  used  in  Report

     1822, and any new terms will be defined when they are first used.

     Familiarity  with  Report  1822  (section  3  in  particular)  is

     assumed.


     This RFC was once part of RFC 802, which is now obsolete and  has

     been  replaced  by  the  combination of this RFC and RFC 851, The

     ARPANET 1822L Host  Access  Protocol  [2].   The  Short  Blocking

     Feature  will  be  available to all hosts on C/30 IMPs, no matter



                                   - 1 -



     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     which (1822 or 1822L) host access  protocol  they  are  using  to

     communicate with the IMP.















































                                   - 2 -



     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     2  THE ARPANET SHORT BLOCKING FEATURE


     The Short Blocking Feature of the 1822 and 1822L protocols allows

     a  host to present messages to the IMP without causing the IMP to

     not accept further messages from the host  for  long  amounts  of

     time  (up  to fifteen seconds).  It is a replacement for the non-

     blocking host interface described in section 3.7 of Report  1822,

     and that description should be ignored.




     2.1  Host Blocking


     Usually, when a source host submits a message to an IMP, the  IMP

     immediately processes that message and sends it on its way to its

     destination host.  Sometimes, however, the IMP  is  not  able  to

     process the message immediately.  Processing a message requires a

     significant number of resources, and when the network is  heavily

     loaded,  there can sometimes be a long delay before the necessary

     resources become available.  In such cases, the IMP must  make  a

     decision  as  to  what to do while it is attempting to gather the

     resources.


     One possibility is for the IMP to stop  accepting  messages  from

     the  source  host  until  it has gathered the resources needed to

     process the message just submitted.  This strategy  is  known  as

     blocking  the  host,  and is basically the strategy that has been



                                   - 3 -



     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     used in the ARPANET up to the present.  When  a  host  submits  a

     message  to  an  IMP, all further transmissions from that host to

     that IMP are blocked until the message can be processed.


     It is important to note, however, that not all  messages  require

     the  same  set  of resources in order to be processed by the IMP.

     The particular set of resources needed will depend on the message

     type,  the  message  length,  and  the  destination  host  of the

     message.  Therefore, although it might take a long time to gather

     the  resources  needed  to process a particular message, it might

     take only a short time to gather the resources needed to  process

     some other message.  This fact exposes a significant disadvantage

     in the strategy of blocking the host.  A host  which  is  blocked

     may  have many other messages to submit which, if only they could

     be submitted, could be processed immediately.  It is "unfair" for

     the  IMP to refuse to accept these messages until it has gathered

     the resources for some  other,  unrelated  message.   Why  should

     messages for which the IMP has plenty of resources be delayed for

     an arbitrarily long amount of time just because the IMP lacks the

     resources needed for some other message?


     A simple way to alleviate the problem would be to place  a  limit

     on  the  amount of time during which a host can be blocked.  This

     amount  of  time  should  be  long  enough  so  that,   in   most

     circumstances,  the  IMP  will  be  able  to gather the resources



                                   - 4 -



     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     needed to process the message within the given time period.   If,

     however, the resources cannot be gathered in this period of time,

     the IMP will flush the message, sending a  reply  to  the  source

     host  indicating that the message was rejected and specifying the

     reason that it could not be  processed.   However,  the  resource

     gathering process would continue.  The intention is that the host

     resubmit the message  in  a  short  time,  when,  hopefully,  the

     resource  gathering  process  has concluded successfully.  In the

     meantime, the host  can  submit  other  messages,  which  may  be

     processed   sooner.    This   strategy  does  not  eliminate  the

     phenomenon of host blocking, but  only  limits  the  time  during

     which  a host is blocked.  This shorter time limit will always be

     less than or equal to two seconds.


     Note, however, that there  is  a  disadvantage  to  having  short

     blocking  times.  Let us assume that the IMP accepts a message if

     it has all the resources  needed  to  process  it.   The  ARPANET

     provides a sequential delivery service, whereby messages with the

     same priority, source host, and destination host are delivered to

     the  destination host in the same order as they are accepted from

     the source host.  With short blocking times, however,  the  order

     in  which  the IMP accepts messages from the source host need not

     be the same as the order in  which  the  source  host  originally

     submitted  the messages.  Since the two data streams (one in each




                                   - 5 -



     ARPANET Short Blocking Feature                         April 1983
     RFC 852



     direction) between the host and the IMP are not synchronized, the

     host  may  not  receive the reply to a rejected message before it

     submits subsequent messages for the same destination host.  If  a

     subsequent  message  is accepted, the order of acceptance differs

     from the order of original submission, and the ARPANET  will  not

     provide  the  same type of sequential delivery that it has in the

     past.   If  sequential  delivery  by  the  subnet  is  a   strict

     requirement,  the Short Blocking Feature should not be used.  For

     messages without this requirement, however,  the  Short  Blocking

     Feature can be used.


     Up to now, type 0 (Regular)  messages  have  only  had  sub-types

     available  to  request  the  standard  blocking  timeout, fifteen