Movatterモバイル変換

Network Working Group                          A. Bhushan, MITRequest for Comments #176                      R. Kanodia, MITNIC #7100                                      R. Metcalfe, MITCategories: C and D                            J. Postel, UCLA                                               14 June 1971Comments on Byte Size for Connections-------------------------------------     There are at least the following three views on the use ofbyte 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 bitstreams, and messages should contain bit counts (i.e., abyte size of 1).  This view existed before the "Glitch Cleaning"ofRFC 107, and was discarded in favour of byte stream becauseof stated reasons of efficiency in storage management andmessage concatenation.     The second view represents a special interpretation ofRFC 107.  According to this interpretation, byte size isentirely 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 inRFC 151 by Shoshani.----------------------* Byte size for connection is the byte size selected bysending NCP, as explained inRFC 107 (Output of Host-HostProtocol Glitch Cleaning Committee).                                                                [Page 1]

RFC #176                        -2-                   NIC #7100     According to the third view user processes are alwaysallowed to choose byte size for connection, either explicitly(specify a specific byte size parameter) or implicitly (bytesize depends on I/O mode).  An NCP is allowed to use a defaultbyte size, if the user does not specify it.                            The Correct View                            ________________     The third view should be considered the correct interpre-tation ofRFC 107.  In fact,RFC 107 states on page 2, "thechoice of the byte size for a connection is a 3rd level protocolissue."   To be consistent with TELNET, ICP, and other 3rdlevel protocols which require that a specific byte size beused for connection, it is imperative that corresponding 3rdlevel processes be able to specify (and_impose) a particularbyte 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 levelissue, we are still faced with the following two questions.First, is it appropriate for 3rd level protocols to legislatea specific byte size for all connections using that protocol?Second, if it is appropriate to specify byte size, then whatshould this choice be?                                                                [Page 2]

RFC #176                        -3-                   NIC #7100     There are two arguments in favour of using specificbyte size in 3rd level protocols.  First is that a potentialmismatch problem exists becauseRFC 107 does not requirethat NCPs be capable of handling all byte sizes 1 through 255.Using a fixed byte size of 8-bits or 8-bit multiples resolvesthe problem as this is acceptable to all hosts (includingterminal IMPs).     The second argument is one of efficiency.  If it is agreedbefore hand that only a specific byte size would be used,it is possible to make programs more efficient (i.e., reduceprogram space, and possibly run time).  The efficiency argumentassumes that the byte size for connection represents the naturalbyte structure of data being transferred over the connection.     For TELNET and ICP, the byte size choice is straightforward as data is naturally in 8-bit multiples (8-bit ASCIIcharacters in TELNET, and 32-bit socket numbers in ICP).  Butfor data transfer protocols, the byte size choice is more complex,as data may be structured in a variety of byte sizes.  Specifyinga byte size for a data transfer connection reduces efficiencyin instances where connection byte size does not correspondto data byte size.  Further, filler fields will be requiredfor data blocks which are not a multiple of the fixed bytesize.  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 bytesize, the inefficiency problem will not be solved entirely.Under current specifications "the byte size is fixed for thelife of a connection".*  This means that byte size cannot bevaried during the life of a connection even if structure ofdata varies.  The problem of inefficiency is solved only forinstances in which data has a constant byte structure.     Given the current state of the network, it appears thatspecifying fixed byte size in 3rd level protocols is a goodidea.  This eliminates the potential byte size mismatch problem,and improves efficiency at least for TELNET and ICP.  In datatransfer, the efficiency issue is more complex, as discussedearlier.  It is not clear that overall efficiency would bedegraded if a fixed byte size was required.                    On Reopening the Byte Size Issue                    --------------------------------     The above discussion exposes certain weaknesses in theefficiency arguments for having byte streams on network connec-tions.  In moving from bit stream to byte stream, we may havelost generality, and it is not clear how much overall efficiencyis gained.  Sometimes, the gain in NCP efficiency may be at theexpense 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.  Itis the combined efficiency, rather than NCP efficiency whichshould be our primary concern.  Restricting byte size choiceto NCPs has the further disadvantage of potential byte sizemismatch not only between communicating NPCs but also at theuser-NCP interface.  Therefore, allowing a user process tospecify byte size is a step in the right direction, giventhat we have adopted byte streams.     It is our opinion that the issue of bit stream and bytestream be set aside until serious consideration can be givento a major Host-Host Protocol overhaul.  At a later stagewe 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]