fishi0x01 / tcp-metrics

A tool to measure the round-trip time and bandwidth of a TCP connection with different methods.

tcp-metrics

A tool to measure the round-trip time and bandwidth of a TCP connection with different methods. Bandwidth (or more precisely Goodput) is measured with the harmonic mean. rtt is measured via weighed moving average.

Currently tcp-metrics only supports resources that are available via HTTP/1.1. The reason for this is that most static resources are available via HTTP and it is easy to deploy a static testing resource on a HTTP server.

Two methods are available to measure the Goodput:

1.: by using the first socket.read() timestamp as the start time.

2.: by using a later subsequent socket.read() timestamp as the start time (to avoid bursts and slow-start falsifying the estimate).

For detailed information concerning the techniques applied please check out http://fishi.devtail.com/weblog/8/

Usage

Usage: tcp-metrics [OPTION...] DOMAIN PATH

Example: tcp-metrics yourdomain.com /your/resource

  -a, --all                  Measure everything - option1 + option2 + rtt.
  -b, --bandwidth-method-A   Measure the bandwidth with option 1, meaning the
                             first socket.read() operations are skipped in
                             order to avoid initial bursts and TCP slow-start
                             to falsify the result.
  -c, --bandwidth-method-B   Measure the bandwidth with option 2, meaning we
                             measure beginning from the first socket.read()
                             operation.
  -k, --skips=Skips          Number of socket.read() Skips to avoid bursting
                             and TCP slow-start to falsify the result - by
                             default this value is 10. Note that a value of 0
                             here would be the same as using measurement option
                             2 (-c).
  -m, --multi                If set, for each round a different TCP socket is
                             used. That way you might get a better overall
                             estimate about an expected path between the client
                             and the resource. Please note, that you need at
                             least two measurement rounds for this option,
                             since otherwise you will only use one TCP socket
                             anyways...
  -n, --rounds=Rounds        Number of repeated measurement Rounds. In order
                             to get a fair estimate of the rtt, several rounds
                             should be used. By default this value is 1.
  -p, --port=Port            The Port the resource to measure is available at
                             - default is 80.
  -r, --rtt                  Measure the rtt.
  -s, --size=Size            Size of the receiver buffer - if not specified,
                             by default a 2MB receiver buffer is used. Note
                             that on each socket.read() the buffer is written
                             from the start (it is just a dummy buffer...).
                             Please note, that if this buffer is to small, the
                             socket.read() operation does not have enough
                             memory to store data to - thus a huge bottleneck
                             in the application layer would occur.
  -t, --timeout=Timeout      The socket Timeout in seconds - by default 2s.
  -v, --v                    Verbose - print subsequent estimates to stdout.
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

tcp-metrics's Issues

RTT measured only once

I found the explanation of your code at the following link:
https://fishi.devtail.io/weblog/2015/04/12/measuring-bandwidth-and-round-trip-time-tcp-connection-inside-application-layer/

it clearly states: In case we have multiple round-trip time estimates (several download rounds), we need to combine them to one fair estimate. The TCP layer also estimates the round-trip time (for retransmission purposes) using the weighed moving average. We could do the same on an application layer.

However, I do not understand how it could handle multiple downloads if the function measure_rtt is called only once (due to the flag first_packet)

// very first socket.read()
if(first_packet)
{
    // RTT
    rtl = measure_rtt(&start_ts,&cur_ts);
    gettimeofday(&first_pack_ts,NULL);
    first_packet = 0;
}
else
{
    // OPTION 2: we take the request sent timestamp as the start time
    bw_b = measure_bw(&first_pack_ts,&cur_ts,bytes,1);
}