Cold Interweb Tubes in Action

‹prev | My Chain | next›

Last night I started play with tcptrace and xplot.org as tools to graphically analyze network traffic (mostly as it relates to SPDY and competing protocols). One thing that struck me as odd was the Firefox graph of a small image loaded on a "warm" interweb tube:



This particular tube had been warmed by first downloading a very large image over it. A "warm" interweb tube is a TCP/IP stream that has gone through the "slow start" period of it connection. At first, the congestion window (CWND), the amount of data that is sent before waiting for an acknowledgement, is quite small (on the order a network MTU). After a few round trips, the CWND has expanded significantly, allowing for larger chunks of data to be transferred.

The Firefox tube was definitely warm, but there are still those steps that look very much like additional warming. So what gives?

To answer that, I try downloading the same small image (http://www.ducksong.com/sortbycwnd/b.png, taken from the blog post on Firefox CWND) using curl. That should definitely be a cold tube.

But first, I open a tcpdump session to capture the packets going back and forth between the ducksong.com server:

sudo tcpdump -i usb0 host www.ducksong.com -w 02-ducksong_curl.pcap

Then I curl the PNG:

curl http://www.ducksong.com/sortbycwnd/b.png > /dev/null

And then I xplot.org the data in that tcpdump file:

➜  02  tcptrace -S -n 02-ducksong_curl.pcap
1 arg remaining, starting with '/home/cstrom/repos/spdybook/notes/2011/07/02/02-ducksong_curl.pcap'
Ostermann's tcptrace -- version 6.6.7 -- Thu Nov  4, 2004

58 packets seen, 58 TCP packets traced
elapsed wallclock time: 0:00:00.002043, 28375 pkts/sec analyzed
trace file elapsed time: 0:00:00.808258
TCP connection info:
  1: 192.168.42.48:32807 - 64.22.125.164:80 (a2b)   29>   29<  (complete)

I am not resolving any network resources (-n). I see 58 total packets, 29 going and 29 coming back. All packets are over a single tube, which tcptrace labels as a2b. tcptrace dumps to Time-Sequence plot, one for the request (a2b) and one for the response.

I xplot.org the response (b2a) to find:



That is pretty much what I expect on a cold tube. A couple of packets sent back, then a pause as a TCP/IP acknowledgement is sent, then a few more packets (more than the first clump), followed by another pause for an acknowledgement. Lastly comes the remaining data. The entire PNG image is transferred in around 2 tenths of a second (from the 12.55 second mark to the 12.75 second mark).

Next up, I try the same thing with Chrome. I follow the same experiment that I did yesterday warming a bunch of tubes (by downloading the main page from the blog post mentioned earlier). Then I click on that PNG. Examining the PNG network traffic in a Time-Sequence plot, I find:



That is really what I expected from a warmed tube. No waits for the CWND to increase, just pure download. And, without the warming overhead, nearly 50% less time is needed to transfer the image (no wonder SPDY aims to just use a single warm tube).

So what gives with the Firefox plot. Maybe I simple drew it at a bad scale? Aligning it to a window of ~3 tenths of a second like the other, I find:



Hrm... That's not it. Maybe I just need to retry the experiment again:



Hrm... Well. Firefox seems to be generating a small step for me regardless. I think I can chalk this up to small sample size for now, but I will definitely look into this more later. I would hate to have to explain those steps in SPDY Book if I don't have to (and it doesn't help with the narrative).

Regardless, both the latest Chrome (14) and Firefox (5) both seem to re-use high CWND tubes on secondary requests, significantly cutting down on network travel time for such requests.

Day #63