Re: [tcpm] TCP tuning

[Joe Touch <[e-mail]>]

Jerry Chu wrote:
....
>>> Actually our data points to the contrary - the average web object and page
>>> size have been rising steadily. E.g., the majority of our search responses
>>> no longer fit in 3 MSS these days.
>>
>> This should be relevant only for the first response from a given IP
>> address; persistent connections should render this moot for subsequent
>> requests.
> 
> Yes we are well aware of the advantage of maintaining persistent connections.
> In fact this is one of the reasons holding us back from resurrecting T/TCP
> (in addition to other security issues).
> 
> But from our own observation the average HTTP connections just don't
> persistent that long for some reason. I don't remember the data or all
> the technical reasons on top of my head, but can surely try to get them for
> you.

I think having all of that in one place would be a good start.

> There are other limitations of HTTP 1/1:

Persistent connections predates 1.1, FWIW ;-)

> 1. obviously its effectiveness depends on user's web surfing pattern.
> 2. web browsers have been going down the slope of opening more and
> more simultaneous connections anyway, partly to circumvent HTTP's
> serialization, an issue SPDY tries to address.
> 3. practically web servers have only limited resources. can't hold too many
> open connections.
> 4. a web object will make the TCP slow start algorithm to grow its cwnd
> only upto the size of the object. As such, even with persistent connections,
> a web object that is larger than any of its predecessors will hit the window
> limit, and take more than one round trip time to complete. So persistent
> connections might not be as effective as one might think.

This all depends on many things - e.g., whether the persistent
connection is used for a sequence of requests or whether they are
interleaved using HTTP 'chunks', the size of the chunks, etc.

It's useful as well to keep in mind that HTTP exists because Tim
Berners-Lee thought that FTP would be too inefficient, because 'most of
the time you only get one file from a site', and he didn't want to open
two connections. I.e., one other alternative is to consider FTP's
version of multiplexing as well.

>> Again, the question arises as to how much this is going to achieve a
>> noticeable impact.
> 
> Quite significant in our study. Will present our result at IETF/Anaheim.

We've seen initial work on this before, and had a number of questions
that remain unanswered. A good start would be to put this all in a tech
report. Presentations at the IETF should not get into deep technical
detail; they ought to summarize work available before the meeting and
provided on the list IMO.

Joe