Summary

  • RFC 3918 treated multicast forwarding latency as a set of ingress-to-egress observations, not a single device-wide value.
  • Its maximum-minus-minimum result describes spread; without the underlying branch values, it cannot show which destination path was slow or why.

The measurement problem begins with multicast’s shape. A source sends one group-addressed stream into a device or system under test; the network replicates it toward several receiving interfaces. A unicast latency procedure can pair one input with one output. Multicast creates a fan-out, so the same source event has several possible arrival times. If a report averages them into one value, the statistic may look compact while concealing the branch that matters.

RFC 3918, published as an Informational memo in October 2004, adapted earlier benchmarking work to that one-ingress, many-egress case. It did not define a universal service-level objective or report how a vendor’s equipment performed. It specified how a test apparatus could characterize forwarding under disclosed conditions. The distinction matters: a methodology can make measurements comparable without making the tested topology a miniature of every live network.

For its multicast-latency procedure, the tester offers traffic to the device and inserts a uniquely identifiable frame at the midpoint of the trial. Timestamp A records when the test apparatus finishes transmitting that tagged frame. At each tested egress, the receiver detects the same frame and records a separate Timestamp B. The resulting set is formed from the difference between each branch’s B and the shared A. It is a vector indexed by ingress and egress, not merely a number attached to the box.

The method makes a missing branch a validity problem, not a slow measurement to quietly average away. The expected tagged frame must be seen at every tested output; late arrival beyond the stated five-second window after traffic stops, unexpected offered-load or forwarding-rate differences, and improperly formed frames can invalidate a trial. RFC 3918 also calls for reporting context such as frame size, tested egress count, trial duration, IGMP version, offered load and group count. It recommends a 120-second latency trial, links measurement to the offered traffic, and asks for uniform time units precise enough for the medium.

The memo does define a compact companion statistic: the maximum observed latency minus the minimum. That range answers how far apart the fastest and slowest recorded branches were in the collected set. It does not identify either branch, preserve its absolute delay, or reveal whether the spread came from one persistent outlier or a changing pattern. For that reason the specification requires the branch-related set for the primary latency result and says reports should preserve the input/output relationship so results can be trended across trials. A range is useful as a summary only if the measurements behind it remain available.

That choice was part of a broader measurement discipline. Offered load can change buffering and therefore the latency being measured. RFC 3918 distinguishes store-and-forward from bit-forwarding collection, and separately describes latency under meshed unicast burden with both baseline and burdened runs. It also draws a boundary around its ambition: the document characterizes a device or simple system, while explicit benchmarking of multicast distribution-tree formation is left for more targeted work. A controlled forwarding test is not evidence about tree convergence, application response time or end-to-end user experience.

The historical significance is methodological. RFC 2432 supplied multicast benchmarking terminology; RFC 2544 and RFC 1242 supplied earlier testing and latency concepts; RFC 3918 made the egress branch part of the observation. It turns “multicast latency” from an unqualified scalar into a measurement with a topology, load, trial and receiver-side identity. That is a stronger record—and a narrower claim. The RFC and its publication history establish what the method asked testers to do, not whether a particular product or deployed network met it.

Sources