home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc852 < prev    next >
Text File  |  1991-04-21  |  16KB  |  768 lines
  1.  
  2.  
  3.  
  4.  
  5.      Request for Comments: 852
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.                     The ARPANET Short Blocking Feature
  13.  
  14.  
  15.  
  16.                                   RFC 852
  17.  
  18.  
  19.  
  20.  
  21.  
  22.                               Andrew G. Malis
  23.                        ARPANET Mail: malis@bbn-unix
  24.  
  25.  
  26.  
  27.  
  28.  
  29.                        Bolt Beranek and Newman Inc.
  30.                               50 Moulton St.
  31.                            Cambridge, MA  02238
  32.  
  33.  
  34.  
  35.  
  36.  
  37.                                 April 1983
  38.  
  39.  
  40.  
  41.  
  42.  
  43.      This RFC specifies the ARPANET Short Blocking Feature, which will
  44.      allow ARPANET hosts to optionally shorten the IMP's host blocking
  45.      timer.  This Feature is a replacement of the ARPANET non-blocking
  46.      host   interface,  which  was  never  implemented,  and  will  be
  47.      available to hosts using either the 1822  or  1822L  Host  Access
  48.      Protocol.   The  RFC is also being presented as a solicitation of
  49.      comments on the Short  Blocking  Feature,  especially  from  host
  50.      network software implementers and maintainers.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      ARPANET Short Blocking Feature                         April 1983
  62.      RFC 852
  63.  
  64.  
  65.  
  66.      1  INTRODUCTION
  67.  
  68.  
  69.      This RFC specifies the ARPANET Short Blocking Feature, which will
  70.  
  71.      allow a host to shorten the amount of time that it may be blocked
  72.  
  73.      by its IMP after it presents a message to the network (currently,
  74.  
  75.      the  IMP  can  block  further input from a host for up to fifteen
  76.  
  77.      seconds).
  78.  
  79.  
  80.      The Feature is an addition to the ARPANET  1822  and  1822L  Host
  81.  
  82.      Access  Protocols,  and  replaces the non-blocking host interface
  83.  
  84.      described in section 3.7 of BBN Report 1822 [1], which was  never
  85.  
  86.      implemented.   This  Feature  will  be available to hosts on C/30
  87.  
  88.      IMPs only.  This will not present a problem on the ARPANET, which
  89.  
  90.      only  has  C/30 IMPs, but hosts on non-C/30 IMPs in networks that
  91.  
  92.      mix C/30 and non-C/30 IMPs will not be  able  to  use  the  Short
  93.  
  94.      Blocking Feature.
  95.  
  96.  
  97.      The RFC's terminology is consistent  with  that  used  in  Report
  98.  
  99.      1822, and any new terms will be defined when they are first used.
  100.  
  101.      Familiarity  with  Report  1822  (section  3  in  particular)  is
  102.  
  103.      assumed.
  104.  
  105.  
  106.      This RFC was once part of RFC 802, which is now obsolete and  has
  107.  
  108.      been  replaced  by  the  combination of this RFC and RFC 851, The
  109.  
  110.      ARPANET 1822L Host  Access  Protocol  [2].   The  Short  Blocking
  111.  
  112.      Feature  will  be  available to all hosts on C/30 IMPs, no matter
  113.  
  114.  
  115.  
  116.                                    - 1 -
  117.  
  118.  
  119.  
  120.      ARPANET Short Blocking Feature                         April 1983
  121.      RFC 852
  122.  
  123.  
  124.  
  125.      which (1822 or 1822L) host access  protocol  they  are  using  to
  126.  
  127.      communicate with the IMP.
  128.  
  129.  
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.  
  174.  
  175.                                    - 2 -
  176.  
  177.  
  178.  
  179.      ARPANET Short Blocking Feature                         April 1983
  180.      RFC 852
  181.  
  182.  
  183.  
  184.      2  THE ARPANET SHORT BLOCKING FEATURE
  185.  
  186.  
  187.      The Short Blocking Feature of the 1822 and 1822L protocols allows
  188.  
  189.      a  host to present messages to the IMP without causing the IMP to
  190.  
  191.      not accept further messages from the host  for  long  amounts  of
  192.  
  193.      time  (up  to fifteen seconds).  It is a replacement for the non-
  194.  
  195.      blocking host interface described in section 3.7 of Report  1822,
  196.  
  197.      and that description should be ignored.
  198.  
  199.  
  200.  
  201.  
  202.      2.1  Host Blocking
  203.  
  204.  
  205.      Usually, when a source host submits a message to an IMP, the  IMP
  206.  
  207.      immediately processes that message and sends it on its way to its
  208.  
  209.      destination host.  Sometimes, however, the IMP  is  not  able  to
  210.  
  211.      process the message immediately.  Processing a message requires a
  212.  
  213.      significant number of resources, and when the network is  heavily
  214.  
  215.      loaded,  there can sometimes be a long delay before the necessary
  216.  
  217.      resources become available.  In such cases, the IMP must  make  a
  218.  
  219.      decision  as  to  what to do while it is attempting to gather the
  220.  
  221.      resources.
  222.  
  223.  
  224.      One possibility is for the IMP to stop  accepting  messages  from
  225.  
  226.      the  source  host  until  it has gathered the resources needed to
  227.  
  228.      process the message just submitted.  This strategy  is  known  as
  229.  
  230.      blocking  the  host,  and is basically the strategy that has been
  231.  
  232.  
  233.  
  234.                                    - 3 -
  235.  
  236.  
  237.  
  238.      ARPANET Short Blocking Feature                         April 1983
  239.      RFC 852
  240.  
  241.  
  242.  
  243.      used in the ARPANET up to the present.  When  a  host  submits  a
  244.  
  245.      message  to  an  IMP, all further transmissions from that host to
  246.  
  247.      that IMP are blocked until the message can be processed.
  248.  
  249.  
  250.      It is important to note, however, that not all  messages  require
  251.  
  252.      the  same  set  of resources in order to be processed by the IMP.
  253.  
  254.      The particular set of resources needed will depend on the message
  255.  
  256.      type,  the  message  length,  and  the  destination  host  of the
  257.  
  258.      message.  Therefore, although it might take a long time to gather
  259.  
  260.      the  resources  needed  to process a particular message, it might
  261.  
  262.      take only a short time to gather the resources needed to  process
  263.  
  264.      some other message.  This fact exposes a significant disadvantage
  265.  
  266.      in the strategy of blocking the host.  A host  which  is  blocked
  267.  
  268.      may  have many other messages to submit which, if only they could
  269.  
  270.      be submitted, could be processed immediately.  It is "unfair" for
  271.  
  272.      the  IMP to refuse to accept these messages until it has gathered
  273.  
  274.      the resources for some  other,  unrelated  message.   Why  should
  275.  
  276.      messages for which the IMP has plenty of resources be delayed for
  277.  
  278.      an arbitrarily long amount of time just because the IMP lacks the
  279.  
  280.      resources needed for some other message?
  281.  
  282.  
  283.      A simple way to alleviate the problem would be to place  a  limit
  284.  
  285.      on  the  amount of time during which a host can be blocked.  This
  286.  
  287.      amount  of  time  should  be  long  enough  so  that,   in   most
  288.  
  289.      circumstances,  the  IMP  will  be  able  to gather the resources
  290.  
  291.  
  292.  
  293.                                    - 4 -
  294.  
  295.  
  296.  
  297.      ARPANET Short Blocking Feature                         April 1983
  298.      RFC 852
  299.  
  300.  
  301.  
  302.      needed to process the message within the given time period.   If,
  303.  
  304.      however, the resources cannot be gathered in this period of time,
  305.  
  306.      the IMP will flush the message, sending a  reply  to  the  source
  307.  
  308.      host  indicating that the message was rejected and specifying the
  309.  
  310.      reason that it could not be  processed.   However,  the  resource
  311.  
  312.      gathering process would continue.  The intention is that the host
  313.  
  314.      resubmit the message  in  a  short  time,  when,  hopefully,  the
  315.  
  316.      resource  gathering  process  has concluded successfully.  In the
  317.  
  318.      meantime, the host  can  submit  other  messages,  which  may  be
  319.  
  320.      processed   sooner.    This   strategy  does  not  eliminate  the
  321.  
  322.      phenomenon of host blocking, but  only  limits  the  time  during
  323.  
  324.      which  a host is blocked.  This shorter time limit will always be
  325.  
  326.      less than or equal to two seconds.
  327.  
  328.  
  329.      Note, however, that there  is  a  disadvantage  to  having  short
  330.  
  331.      blocking  times.  Let us assume that the IMP accepts a message if
  332.  
  333.      it has all the resources  needed  to  process  it.   The  ARPANET
  334.  
  335.      provides a sequential delivery service, whereby messages with the
  336.  
  337.      same priority, source host, and destination host are delivered to
  338.  
  339.      the  destination host in the same order as they are accepted from
  340.  
  341.      the source host.  With short blocking times, however,  the  order
  342.  
  343.      in  which  the IMP accepts messages from the source host need not
  344.  
  345.      be the same as the order in  which  the  source  host  originally
  346.  
  347.      submitted  the messages.  Since the two data streams (one in each
  348.  
  349.  
  350.  
  351.  
  352.                                    - 5 -
  353.  
  354.  
  355.  
  356.      ARPANET Short Blocking Feature                         April 1983
  357.      RFC 852
  358.  
  359.  
  360.  
  361.      direction) between the host and the IMP are not synchronized, the
  362.  
  363.      host  may  not  receive the reply to a rejected message before it
  364.  
  365.      submits subsequent messages for the same destination host.  If  a
  366.  
  367.      subsequent  message  is accepted, the order of acceptance differs
  368.  
  369.      from the order of original submission, and the ARPANET  will  not
  370.  
  371.      provide  the  same type of sequential delivery that it has in the
  372.  
  373.      past.   If  sequential  delivery  by  the  subnet  is  a   strict
  374.  
  375.      requirement,  the Short Blocking Feature should not be used.  For
  376.  
  377.      messages without this requirement, however,  the  Short  Blocking
  378.  
  379.      Feature can be used.
  380.  
  381.  
  382.      Up to now, type 0 (Regular)  messages  have  only  had  sub-types
  383.  
  384.      available  to  request  the  standard  blocking  timeout, fifteen
  385.  
  386.      seconds.  The Short Blocking Feature  makes  available  new  sub-
  387.  
  388.      types  that  allow  the  host  to  request  messages  to be short
  389.  
  390.      blocking, i.e. only cause the host to be blocked for two  seconds
  391.  
  392.      at most if the message cannot be immediately processed.
  393.  
  394.  
  395.      Type 0 messages now have the following subtypes:
  396.  
  397.  
  398.      0:  Standard: This subtype instructs the  IMP  to  use  its  full
  399.  
  400.          message  and  error  control  facilities.   The  host  may be
  401.  
  402.          blocked up to fifteen seconds during the message submission.
  403.  
  404.  
  405.      1:  Standard, Short Blocking: The IMP attempts to  use  the  same
  406.  
  407.          facilities  as  for  subtype 0, but will block the host for a
  408.  
  409.  
  410.  
  411.                                    - 6 -
  412.  
  413.  
  414.  
  415.      ARPANET Short Blocking Feature                         April 1983
  416.      RFC 852
  417.  
  418.  
  419.  
  420.          maximum of two seconds.
  421.  
  422.  
  423.      3:  Uncontrolled Packet:  The  IMP  performs  no  message-control
  424.  
  425.          functions,  and the packet is not guaranteed to be delivered.
  426.  
  427.          The host may be blocked up  to  fifteen  seconds  during  the
  428.  
  429.          packet submission, although any such blockage is unlikely.
  430.  
  431.  
  432.      4:  Uncontrolled, Short  Blocking:  The  IMP  treats  the  packet
  433.  
  434.          similarly  to  subtype  3, but will only block the host for a
  435.  
  436.          maximum of two seconds.  Again, actual blockage is unlikely.
  437.  
  438.  
  439.  
  440.  
  441.      2.2  Reasons for Host Blockage
  442.  
  443.  
  444.      There are a number of reasons why a message could  cause  a  long
  445.  
  446.      blockage  in  the  IMP,  which would result in the rejection of a
  447.  
  448.      short (or even non-short) blocking message.  The IMP signals this
  449.  
  450.      rejection of a message by using the Incomplete Transmission (Type
  451.  
  452.      9) message, using the sub-type field to indicate why the  message
  453.  
  454.      was  rejected.   The  already-existing  sub-types  for the type 9
  455.  
  456.      message are:
  457.  
  458.  
  459.      0:  The destination host  did  not  accept  the  message  quickly
  460.  
  461.          enough.
  462.  
  463.  
  464.      1:  The message was too long.
  465.  
  466.  
  467.  
  468.  
  469.  
  470.                                    - 7 -
  471.  
  472.  
  473.  
  474.      ARPANET Short Blocking Feature                         April 1983
  475.      RFC 852
  476.  
  477.  
  478.  
  479.      2:  The host took more  than  fifteen  seconds  to  transmit  the
  480.  
  481.          message  to the IMP.  This time is measured from the last bit
  482.  
  483.          of the leader through the last bit of the message.
  484.  
  485.  
  486.      3:  The message was lost in the network due  to  IMP  or  circuit
  487.  
  488.          failures.
  489.  
  490.  
  491.      4:  The IMP could not accept the entire  message  within  fifteen
  492.  
  493.          seconds  because  of unavailable resources.  This sub-type is
  494.  
  495.          only used in response to non-short blocking messages.   If  a
  496.  
  497.          short  blocking  message  timed  out, it will be responded to
  498.  
  499.          with one of sub-types 6-10.
  500.  
  501.  
  502.      5:  Source IMP  I/O  failure  occurred  during  receipt  of  this
  503.  
  504.          message.
  505.  
  506.  
  507.      The new sub-types that apply to the Short Blocking Feature are:
  508.  
  509.  
  510.      6:  Connection set-up delay: Although the IMP presents  a  simple
  511.  
  512.          message-at-a-time  interface  to  the  host,  it  provides an
  513.  
  514.          internal  connection-oriented  (virtual   circuit)   service,
  515.  
  516.          except in the case of uncontrolled packets.  Two messages are
  517.  
  518.          considered to be on the same connection if they have the same
  519.  
  520.          source  host  (i.e.,  they are submitted to the same IMP over
  521.  
  522.          the same host interface), the same  priority,  and  the  same
  523.  
  524.          destination  host  name  or  address.   The  subnet maintains
  525.  
  526.  
  527.  
  528.  
  529.                                    - 8 -
  530.  
  531.  
  532.  
  533.      ARPANET Short Blocking Feature                         April 1983
  534.      RFC 852
  535.  
  536.  
  537.  
  538.          internal  connection   set-up   and   tear-down   procedures.
  539.  
  540.          Connections  are  set  up  as  needed, and are torn down only
  541.  
  542.          after  a  period  of   inactivity.    Occasionally,   network
  543.  
  544.          congestion or resource shortage will cause a lengthy delay in
  545.  
  546.          connection set-up.  During this period, no messages for  that
  547.  
  548.          connection  can  be  accepted,  but  other  messages  can  be
  549.  
  550.          accepted.
  551.  
  552.  
  553.      7:  End-to-end flow  control:  For  every  message  that  a  host
  554.  
  555.          submits  to  an  IMP  (except  uncontrolled  packets) the IMP
  556.  
  557.          eventually  returns  a  reply  to  the  host  indicating  the
  558.  
  559.          disposition  of  the  message.   Between  the  time  that the
  560.  
  561.          message is submitted and  the  time  the  host  receives  the
  562.  
  563.          reply,  the  message  is  said to be outstanding. The ARPANET
  564.  
  565.          allows  only  eight  outstanding  messages   on   any   given
  566.  
  567.          connection.   If  there  are  eight outstanding messages on a
  568.  
  569.          given connection, and a ninth is  submitted,  it  cannot  the
  570.  
  571.          accepted.  If  a message is refused because its connection is
  572.  
  573.          blocked due to flow control, messages  on  other  connections
  574.  
  575.          can still be accepted.
  576.  
  577.  
  578.          End-to-end flow control is the  most  common  cause  of  host
  579.  
  580.          blocking in the ARPANET at present.
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.                                    - 9 -
  589.  
  590.  
  591.  
  592.      ARPANET Short Blocking Feature                         April 1983
  593.      RFC 852
  594.  
  595.  
  596.  
  597.      8:  Destination IMP buffer space shortage: If the host submits  a
  598.  
  599.          message  of  more  than  1008  bits  (exclusive of the 96-bit
  600.  
  601.          leader), buffer space at the destination IMP must be reserved
  602.  
  603.          before  the  message  can  be  accepted.  Buffer space at the
  604.  
  605.          destination IMP is always reserved on a per-connection basis.
  606.  
  607.          If  the  destination  IMP  is  heavily loaded, there may be a
  608.  
  609.          lengthy wait for the buffer space;  this  is  another  common
  610.  
  611.          cause  of  blocking  in  the  present  ARPANET.  Messages are
  612.  
  613.          rejected  for  this  reason  based  on   their   length   and
  614.  
  615.          connection;  messages  of  1008 or fewer bits or messages for
  616.  
  617.          other connections may still be acceptable.
  618.  
  619.  
  620.      9:  Congestion control: A message may be refused for  reasons  of
  621.  
  622.          congestion  control if the path via the intermediate IMPs and
  623.  
  624.          lines to the destination IMP is too heavily loaded to  handle
  625.  
  626.          additional  traffic.   Messages  to other destinations may be
  627.  
  628.          acceptable, however.
  629.  
  630.  
  631.      10: Local resource shortage: Occasionally, the source IMP  itself
  632.  
  633.          is  short  of  buffer  space,  table  entries,  or some other
  634.  
  635.          resource that it needs to accept a message.  Unlike the other
  636.  
  637.          reasons  for  message  rejection, this resource shortage will
  638.  
  639.          affect all messages equally, except for uncontrolled packets.
  640.  
  641.          The message's size or connection is not relevant.
  642.  
  643.  
  644.  
  645.  
  646.  
  647.                                   - 10 -
  648.  
  649.  
  650.  
  651.      ARPANET Short Blocking Feature                         April 1983
  652.      RFC 852
  653.  
  654.  
  655.  
  656.      The Short Blocking Feature is available  to  all  hosts  on  C/30
  657.  
  658.      IMPs,  whether they are using the 1822 or 1822L protocol, through
  659.  
  660.      the use of Type 0, sub-type 1 and 4 messages.  A host using these
  661.  
  662.      sub-types  should  be  prepared  to  correctly  handle the Type 9
  663.  
  664.      (Incomplete Transmission) messages from the IMP.
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.                                   - 11 -
  707.  
  708.  
  709.  
  710.      ARPANET Short Blocking Feature                         April 1983
  711.      RFC 852
  712.  
  713.  
  714.  
  715.      3  REFERENCES
  716.  
  717.  
  718.      [1]  Specifications for the Interconnection of a Host and an IMP,
  719.  
  720.           BBN Report 1822, December 1981 Revision.
  721.  
  722.  
  723.      [2]  A. Malis, The ARPANET 1822L Host  Access  Protocol,  Request
  724.  
  725.           for Comments 851, April 1983.
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.                                   - 12 -
  766.  
  767.  
  768.