rfc1144.txt

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

         - the change mask.

   At this point, the compressed TCP packet is passed to the framer for
   transmission.


   3.2.4  Decompressor processing

   Because of the simplex communication model, processing at the
   decompressor is much simpler than at the compressor --- all the
   decisions have been made and the decompressor simply does what the
   compressor has told it to do.

   The decompressor is called with the incoming packet,/22/ the length and
   type of the packet and the compression state structure for the incoming
   serial line.  A (possibly re-constructed) IP packet will be returned.

   The decompressor can receive four types of packet:  the three generated
   by the compressor and a TYPE_ERROR pseudo-packet generated when the
   receive framer detects an error./23/  The first step is a `switch' on
   the packet type:

     - If the packet is TYPE_ERROR or an unrecognized type, a `toss' flag
       is set in the state to force COMPRESSED_TCP packets to be discarded
       until one with the C bit set or an UNCOMPRESSED_TCP packet arrives.
       Nothing (a null packet) is returned.

   ----------------------------
    22. It's assumed that link-level framing has been removed by this point
   and the packet and length do not include type or framing bytes.
    23. No data need be associated with a TYPE_ERROR packet.  It exists so
   the receive framer can tell the decompressor that there may be a gap in
   the data stream.  The decompressor uses this as a signal that packets
   should be tossed until one arrives with an explicit connection number (C
   bit set).  See the last part of sec. 4.1 for a discussion of why this is
   necessary.


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


     - If the packet is TYPE_IP, an unmodified copy of it is returned and
       the state is not modified.

     - If the packet is UNCOMPRESSED_TCP, the state index from the IP
       protocol field is checked./24/  If it's illegal, the toss flag is
       set and nothing is returned.  Otherwise, the toss flag is cleared,
       the index is copied to the state's last connection received field, a
       copy of the input packet is made,/25/ the TCP protocol number is
       restored to the IP protocol field, the packet header is copied to
       the indicated state slot, then the packet copy is returned.

   If the packet was not handled above, it is COMPRESSED_TCP and a new
   TCP/IP header has to be synthesized from information in the packet plus
   the last packet's header in the state slot.  First, the explicit or
   implicit connection number is used to locate the state slot:

     - If the C bit is set in the change mask, the state index is checked.
       If it's illegal, the toss flag is set and nothing is returned.
       Otherwise, last connection received is set to the packet's state
       index and the toss flag is cleared.

     - If the C bit is clear and the toss flag is set, the packet is
       ignored and nothing is returned.

   At this point, last connection received is the index of the appropriate
   state slot and the first byte(s) of the compressed packet (the change
   mask and, possibly, connection index) have been consumed.  Since the
   TCP/IP header in the state slot must end up reflecting the newly arrived
   packet, it's simplest to apply the changes from the packet to that
   header then construct the output packet from that header concatenated
   with the data from the input packet.  (In the following description,
   `saved header' is used as an abbreviation for `the TCP/IP header saved
   in the state slot'.)

     - The next two bytes in the incoming packet are the TCP checksum.
       They are copied to the saved header.

     - If the P bit is set in the change mask, the TCP PUSH bit is set in
       the saved header.  Otherwise the PUSH bit is cleared.




   ----------------------------
    24. State indices follow the C language convention and run from 0 to N
   - 1, where 0 < N <= 256 is the number of available state slots.
    25. As with the compressor, the code can be structured so no copies are
   done and all modifications are done in-place.  However, since the output
   packet can be larger than the input packet, 128 bytes of free space must
   be left at the front of the input packet buffer to allow room to prepend
   the TCP/IP header.


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


     - If the low order four bits (S, A, W and U) of the change mask are
       all set (the `unidirectional data' special case), the amount of user
       data in the last packet is calculated by subtracting the TCP and IP
       header lengths from the IP total length in the saved header.  That
       amount is then added to the TCP sequence number in the saved header.

     - If S, W and U are set and A is clear (the `terminal traffic' special
       case), the amount of user data in the last packet is calculated and
       added to both the TCP sequence number and ack fields in the saved
       header.

     - Otherwise, the change mask bits are interpreted individually in the
       order that the compressor set them:

         - If the U bit is set, the TCP URG bit is set in the saved header
           and the next byte(s) of the incoming packet are decoded and
           stuffed into the TCP Urgent Pointer.  If the U bit is clear, the
           TCP URG bit is cleared.

         - If the W bit is set, the next byte(s) of the incoming packet are
           decoded and added to the TCP window field of the saved header.

         - If the A bit is set, the next byte(s) of the incoming packet are
           decoded and added to the TCP ack field of the saved header.

         - If the S bit is set, the next byte(s) of the incoming packet are
           decoded and added to the TCP sequence number field of the saved
           header.

     - If the I bit is set in the change mask, the next byte(s) of the
       incoming packet are decoded and added to the IP ID field of the
       saved packet.  Otherwise, one is added to the IP ID.

   At this point, all the header information from the incoming packet has
   been consumed and only data remains.  The length of the remaining data
   is added to the length of the saved IP and TCP headers and the result is
   put into the saved IP total length field.  The saved IP header is now up
   to date so its checksum is recalculated and stored in the IP checksum
   field.  Finally, an output datagram consisting of the saved header
   concatenated with the remaining incoming data is constructed and
   returned.


   4  Error handling


   4.1  Error detection

   In the author's experience, dialup connections are particularly prone to
   data errors.  These errors interact with compression in two different
   ways:


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


   First is the local effect of an error in a compressed packet.  All error
   detection is based on redundancy yet compression has squeezed out almost
   all the redundancy in the TCP and IP headers.  In other words, the
   decompressor will happily turn random line noise into a perfectly valid
   TCP/IP packet./26/  One could rely on the TCP checksum to detect
   corrupted compressed packets but, unfortunately, some rather likely
   errors will not be detected.  For example, the TCP checksum will often
   not detect two single bit errors separated by 16 bits.  For a V.32 modem
   signalling at 2400 baud with 4 bits/baud, any line hit lasting longer
   than 400us. would corrupt 16 bits.  According to [2], residential phone
   line hits of up to 2ms. are likely.

   The correct way to deal with this problem is to provide for error
   detection at the framing level.  Since the framing (at least in theory)
   can be tailored to the characteristics of a particular link, the
   detection can be as light or heavy-weight as appropriate for that
   link./27/  Since packet error detection is done at the framing level,
   the decompressor simply assumes that it will get an indication that the
   current packet was received with errors.  (The decompressor always
   ignores (discards) a packet with errors.  However, the indication is
   needed to prevent the error being propagated --- see below.)

   The `discard erroneous packets' policy gives rise to the second
   interaction of errors and compression.  Consider the following
   conversation:

                 +-------------------------------------------+
                 |original | sent   |received |reconstructed |
                 +---------+--------+---------+--------------+
                 | 1:  A   | 1:  A  | 1:  A   | 1:  A        |
                 | 2:  BC  | 1,  BC | 1,  BC  | 2:  BC       |
                 | 4:  DE  | 2,  DE |  ---    |  ---         |
                 | 6:  F   | 2,  F  | 2,  F   | 4:  F        |
                 | 7:  GH  | 1,  GH | 1,  GH  | 5:  GH       |
                 +-------------------------------------------+

   (Each entry above has the form `starting sequence number:data sent' or
   `?sequence number change,data sent'.)  The first thing sent is an
   uncompressed packet, followed by four compressed packets.  The third
   packet picks up an error and is discarded.  To reconstruct the fourth
   packet, the receiver applies the sequence number change from incoming
   compressed packet to the sequence number of the last correctly received

   ----------------------------
    26. modulo the TCP checksum.
    27. While appropriate error detection is link dependent, the CCITT CRC
   used in [9] strikes an excellent balance between ease of computation and
   robust error detection for a large variety of links, particularly at the
   relatively small packet sizes needed for good interactive response.
   Thus, for the sake of interoperability, the framing in [9] should be
   used unless there is a truly compelling reason to do otherwise.


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


   packet, packet two, and generates an incorrect sequence number for
   packet four.  After the error, all reconstructed packets' sequence
   numbers will be in error, shifted down by the amount of data in the
   missing packet./28/

   Without some sort of check, the preceding error would result in the
   receiver invisibly losing two bytes from the middle of the transfer
   (since the decompressor regenerates sequence numbers, the packets
   containing F and GH arrive at the receiver's TCP with exactly the
   sequence numbers they would have had if the DE packet had never
   existed).  Although some TCP conversations can survive missing data/29/
   it is not a practice to be encouraged.  Fortunately the TCP checksum,
   since it is a simple sum of the packet contents including the sequence
   numbers, detects 100% of these errors.  E.g., the receiver's computed
   checksum for the last two packets above always differs from the packet
   checksum by two.

   Unfortunately, there is a way for the TCP checksum protection described
   above to fail if the changes in an incoming compressed packet are
   applied to the wrong conversation:  Consider two active conversations C1
   and C2 and a packet from C1 followed by two packets from C2.  Since the
   connection number doesn't change, it's omitted from the second C2
   packet.  But, if the first C2 packet is received with a CRC error, the
   second C2 packet will mistakenly be considered the next packet in C1.
   Since the C2 checksum is a random number with respect to the C1 sequence
   numbers, there is at least a 2^-16 probability that this packet will be
   accepted by the C1 TCP receiver./30/  To prevent this, after a CRC error
   indication from the framer the receiver discards packets until it
   receives either a COMPRESSED_TCP packet with the C bit set or an
   UNCOMPRESSED_TCP packet.  I.e., packets are discarded until the receiver
   gets an explicit connection number.

   To summarize this section, there are two different types of errors:
   per-packet corruption and per-conversation loss-of-sync.  The first type
   is detected at the decompressor from a link-level CRC error, the second
   at the TCP receiver from a (guaranteed) invalid TCP checksum.  The
   combination of these two independent mechanisms ensures that erroneous
   packets are discarded.





   ----------------------------
    28. This is an example of a generic problem with differential or delta
   encodings known as `losing DC'.
    29. Many system managers claim that holes in an NNTP stream are more
   valuable than the data.
    30. With worst-case traffic, this probability translates to one
   undetected error every three hours over a 9600 baud line with a 30%
   error rate).


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