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 pc1: 10.0.1.1 pc2: 10.0.2.1 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 workSince my interest started to grow how other TCPs would perform I wrote a little script - see [5] - experiment2. Have a look at auto_tcp_test.sh 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:
There are other issues but since this work might inspire you for further experiments I uploaded it anyway. Have fun! links
![]() |