rfc3006.txt

Integrated Services in the Presence of Compressible Flows

   compress the 40 bytes of IP/UDP/RTP header to 4 bytes (with high
   probability).  To determine the worst-case (smallest) gain provided
   by compression, it can assume that the sender always sends maximum
   sized packets at 48 kbps, i.e., a 120 byte packet every 20
   milliseconds.  The router can conclude that these packets would be
   compressed to 84 bytes, yielding a token bucket rate of 33.6 kbps and
   a token bucket depth of 84 bytes as before.  If the sender is willing
   to allow an independent calculation of compression gain by the
   router, the explicit compression factor may be omitted from the
   TSpec.  Details of the TSpec encoding are provided below.

   To generalize the above discussion, assume that the Sender TSpec
   consists of values (r, b, p, M, m), that the explicit compression
   factor provided by the sender is f percent, and that the number of
   bytes saved by compression is N, independent of packet size.  The
   parameters in the compressed TSpec would be:

     r' = r * f/100
     b' = b * f/100
     p' = p
     M' = M-N
     m' = m-N

   The calculations for r' and b' reflect that fact that f is expressed
   as a percentage and must therefore be divided by 100.  The
   calculations for M' and m' hold only in the case where the
   compression algorithm reduces packets by a certain number of bytes
   independent of content or length of the packet, as is true for header
   compression.  Other compression algorithms may not have this
   property.  In determining the value of N, the router may need to make
   worst case assumptions about the number of bytes that may be removed
   by compression, which depends on such factors as the presence of UDP
   checksums and the linearity of RTP timestamps.




Davie, et al.               Standards Track                     [Page 5]

RFC 3006       Integrated Services in Compressible Flows   November 2000


   All these adjusted values are used in the compressed TSpec.  The
   router's admission control and resource allocation algorithms should
   behave as if the sender TSpec contained those values.  [RFC 2205]
   provides a set of rules by which sender and receiver TSpecs are
   combined to calculate a single `effective' TSpec that is passed to
   admission control.  When a reservation covering multiple senders is
   to be installed, it is necessary to reduce each sender TSpec by its
   appropriate compression factor. The set of sender TSpecs that apply
   to a single reservation on an interface are added together to form
   the effective sender TSpec, which is passed to traffic control.  The
   effective receiver TSpec need not be modified; traffic control takes
   the greatest lower bound of these two TSpecs when making its
   admission control and resource allocation decisions.

   The handling of the receiver RSpec depends on whether controlled load
   or guaranteed service is used.  In the case of controlled load, no
   additional processing of RSpec is needed.  However, a guaranteed
   service RSpec contains a rate term R which does need to be adjusted
   downwards to account for compression.  To determine how R should be
   adjusted, we note that the receiver has chosen R to meet a certain
   delay goal, and that the terms in the delay equation that depend on R
   are b/R and C/R (when the peak rate is large).  The burstsize b in
   this case is the sum of the burstsizes of all the senders for this
   reservation, and each of these numbers has been scaled down by the
   appropriate compression factor.  Thus, R should be scaled down using
   an average compression factor

      f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... bn)

   where bk is the burstsize of sender k and fk is the corresponding
   compression factor for this sender.  Note that f_avg, like the
   individual fi's, is a percentage.  Note also that this results in a
   compression factor of f in the case where all senders use the same
   compression factor f.

   To prevent an increase in delay caused by the C/R term when the
   reduced value of R is used for the reservation, it is necessary for
   this hop to `inflate' its value of C by dividing it by (f_avg/100).
   This will cause the contribution to delay made by this hop's C term
   to be what the receiver would expect when it chooses its value of R.

   There are certain risks in adjusting the resource requirements
   downwards for the purposes of admission control and resource
   allocation.  Most compression algorithms are not completely
   deterministic, and thus there is a risk that a flow will turn out to
   be less compressible than had been assumed by admission control.
   This risk is reduced by the use of the explicit compression factor
   provided by the sender, and may be minimized if the router makes



Davie, et al.               Standards Track                     [Page 6]

RFC 3006       Integrated Services in Compressible Flows   November 2000


   worst case assumptions about the amount of compression that may be
   achieved.  This is somewhat analogous to the tradeoff between making
   worst case assumptions when performing admission control or making
   more optimistic assumptions, as in the case of measurement-based
   admission control.  If a flow turns out to be less compressible that
   had been assumed when performing admission control, any extra traffic
   will need to be policed according to normal intserv rules.  For
   example, if the router assumed that the 48 kbps stream above could be
   compressed to 33.6 kbps and it was ultimately possible to compress it
   to 35 kbps, the extra 1.4 kbps would be treated as excess.  The exact
   treatment of such excess is service dependent.

   A similar scenario may arise if  a sender claims that data for a
   certain session is compressible when in fact it is not, or overstates
   the extent of its compressibility.  This might cause the flow to be
   erroneously admitted, and would cause insufficient resources to be
   allocated to it.  To prevent such behavior from adversely affecting
   other reserved flows, any flow that sends a compressibility hint
   should be policed (in any router that has made use of the hint for
   its admission control) on the assumption that it is indeed
   compressible, i.e., using the compressed TSpec.  That is, if the flow
   is found to be less compressible than advertised, the extra traffic
   that must be forwarded  by the router above the compressed TSpec will
   be policed according to intserv rules appropriate for the service.
   Note that services that use the maximum datagram size M for policing
   purposes (e.g. guaranteed service [RFC 2210]) should continue to use
   the uncompressed value of M to allow for the possibility that some
   packets may not be successfully compressed.

   Note that RSVP does not generally require flows to be policed at
   every hop.  To quote [RFC 2205]:

      Some QoS services may require traffic policing at some or all of
      (1) the edge of the network, (2) a merging point for data from
      multiple senders, and/or (3) a branch point where traffic flow
      from upstream may be greater than the downstream reservation being
      requested.  RSVP knows where such points occur and must so
      indicate to the traffic control mechanism.

   For the purposes of policing, a router which makes use of the
   compressibility hint in a sender TSpec should behave as if it is at
   the edge of the network, because it is in a position to receive
   traffic from a sender that, while it passed through policing at the
   real network edge, may still need to be policed if the amount of data
   sent exceeds the amount described by the compressed TSpec.






Davie, et al.               Standards Track                     [Page 7]

RFC 3006       Integrated Services in Compressible Flows   November 2000


4. Object Format

   The compressibility hint may be included in the sender TSpec using
   the encoding rules of Appendix A in [RFC 2210].  The complete sender
   TSpec is as follows:

        31           24 23           16 15            8 7             0
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   1   | 0 (a) |    reserved           |            10 (b)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   2   |    1  (c)     |0| reserved    |             9 (d)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   3   |   127 (e)     |    0 (f)      |             5 (g)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   4   |  Token Bucket Rate [r] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   5   |  Token Bucket Size [b] (32-bit IEEE floating point number)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   6   |  Peak Data Rate [p] (32-bit IEEE floating point number)       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   7   |  Minimum Policed Unit [m] (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   8   |  Maximum Packet Size [M]  (32-bit integer)                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   9   |   126 (h)     |    0 (i)      |             2 (j)             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   10  |     Hint (assigned number)                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   11  |  Compression factor [f] (32-bit integer)                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        (a) - Message format version number (0)
        (b) - Overall length (10 words not including header)
        (c) - Service header, service number 1 (default/global
              information)
        (d) - Length of service 1 data, 9 words not including header
        (e) - Parameter ID, parameter 127 (Token_Bucket_TSpec)
        (f) - Parameter 127 flags (none set)
        (g) - Parameter 127 length, 5 words not including header
        (h) - Parameter ID, parameter 126 (Compression_Hint)
        (i) - Parameter 126 flags (none set)
        (j) - Parameter 126 length, 2 words not including header

   The difference between this TSpec and the one described in [RFC 2210]
   is that the overall length contained in the first word is increased
   by 3, as is the length of the `service 1 data', and the original
   TSpec parameters are followed by a new parameter, the compressibility
   hint.  This parameter contains the standard parameter header, and an



Davie, et al.               Standards Track                     [Page 8]

RFC 3006       Integrated Services in Compressible Flows   November 2000


   assigned number indicating the type of compression that is possible
   on this data.  Different values of the hint would imply different
   compression algorithms may be applied to the data.  Details of the
   numbering scheme for hints appear below.

   Following the hint value is the compression factor f, expressed as a
   32 bit integer representing the factor as a percentage value.  The
   valid range for this factor is (0,100].  A sender that does not know
   what value to use here or wishes to leave the compression factor
   calculation to the routers' discretion may use the reserved value 0
   to indicate this fact.  Zero is reserved because it is not possible
   to compress a data stream to zero bits per second.  The value 100
   indicates that no compression is expected on this stream.

   In some cases, additional quantitative information about the traffic
   may be required to enable a router to determine the amount of
   compression possible.  In this case, a different encoding of the
   parameter would be required.

   In some cases it may be desirable to include more than one hint in a
   Tspec (e.g., because more than one compression scheme could be
   applied to the data.)  In this case, multiple instances of parameter
   126 may appear in the Tspec and the overall length of the Tspec and
   the length of the Service 1 data would be increased accordingly.

   Note that the Compression_Hint is, like the Token_Bucket_Tspec, not
   specific to a single service, and thus has a parameter value less
   than 128.  It is also included as part of the default/global
   information (service number 1).

4.1. Hint Numbering

   Hints are represented by a 32 bit field, with the high order 16 bits
   being the IP-compression-protocol number as defined in [RFC 1332] and