Summary

  • RFC 5136 treats an unqualified capacity figure as incomplete: protocol layer, packet population, endpoints, start time and interval all matter.
  • Nominal physical link capacity is a theoretical upper bound, not the IP-layer capacity available to a flow.
  • IP-layer capacity counts correctly received IP bits at the destination; it excludes lower-layer errors but can include valid fragments and higher-layer-invalid payloads.
  • Type P identifies the flow or aggregate being measured because markings, queues, policies and load balancing can change treatment and path.
  • Link usage is actual correctly received traffic from any source; utilization is usage divided by the qualified link capacity.
  • Available link capacity is the unused portion during a stated interval, and available path capacity is the minimum across the path.
  • The narrow link has the smallest capacity; the tight link has the smallest available capacity. They need not be the same link.
  • A measurement without T and I cannot be safely compared with another observation or promoted into a current claim.
  • Periodic sampling can align with periodic traffic and manufacture a biased view; a sequence of observations needs a declared sampling design.
  • Generic IP capacity may count duplicated packets, headers and data that an application would not regard as unique useful work.
  • Bulk Transfer Capacity is a transport-layer, congestion-aware view of unique data and does not correspond to RFC 5136's IP-layer quantities.
  • Leadership should separate physical inventory, measured IP capacity, current availability, contractual entitlement and application outcome into distinct receipts.

The label on the port is the beginning of the question

Suppose an inventory page says a port is 10 Gbit/s. The statement may accurately identify a physical interface mode. It may also be the wrong answer to almost every operational question being asked of it. It does not say how many correctly received IP-layer bits can cross between the relevant endpoints. It does not say which packets receive which queue or route. It does not say how much competing traffic occupied the path at 09:00, whether the path changed at 09:01, or how much unique application data arrived before a deadline.

RFC 5136 starts by naming this physical figure NomCap(L): the theoretical maximum amount of data the link can support. The document gives it a deliberately limited job. Nominal capacity distinguishes a physical-layer upper bound from IP-layer quantities; it does not feed the later equations as though all physical bits automatically became usable IP bits. Encoding, framing, link behavior, device processing and errors sit between the label and the IP observation.

The distinction is not hostility to inventory. A physical rate is a necessary receipt when buying optics, checking interface negotiation or mapping maximum exposure. The error comes when one receipt is promoted through several layers without new evidence. “The port can signal at this rate” becomes “the path can carry this rate,” then “this class can use this rate,” then “the subscriber is entitled to this rate,” and finally “the application received this rate.” Each sentence adds a claim the original label did not measure.

RFC 5136's enduring contribution is to stop that promotion early. It says capacity is meaningful only relative to a given protocol layer. Even at the IP layer, one must name the source, destination, packet population and time interval. The number becomes longer to report, but much harder to misuse.

What the IP-layer counter is actually allowed to count

The RFC defines IP-layer bits as eight times the octets in correctly received IP packets, beginning with the first octet of the IP header and ending with the last octet of the payload. The observation is made at destination D, begins at time T and ends at T+I. Those symbols are not mathematical decoration. They are part of the identity of the result.

Correct reception has a specific boundary. Data corrupted below IP and unable to reach IP processing does not count. Packets failing IP-header validation do not count. But the metric is not an application-validity metric. Higher-layer data need not be understood or valid. IP options do not disqualify an otherwise processable packet, and valid fragments consume resources and therefore count even when a complete higher-layer object cannot be reassembled.

That creates a useful but narrow truth. An IP-capacity observation can describe the movement of processable IP-layer bits. It cannot, without further receipts, say that a TCP connection delivered unique bytes, that a video decoder produced frames, that an object arrived intact or that a transaction completed. A fragment that counts for link capacity may be worthless to the application. A retransmitted payload may consume the path twice while contributing useful data once. The layer is not wrong; it is answering its own question.

Interval boundaries also matter. If T or T+I cuts through a packet, RFC 5136 excludes the partial packet. In a long, busy interval this may be negligible. In a short or sparse interval it can bias the result. Reporting only the final rate erases the information needed to judge that effect. Two identical-looking rates derived from different interval lengths and boundary conditions are not necessarily comparable observations.

Type P determines whose capacity has been measured

The phrase Type P is where a generic capacity claim encounters the network's policy. It can describe a broad aggregate or a tightly specified flow population. That choice matters because real networks classify and treat packets differently. Marking can select a queue. An ACL can suppress one protocol. Routing policy can move traffic. Load balancing can choose another path. A packet with an IP option may receive exceptional handling. The measurement packet may therefore traverse a different operational reality from the traffic it is supposed to represent.

RFC 5136 recognizes two legitimate viewpoints. A provider may choose a broad Type P to characterize the resource across many packets. An application user may choose a narrow Type P that resembles the flow that matters. Neither viewpoint is automatically superior, and neither can silently impersonate the other. A generic probe's result cannot be sold as application capacity unless the equivalence of treatment is demonstrated. An application-specific result cannot describe the whole link unless its narrow population is explicitly generalized with evidence.

This is why a speed test that omits packet characteristics is not merely under-documented. It lacks part of the measured object's identity. The endpoint pair is insufficient if the network can classify the probe differently. The route is insufficient if the queue differs. The queue is insufficient if packet size changes lower-layer overhead. One must state which packets made the number true.

The same principle applies to shared traffic. The capacity relevant to one Type P depends not only on the reference packets but on the population sharing the links. A test taken while a priority class is empty is not a timeless property. A test whose markings accidentally enter a privileged queue may faithfully report that queue and falsely reassure the ordinary application.

Capacity, usage and availability are different records

For a link L, RFC 5136 writes IP-layer capacity as C(L,T,I): the maximum Type-P IP-layer bits that can be transmitted from S and correctly received at D during the interval, divided by the interval length. For a path P, capacity is the smallest link capacity on that path. This is the familiar narrow-link idea, but the formalism keeps its time and traffic qualifications attached.

Usage answers another question. Used(L,T,I) is the actual correctly received IP traffic from any source during the interval. It is not the maximum and need not originate at the endpoints under study. Utilization is Used/C. A percentage without the qualified denominator is consequently incomplete: changing the definition of capacity, Type P or interval can change the meaning of the same displayed percentage.

Available link capacity is C*(1-Util). Available path capacity is the minimum available capacity among the path's links. This minimum identifies the tight link. The tight link and narrow link can differ. A relatively slow link may be lightly loaded, while a faster link carries so much competing traffic that it offers less capacity to the measured path. An upgrade to the narrow link can therefore leave the tight-link constraint untouched.

This separation has direct consequences for procurement and incident review. Buying a higher nominal rate changes a physical upper bound. Activating the interface may change the IP-layer capacity. Moving traffic or altering scheduling may change availability. None of those changes proves that the application can exploit the new resource, that the route includes it, or that the subscriber has permission to use it. Capacity planning fails when these changes are recorded as one undifferentiated “bandwidth increase.”

A timestamp is part of the evidence, not display chrome

Available capacity is volatile because usage changes. RFC 5136 therefore insists that time and interval accompany the result and suggests a sequence of measurements when characterizing availability. A single observation is not invalid; it is bounded. The problem begins when its bounds are discarded.

Sampling design can also manufacture confidence. If a probe runs at a frequency that is a multiple of a periodic workload, it can repeatedly see the quiet phase or the busy phase. More samples taken with the same phase lock do not cure the bias. An operator needs the schedule, jitter, missing runs, endpoint state, route state and relevant traffic cycles before interpreting the series.

Freshness is a separate decision. A measurement taken last night may be excellent evidence about last night. It may be useful for a baseline. It does not become current merely because it is the newest number in a dashboard. The decision using it must declare how stale it may be and what changes invalidate it: rerouting, queue policy, access-rate negotiation, maintenance, traffic mix or endpoint software.

This is the point where good measurement governance resembles good registry governance. Preserve the identity and provenance of the record; do not let a convenient summary erase the boundary of what was observed. A capacity value without its interval is not a smaller version of the same fact. It is a different, less auditable claim.

The duplicate packet that made the link look busier

RFC 5136's treatment of hardware duplicates exposes another layer boundary. In the generic form, if a device duplicates a packet and the destination correctly receives both copies, both count. For raw IP resource consumption, that makes sense: both copies traversed and consumed resources. For a user asking how much unique information arrived, it can be misleading.

The remedy is not to call one metric false. It is to state the uniqueness rule. A Type P restriction may count only uniquely sent packets. An application metric may exclude duplicate payload. A fault investigation may want both values: raw link work and unique useful delivery. Collapsing them hides the very duplication that needs attention.

Packet size and compression produce related traps. Smaller packets can consume more lower-layer overhead for the same IP-layer volume. If header compression sends fewer physical bits, RFC 5136 still counts the inflated IP-layer bits. The metric remains coherent at its chosen layer. It simply cannot be compared with a physical-wire counter without accounting for the transformation between them.

Why Bulk Transfer Capacity is not a synonym

RFC 3148's Bulk Transfer Capacity asks how much unique data a congestion-aware transport connection can deliver. It excludes headers and retransmitted data from useful transfer. Its control loop reacts to loss, round-trip time, reordering and recovery algorithms. Those are features of the measurement, not contamination to be removed.

RFC 5136 counts IP-layer headers and is indifferent to whether payload bytes repeat. A burst of errors can reduce correctly received IP packets. The same errors can make a transport retransmit, reduce its sending rate and deliver unique bytes on a very different timescale. The two numbers describe different layers of the same event and need not match.

Later IPPM work, including RFC 9097, gives more concrete methods and statistics for one-way IP capacity. RFC 9946 defines a controlled UDP speed-test protocol. These documents improve how a bounded measurement can be performed and reported. They do not turn the result into a subscriber entitlement, an SLA judgment or universal application goodput. The protocol can authenticate a test; it cannot authorize the business claim built on top of it.

The practical reporting rule is simple: never use “bandwidth” alone where the audience could reasonably confuse nominal rate, IP capacity, available capacity, transport goodput and completed application work. Name the quantity. Attach its parameters. State what it excludes.

Build a receipt ladder before making the promise

The first receipt is physical: medium, interface mode, negotiation state and nominal rate. The second is topological: source, destination, exact path and every link whose minimum could govern the result. The third is semantic: layer, Type P, packet sizes, markings, error and duplicate treatment. The fourth is temporal: start, interval, clocks and sampling schedule.

Only then can the capacity receipts be interpreted: per-link C, path minimum, actual usage, utilization denominator, per-link availability and tight link. Route changes, queue policy and load balancing belong beside the number, not in an operations team's memory. An active test also needs an offered-load record and protection against making the network condition it claims merely to observe.

Contractual evidence is another layer. A subscriber may be entitled to a committed rate, a burst profile or a percentile calculation. Those rules are not derivable from RFC 5136. They come from the service agreement and the authority that applies it. Application evidence follows: unique bytes, completion time, integrity, retries and user-visible outcome.

When these receipts disagree, the disagreement is diagnostic. A physical interface can be healthy while a Type-P path is constrained. IP capacity can be high while available capacity is low. Available capacity can be adequate while a transport control loop underperforms. Transport goodput can be acceptable while the application misses its deadline. One green number cannot adjudicate every layer.

The thin standard and the thick local decision

RFC 5136 is a model of useful restraint. It supplies shared definitions so researchers, tool builders, providers and users can say which quantity they mean. It does not claim that a vocabulary reserves resources, chooses a path, authorizes test load, grants capacity to a subscriber or proves a business outcome.

That division mirrors a broader discipline in Internet coordination. The common layer should be thin enough to preserve interoperability and comparability. Local systems remain responsible for implementation, policy, measurement and consequence. Authority should not expand merely because one layer owns the most visible number.

Leadership's job is therefore not to select a preferred capacity number. It is to prevent one team from grading the whole service with a metric created inside its own boundary. Inventory owns nominal possibility. Network measurement owns bounded IP observations. Operations owns current contention and policy. Commercial systems own entitlement. The application and user own the final outcome evidence.

The port's label can be perfectly correct. RFC 5136 teaches why correctness at that layer is not permission to stop asking questions.

Sources

  1. RFC 5136, HTML
  2. RFC 5136, plain text
  3. RFC Editor record for RFC 5136
  4. IETF Datatracker record for RFC 5136
  5. RFC 5136 document history
  6. RFC 5136 errata search
  7. RFC 1812
  8. RFC 2330
  9. RFC 2544
  10. RFC 3148
  11. RFC 4656
  12. RFC 6349
  13. RFC 6703
  14. RFC 7312
  15. RFC 8337
  16. RFC 9097
  17. RFC 9473
  18. RFC 9946
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary