Lately I was reading RFC 2001 [1] and trying to figure how this RFC fits into the graph produced by a trace using wireshark I started to realize that RFC 2001 would not match. After finding RFC 2581 [2] I realized that this didn't fit either so I wondered what this 'congestion avoidance' was all about and how it is actually done.

After searching the linux kernel source code it was easy to see that a TCP called 'cubic' was used by default. There is a very good paper [3] providing in detail information about 'cubic'-TCP in comparison to 'bic'-TCP. The paper also names the most important aspects of other TCP implementations.

So again I wondered how to draw a 'tcp stream graph' using 'stevens' style inspired by the TCP/IP Book written by stevens 'et al.'. Another interesting page is [4] where I got inspired using 'iperf' instead of ttcp for testing TCP performance and other parameters.

As [4] illustrates I used gnuplot for drawing the cwnd and ssthresh. I created an overlay graph featuring both graphs drawn in the same timeline. The result is pretty cool and can be found in [5] in the folder 'experiment1' or directly by [6].

One can find very interesting graphs at [9] as well.


this picture shows a tcp flow with interruptions. the used tcp was 'cubic'

The experiment:

Let's get into details what [6] actually shows:

The setup:

pc1 <----> cisco router1 <---- serial slow link ----> cisco router2 <----> pc2

ttcp was used to transmit data from pc1 to pc2 so pc1 is the 'sender' and pc2 is the 'receiver'. The graph [6] was recorded using wireshark on the senderside 'pc1' and the graph was generated using wireshark - tcp stream graph - stevens.

There was a little ping flood so the tcp connection was forced to interrupt. The ping flood started at sec 15 and ended soon afterwards - see [7] for details.

The other graph was created using the gnuplot script using /proc/net/tcpprobe from [4] which is really cool! Good work the kernel developers made - at least I love it.

The graph:

You might wonder - what is that graph [6] actually good for? Valid question.

The answer is that [6] shows how TCP-Cubic works. It was quite a surprise for me seeing that this works so much different than I had expected reading [1] and [2] that I had to write this little blog entry.

Further work

Since my interest started to grow how other TCPs would perform I wrote a little script - see [5] - experiment2. Have a look at to get an idea what the 'traces' actually show. There are some issues I didn't fix yet (maybe I won't at all) for example:

  • found no way to use lua to draw the stevens graph automatically.
  • when using two instances which then use two TCP streams one has to sort data coming from /proc/net/tcpprobe which I didn't do yet - so some graphs are wrong.

There are other issues but since this work might inspire you for further experiments I uploaded it anyway.

Have fun!


Powered by MediaWiki