rfc914.txt

RFC 的详细文档！

Network Working Group                                    David J. Farber
Request for Comments: 914                                   Gary S. Delp
                                                         Thomas M. Conte
                                                  University of Delaware
                                                          September 1984

                          A Thinwire Protocol
                   for connecting personal computers
                            to the INTERNET

Status of this Memo

   This RFC focuses discussion on the particular problems in the
   ARPA-Internet of low speed network interconnection with personal
   computers, and possible methods of solution.  None of the proposed
   solutions in this document are intended as standards for the
   ARPA-Internet.  Rather, it is hoped that a general consensus will
   emerge as to the appropriate solution to the problems, leading
   eventually to the adoption of standards.  Distribution of this memo
   unlimited.

What is the Problem Anyway ?

   As we connect workstations and personal computers to the INTERNET,
   many of the cost/speed communication tradeoffs change.  This has made
   us reconsider the way we juggle the protocol and hardware design
   tradeoffs.  With substantial computing power available in the $3--10K
   range, it is feasible to locate computers at their point of use,
   including in buildings, in our homes, and other places remote from
   the existing high speed connections.  Dedicated 56k baud lines are
   costly, have limited availability, and long lead time for
   installation.  High speed LAN's are not an applicable interconnection
   solution.  These two facts ensure that readily available 1200 / 2400
   baud phone modems over dialed or leased telephone lines will be an
   important part of the interconnection scheme in the near future.
   This paper will consider some of the problems and possibilities
   involved with using a "thin" (less than 9600 baud) data path.  A trio
   of "THINWIRE"  protocols for connecting a personal computer to the
   INTERNET are presented for discussion.

   Although the cost and flexibility of telephone modems is very
   attractive, their low speed produces some major problems.  As an
   example, a minimum TCP/IP Telnet packet (one character) is 41 bytes
   long.  At 1200 baud, the transmission time for such a packet would be
   around 0.3 seconds.  This is equivalent to using a 30 baud line for
   single character transmission.  (Throughout the paper, the assumption
   is made that the transmission speed is limited only by the speed of
   the communication line.  We also assume that the line will act as a
   synchronous link when calculating speed.  In reality, with interrupt,
   computational, and framing overhead, the times could be 10-50%
   worse.)

   In many cases, local echo and line editing can allow acceptable


Farber & Delp & Conte                                           [Page 1]



RFC 914                                                   September 1984
Thinwire Protocol


   Telnet behavior, but many applications will work only with character
   at a time transmission.  In addition, multiple data streams can be
   very useful for fully taking advantage of the personal
   computer/Internet link.  Thus this proposal.

   There are several forms that a solution to this problem can take.
   Three of these are listed below, followed by descriptions of possible
   solutions of each form.

   o    As a non-solution, one can learn to live with the slow
        communication (possibly a reasonable thing to do for background
        file transfer and one-time inquiries to time, date, or
        quote-of-the-day servers).

   o    Using TCP/IP, one can intercept the link level transmissions,
        and try various kinds of compression algorithms.  This provides
        for a symmetrical structure on either side of the "Thinwire".

   o    One could build an "asymmetrical" gateway which takes some of
        the transport and network communication overhead away from both
        the serial link and the personal computer.  The object would be
        to make the PC do the local work, and to make the
        interconnection with the extended network a benefit to the PC
        and not a drain on the facilities of the PC.

   The first form has the advantage of simplicity and ease of
   implementation. The disadvantages have been discussed above.  The
   second form, compression at link level, can be exploited in two ways.

      Thinwire I is a simple robust compressor, which will reduce the 41
      byte minimum TCP/IP Telnet packets to a series of 17 byte update
      packets.  This would improve the effective baud rate from 30 baud
      to 70 baud over a 1200 baud line (for single character packets).

      Thinwire II uses a considerably more complex technique, and takes
      advantage of the storage and processing power on either side of
      the thinwire link.  Thinwire II will compress packets from
      multiple TCP/IP connections from 41 bytes down to 13 bytes.  The
      increased communication rate is 95 (effective) baud for single
      character packets.

   The third form balances the characteristics of the personal computer,
   the communications line, the gateway, and the Internet protocols to
   optimize the utility of the communications and the workstation
   itself.  Instead of running full transport and internet layers on the
   PC, the PC and the gateway manage a single reliable stream,
   multiplexing data on this stream with control requests.  Without the
   interneting and flow control structures traveling over the
   communications line on a per/packet basis, the data flow can be


Farber & Delp & Conte                                           [Page 2]



RFC 914                                                   September 1984
Thinwire Protocol


   compressed a great deal.  As there is some switching overhead, and a
   reliable link level protocol is needed on the serial line, the
   average effective baud rate would be in the 900 baud range.

   Each of these Thinwire possibilities will be explored in detail.

Thinwire I

   The simplest technique for the compression of packets which have
   similar headers is for both the transmitting and receiving host to
   store the most recent packet and transmit just the changes from one
   packet to the next.  The updated information is transmitted by
   sending a packet including the updated information along with a
   description of where the information should be placed.  A series of
   descriptor-data blocks would make up the update packet.  The
   descriptor consists of the offset from the last byte changed to the
   start of the data to be changed and a count of the number of data
   bytes to be substituted into the old template.  The descriptor is one
   byte long, with two four bit fields; offsets and counts of up to 15
   bytes can be described. In the most pathological case the descriptor
   adds an extra byte for every 15 bytes (or a 6% expansion).

   An example of Thinwire I in action is shown in Appendix A.  A
   sequence of two single character TCP/IP Telnet packets is shown.  The
   "update" packet which would actually be transmitted is shown
   following them.  Each Telnet packet is 41 bytes long; the typical
   update is 17 bytes.  This technique is a useful improvement over
   sending entire packets.  It is also computationally simple.  It
   suffers from two problems: the compression is modest, and, if there
   is more than one class of packets being handled, the assumption of
   common header information breaks down, causing the compression of
   each class to suffer.

Thinwire II

   Both of the problems described above suggest that a more
   computationally complex protocol may be appropriate.  Any major
   improvement in data compression must depend on knowledge of the
   protocols being used.  Thinwire II uses this knowledge to accomplish
   two things.  First, the packets are sorted into classes.  The packets
   from each TCP connection using the thinwire link, would, because of
   their header similarities, make up a class of packets.  Recognizing
   these classes and sorting by them is called "matching templates".
   Second, knowledge of the protocols is used to compress the updates.
   A bitfield indicating which fields in the header have changed,
   followed only by the changed fields, is much shorter than the general
   form of change notices.  Simple arithmetic is allowed, so 32 bit




Farber & Delp & Conte                                           [Page 3]



RFC 914                                                   September 1984
Thinwire Protocol


   fields can often be updated in 8 or 16 bits.  By using the sorting,
   protocol-specific updating, Thinwire II provides significant
   compression.

   A typical transaction is described in Appendix B.  The "template
   matching" is based on the unchanging fields in each class of packet.
   A TCP/IP packet would match on the following fields: network type
   field(IP), version, type of service, protocol(TCP), and source and
   destination address and port.  Note that the 41 bytes have been
   reduced to 13 bytes.  An additional advantage is that  multiple
   classes of packets can be transported across the same line without
   affecting the compression of each other, just by matching and storing
   multiple templates.

   Some of the implications of this system are:

      o    The necessity of saving several templates (one for each
           TCP/IP connection ) means that there will be a relatively
           large memory requirement.  This requirement for current
           personal computers is reasonable.  In addition, the gateway
           must keep tables for several connections at a time.

      o    The Thinwire links are slow (that's why we call them thin);
           much slower than normal disk access.  There is no reason that
           inactive templates cannot be swapped out to disk and
           retrieved when needed if memory is limited.  (Note that as
           memory density increases, this is less and less of a
           problem.)

      o    There is state information in the connections.  If the two
           sides get out of synchronization with each other, data flow
           stops.  This means that some method of error detection and
           recovery must be provided.

      o    To minimize the problem described above, the protocol used on
           the serial line must be reliable.  See Appendix D for details
           of SLIP, Serial Line Interface Protocol, as an example of
           such a protocol.  There must also be periodic
           resynchronization.  (For example, every Nth packet would be
           transmitted in full).

      o    The asynchronous link is not, by its nature, a packet
           oriented system; a packet structure will need to be layered
           on the character at a time transfer.  However, if the
           protocol layer below thinwire (SLIP) can be trusted, the
           formation of packets is a simple matter.

      o    Thinwire II will need to be enhanced for each new protocol



Farber & Delp & Conte                                           [Page 4]



RFC 914                                                   September 1984
Thinwire Protocol


           (TCP, UDP, TP4) it is called upon to service.  Any packet
           type not recognized by the Thinwire connection will be
           transmitted in full.

   For maintaining full network service, Thinwire II or a close variant
   seems to be the solution.

Thinwire III

   When transmissions at the local network (link) level are not
   required, if only the available services are desired, then a solution
   based on Thinwire III may be appropriate.  A star network with a
   gateway in the center serving as the connection between a number of
   Personal Computers and the Internet is the key of Thinwire III.
   Rather than providing connections at the network/link level, Thinwire
   III assumes that there is a reliable serial link (SLIP or equivalent)
   beneath it and that the workstation/personal computer has better
   things to do than manage TCP state tables, timeouts, etc.  It also
   assumes that the gateway supporting the Thinwire III connections is
   powerful enough to run many TCP connections and several SLIP's at the
   same time.  The gateway fills in for the limitations of the
   communications line and the personal computer.  It provides a gateway
   to the INTERNET, managing the transport and network functions,
   providing both reliable stream and datagram service.

   In Thinwire III, the gateway starts an interpreter for each SLIP
   connection from a personal computer.  The gateway will open TCP, UDP,
   and later TP4 connections on the request of the personal computer.
   Acting as the agent for the personal computer, it will manage the
   remote negotiations and the data flow to and from the personal
   computer.  Multiple connections can be opened, with inline logical
   switches in the reliable data flow indicating which connection the
   data is destined for.  Additional escaped sequences will send error
   and informational data between the two Thinwire III communicators.

   This protocol is not symmetric.  The gateway will open connections to
   the INTERNET world as an agent for the personal computer, but the
   gateway will not be able to open inbound connections to the personal
   computer, as the personal computer is perceived as a stub host.  The
   personal computer may however passively open connections on the
   gateway to act as a server.  Extended control sequences are specified
   to handle the multiple connection negotiation that this server
   ability will entail.

   This protocol seems to ignore the problem of flow control. Our
   thought is that the processing on either side of the communication
   link will be much speedier than the link itself.  The buffering for
   the communication line and the user process blocking for this will



Farber & Delp & Conte                                           [Page 5]



RFC 914                                                   September 1984
Thinwire Protocol


   provide most of the flow control.  For the rare instances that this
   is not sufficient, there are control messages to delay the flow to a
   port or all data flow.

   A tentative specification for Thinwire III is attached as Appendix C.

The authors acknowledge the shoulders upon which they stand, and
apologize for the toes they step on.  Ongoing work is being done by Eric
Thayer, Guru Parulkar, and John Jaggers.  Special thanks are extended to
Peter vonGlahn, Jon Postel and Helen Delp for their helpful comments on
earlier drafts.  Responses will be greatly appreciated at the following
addresses:

   Dave Farber <Farber@udel-ee>
   Gary Delp <Delp@udel-ee>
   Tom Conte <Conte@udel-ee>