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.
\nIETF 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.
\nThe 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.
\nSynthetic 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.
\nDefine 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.
\nRepeat 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.
\nKeep 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.
\n