[Tmrg] Proposal to increase TCP initial CWND

[fred at cisco.com (Fred Baker)]

To give you an idea of the kind of thing that concerns me, that I commented on earlier today, I ran an example of the kind of how-do-they-interact-with-competing-sessions test that I mentioned. I won't describe this as being in any sense scientific - it is a sample run and a bit of doodle-level analysis, without a control and without trying to root out root causes. It is what it is.

    ftp://ftpeng.cisco.com/fred/tmrg/image-captire-firefox-alone.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture-entire-run.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture-firefox+sftp.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture-safari+sftp.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture-safari-alone.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture-start-of-sftp.pdf
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture.csv
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture.pl
    ftp://ftpeng.cisco.com/fred/tmrg/image-capture.txt

The scenario is this:

I opened up http://tinyurl.com/2g5cqkh in both Firefox and Safari, which is to say "a google images page with a bunch thereof", and cleared my cache. I then started tcpdump running into image-capture.txt. 

I now:
    - waited a few seconds and refreshed the Safari window
    - waited a few more seconds and refreshed the Firefox window
    - cleared both caches again

I then started an SFTP, moving a file I expected to take about 146 seconds to move at the ambient bit rate from somewhere else to my machine. I then 
    - waited ~30 seconds and refreshed the Safari window
    - waited a few more seconds and refreshed the Firefox window
    - waited until the SFTP completed and then closed it all up.

I imported the whole lot into Excel for the purpose of drawing pretty pictures, and came up with the graphics you see. The reduction program I used to pull the data together distinguished between TCP sessions, ignored jabber, Facebook, time checks, and a host of other noise level traffic, and bucketized information into 50 ms windows of time, reporting it in effective bit rate (bps). 

One observation: SACK was reported on roughly one segment in 50, roughly evenly distributed so that most RTTs had at least one SACK block, and the interval from 11:19 to 11:25 was reporting 3 SACK blocks pretty frequently. If one wants a poster child for why manically aggressive tune-to-the-cliff behavior is a waste of bandwidth, the cases in ftp://ftpeng.cisco.com/fred/tmrg/image-capture-start-of-sftp.pdf where throughput sags below 2 MBPS (my nominal bitrate from my ISP) should serve. Note that this is one SFTP/STCP session with nothing competing with it, never mind the question before the house of other sessions coming up with IW values that effectively disable congestion control. One expects drops when other TCPs are starting up, and one expects TCP to slow down in a TCP-friendly manner. What I observed here was a lot more than that.

I presume that Google is running IW=4; for example, the session labelled stealth-10-32-244-222.cisco.com.59583 has four segments arrive approximately 12:10:40.86. What I observed here was Safari and Firefox deciding (when competing with the SFTP) that they needed more than one TCP to make the right thing happen, and opening up several of them. With IW=4, on the HTTP sessions, SFTP slowed down dramatically, in some cases apparently experiencing enough loss that they paused for a retransmission timeout.

You want IW=10? And that on a relatively high bandwidth (2 MBPS) link as compared to the lower bandwidths predominant outside the high capacity network that connects Australia and Eastern Asia across North America to Western Europe and Scandinavia?