rfc1144.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   4.2  Error recovery

   The previous section noted that after a CRC error the decompressor will
   introduce TCP checksum errors in every uncompressed packet.  Although
   the checksum errors prevent data stream corruption, the TCP conversation
   won't be terribly useful until the decompressor again generates valid
   packets.  How can this be forced to happen?

   The decompressor generates invalid packets because its state (the saved
   `last packet header') disagrees with the compressor's state.  An
   UNCOMPRESSED_TCP packet will correct the decompressor's state.  Thus
   error recovery amounts to forcing an uncompressed packet out of the
   compressor whenever the decompressor is (or might be) confused.

   The first thought is to take advantage of the full duplex communication
   link and have the decompressor send something to the compressor
   requesting an uncompressed packet.  This is clearly undesirable since it
   constrains the topology more than the minimum suggested in sec. 2 and
   requires that a great deal of protocol be added to both the decompressor
   and compressor.  A little thought convinces one that this alternative is
   not only undesirable, it simply won't work:  Compressed packets are
   small and it's likely that a line hit will so completely obliterate one
   that the decompressor will get nothing at all.  Thus packets are
   reconstructed incorrectly (because of the missing compressed packet) but
   only the TCP end points, not the decompressor, know that the packets are
   incorrect.

   But the TCP end points know about the error and TCP is a reliable
   protocol designed to run over unreliable media.  This means the end
   points must eventually take some sort of error recovery action and
   there's an obvious trigger for the compressor to resync the
   decompressor:  send uncompressed packets whenever TCP is doing error
   recovery.

   But how does the compressor recognize TCP error recovery?  Consider the
   schematic TCP data transfer of fig. 6.    The confused decompressor is
   in the forward (data transfer) half of the TCP conversation.  The
   receiving TCP discards packets rather than acking them (because of the
   checksum errors), the sending TCP eventually times out and retransmits a
   packet, and the forward path compressor finds that the difference
   between the sequence number in the retransmitted packet and the sequence
   number in the last packet seen is either negative (if there were
   multiple packets in transit) or zero (one packet in transit).  The first
   case is detected in the compression step that computes sequence number
   differences.  The second case is detected in the step that checks the
   `special case' encodings but needs an additional test:  It's fairly
   common for an interactive conversation to send a dataless ack packet
   followed by a data packet.  The ack and data packet will have the same
   sequence numbers yet the data packet is not a retransmission.  To
   prevent sending an unnecessary uncompressed packet, the length of the
   previous packet should be checked and, if it contained data, a zero


   Jacobson                                                       [Page 17]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   sequence number change must indicate a retransmission.

   A confused decompressor in the reverse (ack) half of the conversation is
   as easy to detect (fig. 7):    The sending TCP discards acks (because
   they contain checksum errors), eventually times out, then retransmits
   some packet.  The receiving TCP thus gets a duplicate packet and must
   generate an ack for the next expected sequence number[11, p. 69].  This
   ack will be a duplicate of the last ack the receiver generated so the
   reverse-path compressor will find no ack, seq number, window or urg
   change.  If this happens for a packet that contains no data, the
   compressor assumes it is a duplicate ack sent in response to a
   retransmit and sends an UNCOMPRESSED_TCP packet./31/



   5  Configurable parameters and tuning


   5.1  Compression configuration

   There are two configuration parameters associated with header
   compression:  Whether or not compressed packets should be sent on a
   particular line and, if so, how many state slots (saved packet headers)
   to reserve.  There is also one link-level configuration parameter, the
   maximum packet size or MTU, and one front-end configuration parameter,
   data compression, that interact with header compression.  Compression
   configuration is discussed in this section.  MTU and data compression
   are discussed in the next two sections.

   There are some hosts (e.g., low end PCs) which may not have enough
   processor or memory resources to implement this compression.  There are
   also rare link or application characteristics that make header
   compression unnecessary or undesirable.  And there are many existing
   SLIP links that do not currently use this style of header compression.
   For the sake of interoperability, serial line IP drivers that allow
   header compression should include some sort of user configurable flag to
   disable compression (see appendix B.2)./32/

   If compression is enabled, the compressor must be sure to never send a
   connection id (state index) that will be dropped by the decompressor.
   E.g., a black hole is created if the decompressor has sixteen slots and

   ----------------------------
    31. The packet could be a zero-window probe rather than a retransmitted
   ack but window probes should be infrequent and it does no harm to send
   them uncompressed.
    32. The PPP protocol in [9] allows the end points to negotiate
   compression so there is no interoperability problem.  However, there
   should still be a provision for the system manager at each end to
   control whether compression is negotiated on or off.  And, obviously,
   compression should default to `off' until it has been negotiated `on'.


   Jacobson                                                       [Page 18]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   the compressor uses twenty./33/  Also, if the compressor is allowed too
   few slots, the LRU allocator will thrash and most packets will be sent
   as UNCOMPRESSED_TCP. Too many slots and memory is wasted.

   Experimenting with different sizes over the past year, the author has
   found that eight slots will thrash (i.e., the performance degradation is
   noticeable) when many windows on a multi-window workstation are
   simultaneously in use or the workstation is being used as a gateway for
   three or more other machines.  Sixteen slots were never observed to
   thrash.  (This may simply be because a 9600 bps line split more than 16
   ways is already so overloaded that the additional degradation from
   round-robbining slots is negligible.)

   Each slot must be large enough to hold a maximum length TCP/IP header of
   128 bytes/34/ so 16 slots occupy 2KB of memory.  In these days of 4 Mbit
   RAM chips, 2KB seems so little memory that the author recommends the
   following configuration rules:

   (1) If the framing protocol does not allow negotiation, the compressor
       and decompressor should provide sixteen slots, zero through fifteen.

   (2) If the framing protocol allows negotiation, any mutually agreeable
       number of slots from 1 to 256 should be negotiable./35/  If number
       of slots is not negotiated, or until it is negotiated, both sides
       should assume sixteen.

   (3) If you have complete control of all the machines at both ends of
       every link and none of them will ever be used to talk to machines
       outside of your control, you are free to configure them however you
       please, ignoring the above.  However, when your little eastern-block
       dictatorship collapses (as they all eventually seem to), be aware
       that a large, vocal, and not particularly forgiving Internet
       community will take great delight in pointing out to anyone willing


   ----------------------------
    33. Strictly speaking, there's no reason why the connection id should
   be treated as an array index.  If the decompressor's states were kept in
   a hash table or other associative structure, the connection id would be
   a key, not an index, and performance with too few decompressor slots
   would only degrade enormously rather than failing altogether.  However,
   an associative structure is substantially more costly in code and cpu
   time and, given the small per-slot cost (128 bytes of memory), it seems
   reasonable to design for slot arrays at the decompressor and some
   (possibly implicit) communication of the array size.
    34. The maximum header length, fixed by the protocol design, is 64
   bytes of IP and 64 bytes of TCP.
    35. Allowing only one slot may make the compressor code more complex.
   Implementations should avoid offering one slot if possible and
   compressor implementations may disable compression if only one slot is
   negotiated.


   Jacobson                                                       [Page 19]

   RFC 1144               Compressing TCP/IP Headers          February 1990


       to listen that you have misconfigured your systems and are not
       interoperable.


   5.2  Choosing a maximum transmission unit

   From the discussion in sec. 2, it seems desirable to limit the maximum
   packet size (MTU) on any line where there might be interactive traffic
   and multiple active connections (to maintain good interactive response
   between the different connections competing for the line).  The obvious
   question is `how much does this hurt throughput?'  It doesn't.

   Figure 8 shows how user data throughput/36/ scales with MTU with (solid
   line) and without (dashed line) header compression.  The dotted lines
   show what MTU corresponds to a 200 ms packet time at 2400, 9600 and
   19,200 bps.  Note that with header compression even a 2400 bps line can
   be responsive yet have reasonable throughput (83%)./37/

   Figure 9 shows how line efficiency scales with increasing line speed,
   assuming that a 200ms. MTU is always chosen./38/  The knee in the
   performance curve is around 2400 bps.  Below this, efficiency is
   sensitive to small changes in speed (or MTU since the two are linearly
   related) and good efficiency comes at the expense of good response.
   Above 2400bps the curve is flat and efficiency is relatively independent
   of speed or MTU. In other words, it is possible to have both good
   response and high line efficiency.

   To illustrate, note that for a 9600 bps line with header compression
   there is essentially no benefit in increasing the MTU beyond 200 bytes:
   If the MTU is increased to 576, the average delay increases by 188%
   while throughput only improves by 3% (from 96 to 99%).







   ----------------------------
    36. The vertical axis is in percent of line speed.  E.g., `95' means
   that 95% of the line bandwidth is going to user data or, in other words,
   the user would see a data transfer rate of 9120 bps on a 9600 bps line.
   Four bytes of link-level (framer) encapsulation in addition to the
   TCP/IP or compressed header were included when calculating the relative
   throughput.  The 200 ms packet times were computed assuming an
   asynchronous line using 10 bits per character (8 data bits, 1 start, 1
   stop, no parity).
    37. However, the 40 byte TCP MSS required for a 2400 bps line might
   stress-test your TCP implementation.
    38. For a typical async line, a 200ms. MTU is simply .02 times the line
   speed in bits per second.


   Jacobson                                                       [Page 20]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   5.3  Interaction with data compression

   Since the early 1980's, fast, effective, data compression algorithms
   such as Lempel-Ziv[7] and programs that embody them, such as the
   compress program shipped with Berkeley Unix, have become widely
   available.  When using low speed or long haul lines, it has become
   common practice to compress data before sending it.  For dialup
   connections, this compression is often done in the modems, independent
   of the communicating hosts.  Some interesting issues would seem to be:
   (1) Given a good data compressor, is there any need for header
   compression?  (2) Does header compression interact with data
   compression?  (3) Should data be compressed before or after header
   compression?/39/

   To investigate (1), Lempel-Ziv compression was done on a trace of 446
   TCP/IP packets taken from the user's side of a typical telnet
   conversation.  Since the packets resulted from typing, almost all
   contained only one data byte plus 40 bytes of header.  I.e., the test
   essentially measured L-Z compression of TCP/IP headers.  The compression
   ratio (the ratio of uncompressed to compressed data) was 2.6.  In other
   words, the average header was reduced from 40 to 16 bytes.  While this
   is good compression, it is far from the 5 bytes of header needed for
   good interactive response and far from the 3 bytes of header (a
   compression ratio of 13.3) that header compression yielded on the same
   packet trace.

   The second and third questions are more complex.  To investigate them,
   several packet traces from FTP file transfers were analyzed/40/ with and
   without header compression and with and without L-Z compression.  The
   L-Z compression was tried at two places in the outgoing data stream
   (fig. 10):    (1) just before the data was handed to TCP for
   encapsulation (simulating compression done at the `application' level)
   and (2) after the data was encapsulated (simulating compression done in
   the modem).  Table 1 summarizes the results for a 78,776 byte ASCII text
   file (the Unix csh.1 manual entry)/41/ transferred using the guidelines
   of the previous section (256 byte MTU or 216 byte MSS; 368 packets
   total).  Compression ratios for the following ten tests are shown
   (reading left to right and top to bottom):

   ----------------------------
    39. The answers, for those who wish to skip the remainder of this
   sectio