Re: [tcpm] TCP tuning

["Biswas, Anumita" <Anumita.Biswas at netapp.com>]

> -----Original Message-----
> From: John Heffner [mailto:johnwheffner at gmail.com]
> Sent: Wednesday, February 03, 2010 12:51 PM
> To: Jerry Chu
> Cc: tcpm at ietf.org WG
> Subject: Re: [tcpm] TCP tuning
> 
> On Wed, Feb 3, 2010 at 3:44 PM, Jerry Chu <hkchu at google.com> wrote:
> > Hi John,
> >
> > On Wed, Feb 3, 2010 at 12:32 PM, John Heffner
> <johnwheffner at 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.

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