Re: [tcpm] TCP tuning

Hi Anumita,

On Wed, Feb 3, 2010 at 1:50 PM, Biswas, Anumita
<Anumita.Biswas@netapp.com> wrote:
>
>
>> -----Original Message-----
>> From: John Heffner [mailto:johnwheffner@gmail.com]
>> Sent: Wednesday, February 03, 2010 12:51 PM
>> To: Jerry Chu
>> Cc: tcpm@ietf.org WG
>> Subject: Re: [tcpm] TCP tuning
>>
>> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu <hkchu@google.com> wrote:
>> > Hi John,
>> >
>> > On Wed, Feb 3, 2010 at 12:32 PM, John Heffner
>> <johnwheffner@gmail.com> wrote:
>> >> A couple thoughts:
>> >> - A large initial window should probably only be used by mutual
>> >> agreement.  Maybe via a TCP option during the handshake?
>> >
>> > This may not be needed. A receiver can effectively constrain the
>> > sender's window by advertising a smaller initial receive window.
>> >
>> > Obviously this works for only the initial window, not the restart
>> window.
>> > (Oh, on a second thought this can be made to work for the restart
>> > window too.)
>>
>> A good point, though most receivers (Linux 2.4 and later being the
>> exception) advertise all available window space, not expecting a large
>> initial burst from the sender.  I think you need a negotiation for
>> opt-in rather than opt-out.
>
> The slow start algorithm tries to probe the network capacity, not the end node's available window space. The network capacity is dependent on switch/router queue lengths, among other things and therefore the initial receive window is not something that can/should be negotiated by end points.
>
> However, I do have reservations with standardizing an increased initial window assuming that 10 MSS is a good "guess" for what the network can tolerate.
>
> I have seen cases where switches topple over initial receive window sizes as spec'd out by RFC 3390. In fact, RFC 3390 does state that the recommended IW value of 4 segments for 1500MSS can cause more loss in networks with higher segment drop rates.

Understood the concern. But sometimes we'll need to take active action
in order to break the
deadlock - TCP spec relying on switch/router upgrade while equipment
vendors waiting for
TCP spec to be ratified. In this case a modest increase of initcwnd
may well be the right one
to get both sides into a healthy lockstep toward a faster Internet.
This is because the negative
impact (% of access switch/router with tiny buffer) is limited and
easy (IMHO) to fix while the
gain can be significant for the vast majority. This is a good
incentive to encourage those left
behind to move up the bandwidth curve.

Jerry

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