rfc935.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 774 行 · 第 1/3 页

   For point-point operation, the address is clearly superfluous (except
   to distinguish commands and replies in bit-oriented protocols); one
   might imagine dispensing with it.

The Asynchronous Environment

   Which of these protocols is best for the asynchronous environment?
   This depends on the definition of "best", of course.  One means of
   judging is to compare the amount of overhead that each protocol would
   add to each frame sent.

   We will examine the overhead costs in two groups:

      framing/transparency/error checking,

      and addressing/control.

   The two groups of functions are independent of each other, even
   though the protocols mentioned above use specific combinations of
   techniques from these two groups.  Also, hardware available on
   minicomputer-class and larger machines today supports the first group
   of functions completely for these standard protocols; this fact
   should allow for far greater performance from the gateway machine.


Robinson                                                        [Page 5]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   To the extent that such hardware becomes available for personal
   computers, it can also be used there to reduce the protocol
   processing overhead.  Here's a breakdown of framing costs in
   characters.  RATP is also included for comparison.

      Protocol   Frame   Check  Transp.  Total    F+C

      char-or.     4       2       2       8       6
      bit-or.      1       2       2       5       3
      DDCMP        4       4       0       8       8
      RATP         2       3       0       5       5

   The transparency column indicates the anticipated cost in inserted
   characters to achieve transparency across a 256-byte frame.  The
   figure for bit-oriented protocols is a pessimistic guess, because I
   don't know the exact answer; it is between 0 and 8 characters, with
   the worst case occurring when the data is all one bits.  For
   character-oriented protocols, we would expect on average one DLE
   character in a 256-byte frame; the worst case overhead (256 DLEs) is
   256 bytes.

   Because transparency is so much a function of the user data, and
   because we have ignored the cost of loss of frame synchronization in
   the counting protocols (DDCMP and RATP), I argue that we should base
   the comparison on the frame and checksum costs only.  For these two
   columns, character-oriented framing costs one more character per
   frame than RATP. This, plus its wide use and hardware chip support,
   create a strong case for its use in preference to RATP for framing.

   Bit-oriented framing, as noted previously, is appropriate only on
   synchronous links.  The character oriented variant I postulated above
   would have the same costs, but as it is not a standard, it is not
   proposed here.  So we now have constructed the following frame
   format:

      DLE STX <control and data ...> DLE ETX CRC CRC

   One objection to using character-oriented protocols as opposed to
   character-count protocols is that it is necessary to examine every
   character as it arrives.  I respond to this objection as follows:

      1.  Under some circumstances, such as when a header has been hit
      with an error, it will be necessary for the receiver to look at
      every character anyway.

      2.  The environment for this protocol is a 1200 baud link; thus



Robinson                                                        [Page 6]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


      120 characters per second need to be examined at a maximum.  Even
      on a relatively slow personal computer, this should not present a
      problem.

   We now turn our attention to the content and format of the control
   information preceding each link frame.  There are three components to
   this cost, control, address, and acknowledgment.  The address field
   allows multipoint configurations and is superfluous for the
   point-to-point environment proposed, but it is present in the public
   standards and we restrict ourselves to those.

   Acknowledgments are shown if they are required explicitly by the
   protocol.  A "0" indicates that the acknowledgments may be included
   in the control information for traffic in the opposite direction, and
   only need be sent explicitly when no reverse traffic is present (and
   thus are assumed to take no required overhead).  Only
   character-oriented protocols have required acknowledgments.

                 Cont.   Addr.    Ack    Total
      char-or.     0       3       2       5
      bit-or.      1       1       0       2
      DDCMP        3       1       0       4
      RATP         1       0       0       1

   Again, the bit-oriented procedures provide the lowest overhead among
   the public standards, but in this case there is no conflict in using
   them in the asynchronous environment.  In fact, even if all the other
   aspects of RATP were to be adopted, I believe the control field
   codings of the bit- oriented procedures represent a more efficient
   use of the channel, are widely implemented, and allow for addition of
   more functions later if desired.  As stated above, there are several
   protocols in the bit-oriented family.  I would recommend use of LAPB,
   since this is the most widely known of the family.

   For those not familiar with bit-oriented control procedures, I have
   included a quick summary of these procedures in Appendix A.  Refer to
   the standards listed at the end of this note for more detail.












Robinson                                                        [Page 7]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


RATP Compared to Public Protocols

   As can be seen from the above tables, RATP does not represent a
   significant savings compared to other widely-used protocols.

   Given frame lengths of 13 bytes, which appears to be the minimum for
   Thinwire II (RFC 914), 8 characters' overhead using the public
   standards represents 61% versus 46% for RATP's 6 characters.  On a
   1200 baud line, the bandwidth available assuming only such short
   frames is thus 74 versus 82 characters per second, respectively.
   Since 1/13 of these are actually user data, the typing rates
   supported by these protocols using TCP/IP are pretty low, like 5.6
   versus 6.3 characters per second.  Clearly a bigger cost is still
   found in the 12 characters overhead in Thinwire II (or 40 for TCP/IP
   with no compression).

   The costs improve dramatically when the number of user characters per
   frame increases.  Thus, file transfer, or even line-blocked typing,
   should perform adequately.  As frame size grows, the cost of the
   extra 2 characters per frame to use standard protocols rapidly drops
   to a few percent or less.

   RATP does allow one optimization which cannot be achieved in the
   standard protocols - the use of a one-character format that reduces
   the per-frame overhead to 3 characters (or 4 if a 16-bit CRC is
   used).  However, in the scenario wherein single-character messages
   make sense, a user typing characters (with no higher layer
   protocols), the extra overhead is probably not a problem since the
   link is still lightly enough loaded that the extra overhead is still
   a small percentage of the available bandwidth.  Also, allowing
   multiple frames in flight helps reduce the bottleneck caused by
   having one frame at a time outstanding.

On Check Sequences

   Both RFCs 914 and 916 propose to use relatively simple check
   sequences, which can be easily computed in a general-purpose
   processor.  In one case, this is an additive check and in the other
   it is an exclusive-or (or parity) check.  Although the additive check
   is slightly more powerful than the exclusive-or, both are relatively
   weak compared to CRC techniques.

   Since the intended network-layer protocol (IP) provides for similar
   checks on its header, and the transport layer (TCP) checksums its
   header and data, one might question whether the protection should
   also be provided at the link layer at all, or if it should, then are
   these checks good enough?  Providing for recovery at the TCP layer


Robinson                                                        [Page 8]



RFC 935                                                     January 1985
Reliable Link Layer Protocols


   leads to slow recovery times, so this approach will probably yield
   too poor a level of service for noisy links.  More importantly, the
   link layer control field needs a certain degree of protection to
   prevent needless loss or duplication of frames in the face of line
   errors.

   A CRC check, in combination with the additive checks provided by IP
   and TCP, yield an error-protection that is greater than that afforded
   by either check by itself.  This is because the two techniques
   address fundamentally different characteristics of the possible
   errors.  The degree of increase is substantial compared to that of
   two additive checks.  That is, if two additive checks are cascaded,
   there are many types of two-bit failures that will pass both the link
   layer and TCP/IP checking.

   Although I don't wish to include a detailed error analysis in this
   note, I would support the use of a CRC type of error check because of
   the far greater level of protection it affords.  As I pointed out,
   the cost per character is roughly 5-6 instructions, assuming the use
   of a 256 by 16-bit lookup table.  Again, at 120 characters per
   second, the increased cost is not deemed to be too great.

   Moreover, use of a standard CRC allows for the possibility that the
   serial line chip's own CRC generation and checking hardware may be
   used.  Although such chips may not be present in the PCs in the
   environment envisioned, they are likely to be available in the
   gateway machine to which the PCs talk.

Data Compression: An Aside

   I find the proposed methods of data compression of RFC 914
   particularly interesting.  I see these as independent of the choice
   of the underlying link layer protocol, as it is in RFC 914.  I am
   aware of no such character-oriented compression that is in common use
   in the communication world.  The only techniques that come close are
   in statistical multiplexing devices, which sometimes also include an
   adaptive Huffman-coding to reduce link bandwidth.  Since the Thinwire
   II approach can recognize much longer repeated sequences than a
   Huffman code, I expect that the potential savings are correspondingly
   greater.

   I would like to see a version of the Thinwire protocols which allows
   for the template idea, but which keeps it independent of the higher
   layer protocols in use.  One way to achieve this is to allow
   templates to be encoded and exchanged between the communicating
   parties when they start up, and perhaps adaptively as conditions
   warrant.  I would anticipate that this sort of approach might well


Robinson                                                        [Page 9]