Summary

  • RFC 3006 kept the sender's original traffic specification intact but added a compressibility hint that each router could use only where its own link supported the named compression.
  • A router that admitted the flow at a discounted compressed rate had to police that smaller budget as if it were a network edge, keeping the downside of an inaccurate claim with the flow that benefited from it.

The reservation looked too large until one router knew something the end host could not safely put into the number. In the worked example in RFC 3006, a sender described a 48 kbit/s stream made of 120-byte packets. A constrained interface could compress 40 bytes of IP, UDP and RTP header to four. On that hop, the packet would occupy 70 percent of its uncompressed size, so the router could budget 33.6 kbit/s rather than 48.

That arithmetic seems like a minor optimization. It actually exposed a division of knowledge. The sender knew what kind of traffic it intended to emit. The router knew whether a particular outgoing interface ran the relevant compressor. Neither knew enough to rewrite the end-to-end demand for every hop. Some links might compress; others might not. A sender that simply advertised 33.6 kbit/s would understate its cost on the uncompressed parts of the path. A router that saw only 48 kbit/s could reject a reservation that its own link was able to carry.

RFC 3006 resolved the mismatch without declaring either actor globally authoritative. The transmitted Sender TSpec remained unchanged, consistent with the RSVP use defined in RFC 2210. A new hint described the possible compression scheme and, optionally, a percentage factor. A network element could treat that information as one input to a locally derived compressed TSpec. The word “hint” was precise: it was neither a command nor proof that the advertised saving would materialize.

The distinction followed RSVP's own division of labor. RFC 2205 carried information between endpoints and network elements, while admission control and traffic control decided whether resources existed. RFC 3006 placed the hint in the Sender TSpec because the sender knew the stream's likely structure and because traffic control, rather than RSVP message processing, needed the information. The common object carried a claim; running code at the hop decided whether the claim was useful.

The example then made the local calculation concrete. The original token-bucket rate r was 48 kbit/s, depth b was 120 bytes, maximum packet size M was 120 bytes and minimum policed unit m was 64 bytes. A 70 percent factor reduced r to 33.6 kbit/s, b and M to 84 bytes. The minimum unit needed different arithmetic: remove the same 36 header bytes from 64, producing 28 bytes. The formula was not “multiply every field by 0.7 and hope.”

For a header compressor that removes a fixed N bytes, RFC 3006 scaled rate and burst depth by f/100, left peak rate unchanged, and subtracted N from maximum and minimum packet sizes. It warned that the fixed-saving model did not describe every compression algorithm. UDP checksum presence, RTP timestamp linearity and packet-size distribution could change the result. A router could choose a conservative calculation instead of accepting the sender's percentage. A factor of zero expressly left the calculation to the routers; 100 said no saving was expected.

The mechanism also had to survive many senders. Each sender's TSpec was reduced using its own factor before the applicable sender specifications were combined. For guaranteed service under RFC 2212, the receiver's rate could be scaled by a burst-size-weighted average of those factors. But reducing R alone would enlarge the C/R contribution to delay, so the hop had to inflate its C error term inversely. A bandwidth discount was valid only if the promised delay semantics stayed intact.

The most important paragraph began where the optimistic arithmetic ended. Compression was not completely deterministic. Suppose the router admitted the 48 kbit/s flow on the assumption that it would consume 33.6, but the actual compressor delivered 35. The extra 1.4 kbit/s had not been reserved. It became excess traffic handled by the rules of the chosen Integrated Services class. The capacity discount did not turn an estimate into a right.

Misstatement could also be strategic. A sender might label data compressible when it was not, or exaggerate the saving. That could admit a flow that should have been refused and leave too few resources for flows whose reservations were honest. RFC 3006 assigned the consequence to the claim that created the discount: any router that used the hint should police the stream against the compressed TSpec as though that router were a network edge.

This was a subtle relocation of responsibility. RSVP did not require policing at every hop. Yet the compression-aware hop had introduced a new local boundary that the actual network edge could not see. Upstream policing against the uncompressed TSpec could prove the sender stayed within 48 kbit/s; it could not prove the downstream link received no more than the discounted 33.6. The router that spent the saving therefore became the verification point for that saving.

Maximum datagram size preserved another asymmetry. A service that used M for policing was to keep the uncompressed value because some packets might fail to compress. The reservation model could discount recurring wire cost without pretending that every individual packet would always shrink. Average efficiency and worst-case admissibility remained different receipts.

Backward compatibility completed the control loop. An old router that did not understand the hint should ideally ignore it locally, forward it unchanged, and reserve against the original TSpec. A capable router later on the path could still use it. But RFC 2210 had not completely specified what to do with unknown parameters, so some implementations might reject the PATH message. RFC 3006 allowed a PathErr response and a retry without the hint. The extension could fail back to the more expensive, understood contract rather than silently inventing a discount.

The surrounding low-speed work shows what this Article does not own. RFC 2688 calculated effective PPP wire cost after framing, fragmentation, stuffing and link-rate changes. RFC 2689 explained why framing, compression and explicit application knowledge had to cooperate on scarce links. RFC 3006 occupied the narrower exchange between claim and enforcement: who could describe compressibility, who could convert it into local capacity, and who carried the downside when the conversion disappointed.

Later, RFC 3241 assigned a family of RSVP hint values for ROHC over PPP and normatively reused RFC 3006. That proves the hint format could be extended to another compression framework. It does not prove broad deployment, market success or a direct causal line to contemporary QoS. The historical value lies in the decision structure visible in the standard itself.

Read through Lu Heng's Running-Code Primacy lens, the router's authority came from an executable capability, not from possession of a number in a signalling object. The minimum common layer carried enough information for a local decision; it did not force every hop to share one future. The stability question was equally concrete: a reservation was operationally stable only while observed compression continued to support the discount on which admission relied.

RFC 3006 therefore treated a resource promise as a chain of bounded receipts. The sender described. The hop verified capability. Admission calculated. Traffic control policed. Compatibility determined whether the optional claim survived the path. None of those receipts alone proved the service outcome. Together they made a local efficiency gain usable without turning it into invisible risk for everyone else.

Sources