Summary

  • An aggregate throughput target can be met without settling the performance of one connection or the delay experienced while the path is busy.
  • RFC 6349 puts transfer time, retransmitted bytes and added round-trip delay alongside one another. Its results can reveal a trade-off without assigning fault.
  • A useful handover identifies the tested operating envelope, the remaining customer-workload gap and who is responsible for investigating it.

Imagine a service handover at which both sides agree on the number. The test has moved data at the expected aggregate rate. The supplier can demonstrate capacity; the customer can show a completed test. A week later, the application owner asks why a particular transfer still takes too long.

That is a hypothetical situation, not a documented complaint about a provider. Its interest lies in the possibility that neither side made a false statement. A collection of simultaneous connections and a single important transfer are different workloads. A busy link can move plenty of bytes while also imposing waiting time. Agreement on a rate need not be agreement on the service that matters.

The unresolved decision is therefore not merely how to measure speed more accurately. It is which combination of performance characteristics the customer is prepared to accept—and whether the people closing the installation have authority to accept that combination on behalf of the people operating the application.

A framework with a deliberately limited promise

RFC 6349, published in August 2011, offers a practical framework for assessing sustained TCP performance across a managed IP network. It is an Informational IETF document, not an Internet Standards Track specification. Its scope is useful precisely because it is narrower than a promise that every application will feel fast.

The document addresses performance once TCP has reached the sustained operating condition it calls equilibrium. It does not set out to predict the transient beginning of a connection, definitively rank operating-system TCP implementations or provide detailed diagnosis of every endpoint and network problem. Its distinction between provisioned access capacity and end-to-end performance is equally important: a commitment at one access segment does not establish the behavior of the entire path.

For a service buyer, this is not a reason to dismiss the test. It is a reason to retain its boundaries. A test of sustained data transport can answer an important capacity question without answering a short-transaction question. Extending its conclusion after the fact creates an expectation that the original measurement was not designed to carry.

A defensible acceptance record would consequently name the path endpoints, direction, test conditions and intended workload. “The network passed” is too large a statement if the evidence concerns one direction between two test hosts during a particular interval. This is a recommendation about the use of evidence, not a new requirement added to the RFC.

Parallel success and an individual shortfall can coexist

TCP has limits on how much data can remain in flight while the sender awaits acknowledgment. The available path capacity and round-trip time help determine how large that allowance needs to be. The framework uses the bandwidth-delay product to connect those conditions with the sending and receiving configuration.

A single connection with an inadequate allowance may be unable to exploit the available capacity. Several connections can collectively place more data in flight. An aggregate result can therefore improve when more connections are introduced, even though the experience of one window-limited transfer has not been solved.

There is nothing inherently improper about the multiple-connection test. An office containing many concurrent users may be better represented by several connections than by one specially tuned flow. The error would be to let a test chosen for that office stand without explanation for a workload that depends on one serial transfer.

The reverse mistake is also possible. A poorly configured test endpoint can make a capable path appear inadequate. Buying more bandwidth would not automatically remove that endpoint limitation. Before a commercial disagreement becomes a dispute over the network, the test instrument itself has to be capable of producing and receiving the intended traffic.

The framework's examples make the dependency concrete, but their historical operating-system defaults and hardware remarks should not be treated as a contemporary equipment guide. What survives is the question: whose workload does the connection count represent? A provider demonstration, a customer application and a diagnostic experiment may all legitimately choose different counts. They should not silently inherit the same acceptance conclusion.

The completed transfer has more than one cost

The framework gives three metrics a place in the result. Transfer Time Ratio compares actual completion time with an ideal duration derived from achievable TCP throughput. That ideal accounts for relevant overhead assumptions; it is not just the nominal interface bit rate written into a denominator.

TCP Efficiency looks at the share of transmitted bytes that were not retransmissions. Its transmitted total includes the original transmissions and the repeated bytes. The metric describes retransmission burden. It is not an application-success percentage, an energy-efficiency score or a direct identification of which device lost a packet.

Buffer Delay compares average round-trip time during the transfer with the baseline round-trip time, expressing the increase relative to that baseline. The underlying baseline and loaded values remain important. A percentage alone does not tell an application owner whether an absolute response-time budget has been met.

These are not three competing ways to award the same prize. They describe different features of the run. The interpretation section of RFC 6349 explicitly recognizes that the same transfer-time result can accompany better TCP Efficiency at the cost of higher Buffer Delay.

That observation puts a choice back into an otherwise tidy acceptance meeting. One operating condition may repeat fewer bytes while making packets wait longer. Another may have more retransmission burden without the same loaded delay. The source does not establish a universal commercial preference between them, and an aggregate rate cannot supply one.

A bulk transfer with a generous completion deadline and an interactive workload may value those conditions differently. This does not mean the three metrics fully predict either application. It means that collapsing them into one pass mark can hide a choice that should be made in relation to the actual work.

Nor is zero retransmission a sensible universal moral standard. Retransmission can arise as TCP responds to its environment. The relevant inquiry is what the observed behavior costs under the tested conditions, whether that cost is acceptable and what further evidence would explain it. A counter is more useful as a prompt for investigation than as an accusation.

Acceptance is not fault allocation

RFC 6349 describes several possible contributors to a shortfall: congestion, endpoint buffer limitations and intermediate devices that regenerate TCP are among them. Its metrics help structure an investigation, but the framework expressly stops short of detailed diagnosis.

A customer and provider can therefore agree that an outcome is unsatisfactory before they know which component caused it. Keeping those decisions separate is commercially useful. Otherwise, evidence of a shortfall can be rejected because responsibility is unresolved, or a party can be blamed simply because it happens to control the most visible component.

Consider a hypothetical test that performs well between purpose-built endpoints while the customer's application remains slow. The controlled result narrows the question; it does not make the application complaint disappear. The next inquiry concerns the differences in endpoints, workload and path conditions. Conversely, a poor controlled result is reason to investigate the tested envelope, not proof that every use of the service is defective.

The important handover artifact is a shared account of what remains open. Who will supply the endpoint information? Which team can inspect the relevant path? What result would change the next decision? Without that agreement, a certificate can terminate the project administratively while leaving the diagnostic work without an owner.

The test must not become the impairment

The desire for a decisive measurement introduces its own operating risk. A test that tries to exercise capacity consumes resources while it runs. RFC 6349 discusses cooperation between customer and provider and does not propose permanent operation under high measurement loads.

A separate applicability statement, RFC 6815, explains why RFC 2544 laboratory overload benchmarks must not be used on production networks. Uncontrolled traffic can undermine the interpretation, while overload can harm traffic sharing the resources. That warning does not prohibit every live-network measurement; it rejects carrying those laboratory methods beyond their isolated scope.

This matters when lower-layer validation is treated as a box to tick before TCP testing. The prerequisite is not permission to run a laboratory overload procedure through a working customer network. A measurement plan still needs an appropriate method, an agreed boundary and authority over the exposure it creates.

No load test was performed for this report. The point is a decision principle: the team seeking evidence should not be allowed to externalize the cost of obtaining it onto users who were not part of the acceptance discussion.

A narrower sign-off can be more useful

The best outcome of a throughput test is not the broadest possible claim. It is a sufficiently precise finding that the next team can use it without guessing what has already been established.

That finding may say that a particular workload achieves the required completion behavior within a tested envelope, while another workload remains under investigation. It may show that aggregate capacity is available but endpoint configuration needs attention. It may expose a delay/retransmission trade-off that requires an application owner to choose. Each is more actionable than declaring the network simply fast or slow.

A service handover is where evidence becomes permission to proceed. If the person granting that permission does not retain the conditions and unresolved choices, the operational organization inherits a conclusion without its meaning. The missing information is not a minor technical appendix. It is part of what was accepted.

Sources and limits

The RFC Editor publication record and errata search were checked on 8 September 2026; the errata search returned no matching records. They do not establish current deployment practice. Lu Heng's essays on reality rather than advocacy and the agency problem inform the questions about decision rights and economic exposure. Their registry-governance claims are not findings about the engineers or institutions discussed here. No customer contract, live result, vendor implementation or service dispute has been examined.