Re: [tcpm] TCP tuning

Any idle period higher than the RTT between HTTP requests tends to reset the cwindow down to the restart window. This hurts persistent connections too. What's the motivation for this, can we have a different slope while reducing the window instead of resetting all the way down?

-----Original Message-----
From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Jerry Chu
Sent: Wednesday, February 03, 2010 1:39 PM
To: Joe Touch
Cc: tcpm@ietf.org; SCHARF, Michael
Subject: Re: [tcpm] TCP tuning

On Wed, Feb 3, 2010 at 11:26 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> Jerry Chu wrote:
>> On Wed, Feb 3, 2010 at 7:17 AM, SCHARF, Michael
>> <Michael.Scharf@alcatel-lucent.com> wrote:
>>>> This topic seems to be gaining momentum, and the WG should
>>>> take some time considering if there is work here for it.
>>> IMHO there could indeed be room for increasing the initial window. If
>>> most data transfers continue to be smaller than 3 MSS, a larger initial
>>> window would not necessarily cause harm, as it is seldomly used. Still,
>>> this would speed up those data transfers that currently suffer from
>>> Slow-Start.
>>
>> 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.

There are other limitations of HTTP 1/1:

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.

>
> 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.

Jerry

>
> Joe
>
>
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm