Re: [tcpm] TCP tuning

[Kacheong Poon <kacheong.poon at sun.com>]

On 02/ 4/10 06:10 AM, Michael Welzl wrote:

> Without trying to get into a debate on engineering vs. research, I would
> say that the research community's perception of TCP research is that,
> indeed, such a change is a valid research question. That's not because
> of a need to find the "best, elegant, risk free solution", but because
> of the need to make sure that it's a solution that's safe to deploy.
>
> This is indeed at odds with needs for timeliness - but your need for
> that can't be the basis for lowering the bar about significant changes
> to TCP in the IETF.


Something interesting to "chit-chat" during coffee break...  I
think the history of the current RFC 3390 limit is like the
following.  Please correct me if I am wrong.

The original limit was 1.  But because of an implementation mistake
in BSD, the reality was actually 2.  And IETF accepted the reality.
Then folks realized that during slow start, TCP almost always sent
a burst of 3 segments because of delayed ACK.  So people thought that
around 4380 (3 * 1460 bytes which is a common segment size) was fine
and came up with a formula as in RFC 3390.

Just wondering, if there were no bug, would the initial cwnd be
increased almost 10 years ago?  Note that I am not trying to start
a debate on history nor reality vs research ;-)



--

						K. Poon.
						kacheong.poon at sun.com