Re: [tcpm] TCP tuning

[Joe Touch <[e-mail]>]

Kacheong Poon wrote:
> 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.

That, and a LOT of simulation analysis. The other alternative was to
declare this a bug and recommend against it.

> 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 ;-)

It's hard to say whether there would have been motivation to look at the
issue so deeply were it not for the bug, but ultimately it was the depth
of analysis that convinced the group to approve the change.

Joe