Measure TCP throughput with the path conditions that shape it

A low TCP test result does not by itself prove that a circuit is undersized. Throughput emerges from the end hosts and the entire path, including delay, loss, path MTU, bottleneck rate, TCP windows, parallel flows, and competing traffic.

Source fact:

IETF RFC 6349 provides an informational framework for practical end-to-end TCP throughput testing in a managed IP network. It calls for establishing path characteristics such as path MTU, round-trip time, and bottleneck bandwidth, then relating those characteristics to TCP window requirements and measured transfer performance. The framework defines metrics intended to make results more interpretable than an isolated speed number.

The method recognizes that TCP performance is affected by the bandwidth-delay product and retransmissions, and that host settings can constrain a test even when network capacity is available. It is designed to evaluate TCP throughput rather than only packet-forwarding capacity. The RFC is Informational, not an IETF Standards Track mandate or a promise that every application will achieve the test result.

Boundary

Synthetic tools may use different TCP implementations, numbers of streams, buffers, and data patterns than a production application. Encryption, storage, CPU, proxies, traffic shaping, Wi-Fi, VPN encapsulation, and cloud service limits can be the bottleneck. A test can also affect users if it fills a production link. Provider service-level measurements may define different methods and demarcation points.

Applicability questions

• What exact user or application transaction is the test meant to represent?
• Where are the controlled endpoints relative to firewalls, VPNs, proxies, and provider handoffs?
• What are the observed path MTU, round-trip time, bottleneck rate, and loss during the test window?
• Do host CPU, storage, window scaling, offload, or security inspection limit the result?
• How much test traffic can the production path safely tolerate?

DSE recommendation:

Define endpoint locations, direction, duration, stream count, protocol settings, traffic class, and acceptance criteria before testing. Verify path MTU and record round-trip time under low load. Measure available link and interface rates at each likely bottleneck. Run a conservative baseline, then increase load only within an approved window while monitoring live-user impact, loss, retransmission, CPU, and queues.

Repeat in both directions and at comparable times. Use a controlled host pair before introducing application servers, then compare the real application separately. When results differ, change one variable at a time rather than labeling the carrier, firewall, or server as the cause. Coordinate provider testing at the contractual demarcation when a service-level dispute is involved.

Verification and evidence

Keep tool and OS versions, endpoint specifications, topology, routing path, MTU evidence, RTT samples, interface counters, TCP statistics, test parameters, timestamps, and raw results. A useful record includes retransmissions and host resource use alongside throughput. It should also state concurrent production load and known policy limits so a later comparison is like-for-like.

Official references

• IETF RFC 6349