Isochronous (fixed period) send schedule¶

•

It's easy to implement

•

It's easy to calculate how many packets and how much data will be sent in a given time

•

It simplifies timer error compensation

Also, isochronous packets are commonly seen in VoIP, games and some streaming media, so it already simulates an array of common types of traffic.

Fixed packet lengths for a given test¶

Stateful protocol¶

•

Smaller packet sizes (a design goal) as context does not need to be included in every request

•

More accurate measurement of upstream vs downstream packet loss (this gets worse in a stateless protocol as RTT approaches the test duration, complicating interplanetary tests!)

•

More accurate rate and test duration limiting on the server

In-memory results storage¶

•

It's easier to perform statistical analysis (like calculation of the median) on fixed arrays than on running data values

•

We don't need to either send client timestamps to the server, or maintain a local running window of sent packet info, because they're all in memory, no matter when server replies come back

•

Not accessing the disk during the test to write test output prevents inadvertently affecting the results

•

It simplifies the API

As a consequence of storing results in memory, packet sequence numbers are fixed at 32-bits. If all 2^32 sequence numbers were used, the results would require over 300 Gb of virtual memory to record while the test is running. That is why 64-bit sequence numbers are currently unnecessary.

64-bit received window¶

•

Per-packet differentiation is not available (for any intervening packets) if greater than 64 packets are lost in succession. These packets will be marked with the generic Lost.

•

While any packet marked LostDown is guaranteed to be marked properly, there is no confirmation of receipt of the receive window from the client to the server, so packets may sometimes be erroneously marked LostUp, for example, if they arrive late to the server and slide out of the received window before they can be confirmed to the client, or if the received window is lost on its way to the client and not amended by a later packet's received window.

There are many ways that this simple approach could be improved, such as by:

•

Allowing a wider window

•

Encoding receipt seqnos in a more intelligent way to allow a wider seqno range

•

Sending confirmation of window receipt from the client to the server and re-sending unreceived windows

However, the current strategy means that a good approximation of per-packet loss results can be obtained with only 8 additional bytes in each packet. It also requires very little computational time on the server, and almost all computation on the client occurs during results generation, after the test is complete. It isn't as accurate with late (out-of-order) upstream packets or with long sequences of lost packets, but high loss or high numbers of late packets typically indicate more severe network conditions that should be corrected first anyway, perhaps before per-packet results matter. Note that in case of very high packet loss, the total number of packets received by the server but not returned to the client (which can be obtained using --stats=count) will still be correct, which will still provide an accurate average loss percentage in each direction over the course of the test.

Use of Go¶

•

Non-negligible system call overhead

•

A larger executable size than with C

•

Somewhat slower execution speed than C (although not that much slower (https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc))

However, Go also has characteristics that make it a good fit for this application:

•

Go's target is network and server applications, with a focus on simplicity, reliability and efficiency, which is appropriate for IRTT

•

Memory footprint tends to be significantly lower than with some interpreted languages

•

It's easy to support a broad array of hardware and OS combinations