Summary

  • RFC 2398 catalogued twelve TCP testing tools by purpose, construction, automation, availability and required environment rather than treating “testing” as one interchangeable activity.
  • Active impairment, live-stack measurement, packet capture, offline analysis and graphing produced different evidence; a plot or throughput number could not alone prove correctness, security or application success.

In 1998, TCP testing did not fit inside a single laboratory instrument. One tool coordinated many transfers and wrote logs. Another placed delay, queue and bandwidth limits inside a running protocol stack. Another turned a Linux machine into a “selectively bad” router. Others injected faults, crafted packets, inspected captures or plotted sequence numbers against time. RFC 2398 gathered twelve of them into one catalog.

The catalog’s structure mattered as much as its contents. Every entry had to identify its category, describe how the tool worked, state what automation and human intervention remained, say where it could be obtained, and disclose the environment needed to run it. That form prevented a tool name from standing in for a method. The same graph could mean little if nobody recorded how the traffic was produced, which stack was under test or which assumptions shaped the analysis.

The RFC used three categories: functional correctness, performance and stress. They were related but not interchangeable. A TCP could move data quickly without following every required behavior. It could conform under a simple exchange and fail under load. A stress result could expose fragility without explaining whether the fault belonged to the implementation, the measurement path or the test harness.

The twelve entries occupied different places in that chain. Dummynet simulated queues, bandwidth and delay between layers of a real stack. NIST Net delayed, dropped, duplicated or constrained packets as a selectively bad router. Orchestra inserted a scripted fault layer able to reorder, modify or invent messages, but still left the user to inspect a trace for correct or incorrect behavior. These tools changed conditions and then watched what the implementation did.

Tcpanaly began later in the evidence path. It inspected tcpdump traces using encoded knowledge of many implementations, tried to explain why each packet had been sent, and could distinguish a likely measurement error from a behavioral deviation. RFC 2398 admitted that its category was hard to name because it profiled behavior rather than applying one fixed test. Tcptrace calculated retransmissions, round-trip times, windows and throughput, while Tracelook and Xplot turned capture variables into pictures. They helped the observer see; they did not create the event they displayed.

Netperf, TReno and Ttcp exposed another boundary. A throughput or latency figure depended on what generated the traffic and whose TCP behavior it included. TReno deliberately timed UDP or ICMP packets as a conforming congestion-controlled TCP might, aiming to measure a path independently of the end hosts’ TCP implementations. That made it useful for a different question, not a superior answer to every TCP question.

The RFC was modest about its authority. The list contained tools reported through the TCP Implementer’s working group. It was not exhaustive. The authors verified publication-era availability, not permanent maintenance, present compatibility or universal fitness. An availability URL was evidence that a tool could then be obtained, not a promise that the same endpoint would endure.

Its security section drew an even harder line. Some tools could create rogue packets or denial-of-service conditions. Some required foreign kernel code or root privilege. Packet capture could expose other people’s mail and files. Yet none of the listed tools evaluated security “in any way or form.” Capability to disturb a network was not proof that a tool could judge its security.

The graph, then, was never the test. It was one representation near the end of a longer custody chain: chosen tool, required environment, injected or observed condition, implementation build, traffic, capture, calculation, visualization and human interpretation. Lose one link and a clean line may become an attractive anecdote. Preserve them, and a result can say exactly what happened—without claiming more than the experiment was built to know.

Sources