Re: [tcpm] TCP tuning

[Jerry Chu <[e-mail]>]

+nandita

On Wed, Feb 3, 2010 at 2:25 PM, Joe Touch <[e-mail]> wrote:
>
>
> 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.

I'm 100% with you on this, and have been working hard on a detailed report
on our experiments done so far to be published in the next few weeks.

Jerry

>
> Joe
>
>