1 files changed, 271 insertions, 0 deletions
diff --git a/doc/rfc/rfc176.txt b/doc/rfc/rfc176.txt
new file mode 100644
index 0000000..7a08eb6
--- /dev/null
+++ b/doc/rfc/rfc176.txt
@@ -0,0 +1,271 @@
+
+
+
+
+
+
+Network Working Group                          A. Bhushan, MIT
+Request for Comments #176                      R. Kanodia, MIT
+NIC #7100                                      R. Metcalfe, MIT
+Categories: C and D                            J. Postel, UCLA
+                                               14 June 1971
+
+
+
+                 Comments on Byte Size for Connections
+                 -------------------------------------
+
+
+
+     There are at least the following three views on the use of
+byte size for network connections*:
+
+     1)   Byte size should not be used at all.
+
+     2)   Byte size is solely for the convenience of NCP's.
+
+     3)   Byte size choice is a user-level prerogative.
+
+
+     According to the first view, network connections are bit
+streams, and messages should contain bit counts (i.e., a
+byte size of 1).  This view existed before the "Glitch Cleaning"
+of RFC 107, and was discarded in favour of byte stream because
+of stated reasons of efficiency in storage management and
+message concatenation.
+
+     The second view represents a special interpretation of
+RFC 107.  According to this interpretation, byte size is
+entirely a 2nd level (i.e., NCP) issue.  There is no require-
+ment that 3rd level user processes be able to specify byte size.
+This view is indicated in RFC 151 by Shoshani.
+
+
+
+
+
+----------------------
+* Byte size for connection is the byte size selected by
+sending NCP, as explained in RFC 107 (Output of Host-Host
+Protocol Glitch Cleaning Committee).
+
+
+
+
+
+
+
+                                                                [Page 1]
+
+RFC #176                        -2-                   NIC #7100
+
+
+     According to the third view user processes are always
+allowed to choose byte size for connection, either explicitly
+(specify a specific byte size parameter) or implicitly (byte
+size depends on I/O mode).  An NCP is allowed to use a default
+byte size, if the user does not specify it.
+
+
+                            The Correct View
+                            ________________
+
+
+     The third view should be considered the correct interpre-
+tation of RFC 107.  In fact, RFC 107 states on page 2, "the
+choice of the byte size for a connection is a 3rd level protocol
+issue."   To be consistent with TELNET, ICP, and other 3rd
+level protocols which require that a specific byte size be
+used for connection, it is imperative that corresponding 3rd
+level processes be able to specify (and_impose) a particular
+byte size to the NCP.  NCP implementors should take note of it.
+
+
+         On Specifying Fixed Byte Sizes in 3rd Level Protocols
+         -----------------------------------------------------
+
+
+     Holding the view that byte size choice is a 3rd level
+issue, we are still faced with the following two questions.
+First, is it appropriate for 3rd level protocols to legislate
+a specific byte size for all connections using that protocol?
+Second, if it is appropriate to specify byte size, then what
+should this choice be?
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 2]
+
+RFC #176                        -3-                   NIC #7100
+
+
+
+
+     There are two arguments in favour of using specific
+byte size in 3rd level protocols.  First is that a potential
+mismatch problem exists because RFC 107 does not require
+that NCPs be capable of handling all byte sizes 1 through 255.
+Using a fixed byte size of 8-bits or 8-bit multiples resolves
+the problem as this is acceptable to all hosts (including
+terminal IMPs).
+
+
+
+     The second argument is one of efficiency.  If it is agreed
+before hand that only a specific byte size would be used,
+it is possible to make programs more efficient (i.e., reduce
+program space, and possibly run time).  The efficiency argument
+assumes that the byte size for connection represents the natural
+byte structure of data being transferred over the connection.
+
+
+
+     For TELNET and ICP, the byte size choice is straight
+forward as data is naturally in 8-bit multiples (8-bit ASCII
+characters in TELNET, and 32-bit socket numbers in ICP).  But
+for data transfer protocols, the byte size choice is more complex,
+as data may be structured in a variety of byte sizes.  Specifying
+a byte size for a data transfer connection reduces efficiency
+in instances where connection byte size does not correspond
+to data byte size.  Further, filler fields will be required
+for data blocks which are not a multiple of the fixed byte
+size.  This imposes an additional overhead.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 3]
+
+RFC #176                        -4-                   NIC #7100
+
+
+
+
+     Even if all hosts were to accept arbitrary byte sizes,
+and the 3rd level protocol does not legislate a specific byte
+size, the inefficiency problem will not be solved entirely.
+Under current specifications "the byte size is fixed for the
+life of a connection".*  This means that byte size cannot be
+varied during the life of a connection even if structure of
+data varies.  The problem of inefficiency is solved only for
+instances in which data has a constant byte structure.
+
+
+
+     Given the current state of the network, it appears that
+specifying fixed byte size in 3rd level protocols is a good
+idea.  This eliminates the potential byte size mismatch problem,
+and improves efficiency at least for TELNET and ICP.  In data
+transfer, the efficiency issue is more complex, as discussed
+earlier.  It is not clear that overall efficiency would be
+degraded if a fixed byte size was required.
+
+
+
+                    On Reopening the Byte Size Issue
+                    --------------------------------
+
+
+
+     The above discussion exposes certain weaknesses in the
+efficiency arguments for having byte streams on network connec-
+tions.  In moving from bit stream to byte stream, we may have
+lost generality, and it is not clear how much overall efficiency
+is gained.  Sometimes, the gain in NCP efficiency may be at the
+expense of user process efficiencies.
+
+
+
+
+
+
+
+
+--------------------
+
+*    RFC 107, page 2
+
+
+
+                                                                [Page 4]
+
+RFC #176                        -5-                   NIC #7100
+
+
+
+
+     It is also clear that for efficiency arguments to hold,
+the byte size choice should not be an NCP prerogative.  It
+is the combined efficiency, rather than NCP efficiency which
+should be our primary concern.  Restricting byte size choice
+to NCPs has the further disadvantage of potential byte size
+mismatch not only between communicating NPCs but also at the
+user-NCP interface.  Therefore, allowing a user process to
+specify byte size is a step in the right direction, given
+that we have adopted byte streams.
+
+     It is our opinion that the issue of bit stream and byte
+stream be set aside until serious consideration can be given
+to a major Host-Host Protocol overhaul.  At a later stage
+we will have a better idea of the relative efficiency merits.
+
+
+
+
+
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by BBN Corp. under the   ]
+       [ direction of Alex McKenzie.                   12/96   ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+