home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 100s / rfc176.txt < prev    next >
Text File  |  1997-03-12  |  7KB  |  272 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                          A. Bhushan, MIT
  8. Request for Comments #176                      R. Kanodia, MIT
  9. NIC #7100                                      R. Metcalfe, MIT
  10. Categories: C and D                            J. Postel, UCLA
  11.                                                14 June 1971
  12.  
  13.  
  14.  
  15.                  Comments on Byte Size for Connections
  16.                  -------------------------------------
  17.  
  18.  
  19.  
  20.      There are at least the following three views on the use of
  21. byte size for network connections*:
  22.  
  23.      1)   Byte size should not be used at all.
  24.  
  25.      2)   Byte size is solely for the convenience of NCP's.
  26.  
  27.      3)   Byte size choice is a user-level prerogative.
  28.  
  29.  
  30.      According to the first view, network connections are bit
  31. streams, and messages should contain bit counts (i.e., a
  32. byte size of 1).  This view existed before the "Glitch Cleaning"
  33. of RFC 107, and was discarded in favour of byte stream because
  34. of stated reasons of efficiency in storage management and
  35. message concatenation.
  36.  
  37.      The second view represents a special interpretation of
  38. RFC 107.  According to this interpretation, byte size is
  39. entirely a 2nd level (i.e., NCP) issue.  There is no require-
  40. ment that 3rd level user processes be able to specify byte size.
  41. This view is indicated in RFC 151 by Shoshani.
  42.  
  43.  
  44.  
  45.  
  46.  
  47. ----------------------
  48. * Byte size for connection is the byte size selected by
  49. sending NCP, as explained in RFC 107 (Output of Host-Host
  50. Protocol Glitch Cleaning Committee).
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60. RFC #176                        -2-                   NIC #7100
  61.  
  62.  
  63.      According to the third view user processes are always
  64. allowed to choose byte size for connection, either explicitly
  65. (specify a specific byte size parameter) or implicitly (byte
  66. size depends on I/O mode).  An NCP is allowed to use a default
  67. byte size, if the user does not specify it.
  68.  
  69.  
  70.                             The Correct View
  71.                             ________________
  72.  
  73.  
  74.      The third view should be considered the correct interpre-
  75. tation of RFC 107.  In fact, RFC 107 states on page 2, "the
  76. choice of the byte size for a connection is a 3rd level protocol
  77. issue."   To be consistent with TELNET, ICP, and other 3rd
  78. level protocols which require that a specific byte size be
  79. used for connection, it is imperative that corresponding 3rd
  80. level processes be able to specify (and_impose) a particular
  81. byte size to the NCP.  NCP implementors should take note of it.
  82.  
  83.  
  84.          On Specifying Fixed Byte Sizes in 3rd Level Protocols
  85.          -----------------------------------------------------
  86.  
  87.  
  88.      Holding the view that byte size choice is a 3rd level
  89. issue, we are still faced with the following two questions.
  90. First, is it appropriate for 3rd level protocols to legislate
  91. a specific byte size for all connections using that protocol?
  92. Second, if it is appropriate to specify byte size, then what
  93. should this choice be?
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113. RFC #176                        -3-                   NIC #7100
  114.  
  115.  
  116.  
  117.  
  118.      There are two arguments in favour of using specific
  119. byte size in 3rd level protocols.  First is that a potential
  120. mismatch problem exists because RFC 107 does not require
  121. that NCPs be capable of handling all byte sizes 1 through 255.
  122. Using a fixed byte size of 8-bits or 8-bit multiples resolves
  123. the problem as this is acceptable to all hosts (including
  124. terminal IMPs).
  125.  
  126.  
  127.  
  128.      The second argument is one of efficiency.  If it is agreed
  129. before hand that only a specific byte size would be used,
  130. it is possible to make programs more efficient (i.e., reduce
  131. program space, and possibly run time).  The efficiency argument
  132. assumes that the byte size for connection represents the natural
  133. byte structure of data being transferred over the connection.
  134.  
  135.  
  136.  
  137.      For TELNET and ICP, the byte size choice is straight
  138. forward as data is naturally in 8-bit multiples (8-bit ASCII
  139. characters in TELNET, and 32-bit socket numbers in ICP).  But
  140. for data transfer protocols, the byte size choice is more complex,
  141. as data may be structured in a variety of byte sizes.  Specifying
  142. a byte size for a data transfer connection reduces efficiency
  143. in instances where connection byte size does not correspond
  144. to data byte size.  Further, filler fields will be required
  145. for data blocks which are not a multiple of the fixed byte
  146. size.  This imposes an additional overhead.
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.                                                                 [Page 3]
  165.  
  166. RFC #176                        -4-                   NIC #7100
  167.  
  168.  
  169.  
  170.  
  171.      Even if all hosts were to accept arbitrary byte sizes,
  172. and the 3rd level protocol does not legislate a specific byte
  173. size, the inefficiency problem will not be solved entirely.
  174. Under current specifications "the byte size is fixed for the
  175. life of a connection".*  This means that byte size cannot be
  176. varied during the life of a connection even if structure of
  177. data varies.  The problem of inefficiency is solved only for
  178. instances in which data has a constant byte structure.
  179.  
  180.  
  181.  
  182.      Given the current state of the network, it appears that
  183. specifying fixed byte size in 3rd level protocols is a good
  184. idea.  This eliminates the potential byte size mismatch problem,
  185. and improves efficiency at least for TELNET and ICP.  In data
  186. transfer, the efficiency issue is more complex, as discussed
  187. earlier.  It is not clear that overall efficiency would be
  188. degraded if a fixed byte size was required.
  189.  
  190.  
  191.  
  192.                     On Reopening the Byte Size Issue
  193.                     --------------------------------
  194.  
  195.  
  196.  
  197.      The above discussion exposes certain weaknesses in the
  198. efficiency arguments for having byte streams on network connec-
  199. tions.  In moving from bit stream to byte stream, we may have
  200. lost generality, and it is not clear how much overall efficiency
  201. is gained.  Sometimes, the gain in NCP efficiency may be at the
  202. expense of user process efficiencies.
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211. --------------------
  212.  
  213. *    RFC 107, page 2
  214.  
  215.  
  216.  
  217.                                                                 [Page 4]
  218.  
  219. RFC #176                        -5-                   NIC #7100
  220.  
  221.  
  222.  
  223.  
  224.      It is also clear that for efficiency arguments to hold,
  225. the byte size choice should not be an NCP prerogative.  It
  226. is the combined efficiency, rather than NCP efficiency which
  227. should be our primary concern.  Restricting byte size choice
  228. to NCPs has the further disadvantage of potential byte size
  229. mismatch not only between communicating NPCs but also at the
  230. user-NCP interface.  Therefore, allowing a user process to
  231. specify byte size is a step in the right direction, given
  232. that we have adopted byte streams.
  233.  
  234.      It is our opinion that the issue of bit stream and byte
  235. stream be set aside until serious consideration can be given
  236. to a major Host-Host Protocol overhaul.  At a later stage
  237. we will have a better idea of the relative efficiency merits.
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.        [ This RFC was put into machine readable form for entry ]
  248.        [ into the online RFC archives by BBN Corp. under the   ]
  249.        [ direction of Alex McKenzie.                   12/96   ]
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.                                                                 [Page 5]
  271.  
  272.