rfc·explained

RFC 2544 · · Informational

The MOT test for network boxes, explained.

The official title is "Benchmarking Methodology for Network Interconnect Devices." What it actually decides: a fixed test program, throughput, latency, frame loss and back-to-back, run on a bench, so two labs measuring the same switch get the same numbers.

Status
✓ Still current
Replaces
RFC 1944
Updated by
RFC 6201, RFC 6815, RFC 9004

Written by Noel Lang · IT trainer

TL;DR

RFC 2544 is the standard bench test for a switch or router. It fixes four measurements, throughput, latency, frame loss and back-to-back, and runs them across a defined set of frame sizes (64 to 1518 bytes), so a vendor’s claim and a buyer’s lab result can be compared on equal terms. It replaced RFC 1944 and is still the benchmark cited on almost every network datasheet, even though it is only Informational and, per RFC 6815, must never be run on a live network.

The problem it solves

“Fast” is a marketing word until someone pins down how you measure it. One vendor quotes throughput with jumbo frames on a quiet link; another with tiny frames under load. The two numbers describe the same device and cannot be compared, and the buyer has no neutral way to check either against the datasheet.

RFC 2544 removes the wiggle room. It fixes which frame sizes to use, how long each trial runs, how to define zero-loss throughput, and how to report the result. Because every lab follows the same script, the numbers finally mean the same thing. That is why the standard still turns up in tender documents and on the menu of every network test set, decades after 1999.

The dynamometer analogy

Think of a car on a rolling-road dynamometer. You do not measure horsepower by driving through town; you strap the car to a rig in a hall and run a fixed program: same gears, same ramp, same instruments, every time. The number that comes out is comparable to every other car put through the same rig.

RFC 2544 is that rig for network hardware. The device under test is bolted to a test set on an isolated bench, fed a fixed program of frames, and its outputs are read off the same four gauges every time. And like a dyno, the point is deliberately artificial: you run the engine flat out in conditions you would never drive in, precisely because that is the only way to read a clean, repeatable number. Which is also why you never do it in traffic.

The four numbers on every datasheet

RFC 2544 defines six tests, but four of them are the ones that reach a brochure. Each is run at every frame size:

  • Throughput frames/s or Mbit/s

    The headline number. The highest constant rate at which the device forwards every frame with zero loss. What it tells you: the honest line rate. A switch sold as "1 Gbit/s" that only hits throughput at 700 Mbit/s with small frames has just told on itself, and this test is where it shows.

  • Latency microseconds

    Delay when it is busy. A single tagged frame is timed through the box, and crucially it is measured at the throughput rate, not on an idle link. What it tells you: the delay you get when the device is already working as hard as it can, which is the number that matters for voice, trading and industrial control.

  • Frame loss rate % at each rate

    How it fails. The percentage of frames dropped, charted as you push load from low to overload. What it tells you: the shape of failure. A good box degrades gracefully; a bad one falls off a cliff. The curve is far more revealing than any single pass/fail.

  • Back-to-back frames per burst

    Burst tolerance. The longest burst of minimum-gap frames the device swallows before its buffers overflow and it starts dropping. What it tells you: how deep the buffers are, and whether the box survives bursty real traffic or only tidy steady streams.

System recovery and reset are the other two: how quickly the box stabilizes after overload and after a reboot. Useful, rarely printed.

What the test bench looks like

One test set sends frames and counts what comes back, through nothing but the DUT. Every test is repeated at each frame size, and 64 bytes is the cruel one: smallest frames mean the most packets per second.

Isolated bench · never a live network (RFC 6815)Test settx: sends framesrx: counts framesEXFO / VIAVI / T-RexDevice under testswitch / routerforwards or dropsframes outthe survivors returnFrame-size program for Ethernet (bytes), each size run in full:64 = smallest frame = most packets per second = the brutal corner64128256512102412801518
Smaller frame, same bit rate, far more packets. 64-byte frames are the stress test for the forwarding engine, which is why line-rate 64-byte throughput is the number worth reading.

What the RFC actually says

The original is a long, dry read, but its structure is simple. The map, in case you visit:

Section In plain words
1–5 · Scope & setup What is being tested and how to wire it: one test box that both sends frames and counts what comes back, connected to the device under test.
9 · Frame sizes The fixed menu for Ethernet: 64, 128, 256, 512, 1024, 1280 and 1518 bytes. Every test is run at each size so a device is judged across its whole range.
24 · Trial duration Each measurement trial SHOULD last at least 60 seconds, long enough that a brief buffer or timing fluke cannot flatter the result.
26 · The tests The heart of it: throughput, latency, frame loss rate, back-to-back, plus system recovery and reset. The four above are the ones that reach datasheets.
26.1 · Throughput search The binary-search recipe: send at a rate, if any frame is lost drop the rate, if none is lost raise it, and close in on the zero-loss maximum.

Things people get wrong

  • "A 2544 result equals real-world performance."

    It does not. 2544 measures raw hardware forwarding on a bench with synthetic frames and no protocol on top. Real performance depends on TCP, application behavior, mixed traffic and distance. A device can ace 2544 and still feel slow to users. Treat it as a spec-sheet floor, not a promise.

  • "You can run it on the live network."

    You should not, and there is an RFC that exists mainly to say so. is titled "Use on Production Networks Considered Harmful". The test floods the device to find its breaking point, which fights real user traffic and produces bad numbers on top. 2544 belongs on an isolated bench.

  • "It tests TCP throughput."

    No TCP is involved. 2544 fires fixed-size Ethernet or IP frames at controlled rates, with no handshake, no windowing, no retransmission. It is a measure of packets forwarded per second, not of a file transfer. For TCP-aware, service-level numbers, that is what Y.1564 and TWAMP are for.

  • "Informational means irrelevant."

    Informational is a status, not a verdict on importance. 2544 was never on the standards track, yet it is the single most-cited benchmark in networking procurement and appears on nearly every switch datasheet. In this corner of the industry it is the de facto standard, label notwithstanding.

Where you'll meet RFC 2544

You rarely read the spec, but you see its output constantly. A field guide:

You see What it means
"RFC 2544 tested" on a datasheet The vendor ran this suite so their throughput and latency numbers are comparable to a competitor's. It is the reason every switch datasheet lists the same four figures.
RFC 2544 in a carrier SLA or acceptance report A circuit or device had to pass a 2544 run before sign-off. Common in Ethernet handoff and telco procurement, increasingly alongside Y.1564.
EXFO, VIAVI, Spirent, Ixia Hardware test sets with a built-in RFC 2544 button. Point them at a device, press go, get the four-part report.
T-Rex, TRex, iperf-style scripts Open-source and software traffic generators used to run 2544-style sweeps without a five-figure test set.
64-byte line rate The brutal corner of the test. Smallest frames mean the most packets per second, so this is where forwarding hardware is most likely to buckle.

Questions people actually ask

What is an RFC 2544 test? +

A standardized bench test for a switch or router. It measures four things across a fixed set of frame sizes: throughput (the highest rate with zero frame loss), latency, frame loss rate under overload, and back-to-back burst tolerance. Because every lab runs the same procedure, the results from a vendor and a buyer can be compared directly.

What is the difference between RFC 2544 and Y.1564? +

RFC 2544 tests one flow at a time and was designed to qualify a single device on a bench. ITU-T Y.1564 (EtherSAM) tests several services at once with their real bandwidth profiles and pass/fail thresholds, which fits turning up a live carrier Ethernet circuit. Rule of thumb: 2544 for the box in the lab, Y.1564 for the service on the wire.

How long does an RFC 2544 test take? +

It depends on how much you run. The spec says each trial should last at least 60 seconds, and a full run repeats every test across seven frame sizes, often with a binary search for throughput. A thorough throughput-plus-latency sweep is typically tens of minutes to a few hours. Operators frequently shorten trials for field turn-up, which is a documented trade-off against accuracy.

Does RFC 2544 test TCP? +

No. It generates raw Ethernet or IP frames at fixed sizes and rates, with no TCP connection, congestion control or retransmission. It measures how fast the hardware forwards packets, not how fast a file transfers or a web page loads. That is why a device can pass 2544 at line rate and still feel slow to an application.

Can I run an RFC 2544 test on a live network? +

You should not. The test deliberately overloads the device to find its limits, which competes with real user traffic and can distort or degrade the network. RFC 6815 (2012) makes this explicit in its title: use on production networks is considered harmful. Run 2544 on an isolated bench, and use Y.1564 or TWAMP for live measurement.

How RFC 2544 connects

What came before

  1. RFC 1944 (1996) was the original version of this same methodology. RFC 2544 is its revised second edition and obsoletes it entirely.

Part of a guided cluster: The network operations RFCs, explained