[dmv]

Are you doing this on the site listed in your profile? From what I can see with a 27ms RTT request, there is a 9ms pause after the GET ACK and content -- and then only 4 full packets before an RTT. That's close to the limit of my initial window (5880) before content ACKs arrive. That would seem like a typical result unless/until clients start tuning their initial window as well... which was kind of the point of Google going public on this. Have you seen much aggregate benefit beyond a window increase from 2 to 4?

[necro]

Here is a pic of the transaction client side. The RTT is about 50ms. This is an intitial, non keep alive, request.

http://www.pinkbike.com/photo/4632455/

Notice that after the connection and the http request, in 1RTT you basically receive 10 segments at flight time (right after each other) This means the server is not waiting for you to ack. You see the acks in this picture (but note the times as they are sent but dont arrive till rtt at the server)

With out altering slow start the server would wait to receive and ACK before sending more segments.

There are 2 factors at play here... 1. slow start 2. window size Does not matter what the window size advertised, as slow start normally start at 2 segments. So in this case the client window is something huge. The advertised 5880 is the server receive window which also grows.