Integrated Services in the Presence of Compressible Flows
Extracted elements (17)
A possible future extension to RFC 2210 could divide the parameter number space so that parameters of the form x1xxxxxx are silently ignored if unrecognized, while x0xxxxxx cause an error, analogous to RSVP's class-num high-bit handling. This is noted as a direction for future work but not mandated here.
The compressibility hint is placed in the Sender TSpec rather than a separate RSVP object because the sender knows best what the data will look like, the TSpec is not modified in transit (unlike the Adspec), and placing it there works for non-RSVP resource reservation mechanisms as well.
This specification is restricted to link-by-link compression (e.g., header compression) and explicitly excludes transcoding or audio silence detection, which would affect bandwidth at all downstream nodes and would require modifying the sender TSpec in transit. The sender TSpec on the wire is never modified.
An intserv router that receives the new TSpec format but does not understand the compressibility hint should silently ignore it rather than rejecting the TSpec. If an implementation instead rejects PATH messages with the hint, it should send a PathErr with Error code 21, Sub-code 04 (malformed TSpec), and the sender may retry without the hint.
When an unknown TSpec parameter is silently ignored, the node should behave as if the parameter is absent but must leave the unknown parameter intact in the forwarded object. RFC 2210 specifies parseable TSpec formats but does not mandate behavior on unknown parameters, so some implementations may reject messages containing the compressibility hint.
A router that makes use of the compressibility hint for admission control should police the flow using the compressed TSpec (as if it is at the edge of the network), so that any traffic exceeding the compressed TSpec is treated as excess according to intserv rules.
Services that use the maximum datagram size M for policing (e.g., guaranteed service) should continue to use the uncompressed value of M to allow for the possibility that some packets may not be successfully compressed.
For guaranteed service reservations covering multiple senders, the receiver RSpec rate R is adjusted downward using a weighted average compression factor f_avg = (b1*f1 + b2*f2 + ... + bn*fn)/(b1 + b2 + ... + bn), where bk and fk are the burstsize and compression factor of sender k.
Multiple instances of parameter 126 may appear in a single TSpec when more than one compression scheme could be applied to the data. The overall TSpec length and Service 1 data length fields are increased accordingly.
The compressibility hint is a new parameter (parameter ID 126, Compression_Hint) added to the Sender TSpec. It consists of an assigned hint number identifying the compression type and a 32-bit integer compression factor f expressed as a percentage in the range (0, 100].
The compression factor f is a 32-bit integer percentage in the range (0, 100]. The reserved value 0 means the sender does not know or wishes to leave the calculation to the router. The value 100 indicates no compression is expected.
To prevent an increase in delay due to the C/R term when R is reduced, the router performing compression must inflate its local C value by dividing it by (f_avg/100), compensating for the reduced R seen by the receiver's delay calculation.
When computing a compressed TSpec from (r, b, p, M, m) with explicit compression factor f percent and bytes-saved N: r'=r*f/100, b'=b*f/100, p'=p (unchanged), M'=M-N, m'=m-N. These adjusted values are used as input to admission control and resource allocation in place of the sender TSpec.
This specification relies on IANA-assigned numbers for the compression scheme hint. Where possible, existing PPP compression algorithm identification numbers (from RFC 1332 and RFC 2509) are reused as the high-order 16 bits of the hint value; IANA may need to assign additional hint numbers specifically for int-serv purposes.
The extensions pose essentially the same security risks as RFC 2210. A sender falsely declaring data to be compressible is equivalent to providing an insufficiently large TSpec; the risk is addressed the same way — flows that exceed their compressed TSpec are policed according to standard intserv rules.
The extended Sender TSpec adds parameter 126 (Compression_Hint) after the standard Token_Bucket_TSpec (parameter 127). Parameter 126 occupies 2 words (not including header): word 10 is the hint assigned number (32-bit), and word 11 is the compression factor f (32-bit integer). The overall TSpec length field increases by 3 words.
The hint value is a 32-bit field: high-order 16 bits are the IP-compression-protocol number as defined in RFC 1332 and RFC 2509; low-order 16 bits are a sub-option for cases where the protocol number alone is insufficient. Defined values include 0x002d0000 (IP/TCP, RFC 1144), 0x00610000 (IP, RFC 2507), and 0x00610100 (IP/UDP/RTP, RFC 2508).