From owner-psarc Tue Dec 14 12:11:30 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16831.18646.459398.47051@gargle.gargle.HOWL> Date: Tue, 14 Dec 2004 15:11:02 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: kacheong.poon@sun.com Subject: 2004/838 TCP Congestion Window Option Content-Length: 1971 I'm sponsoring this fast-track request for Kacheong Poon. The timer is set to 12/21/2004. (An analogous feature for SCTP would be possible, but isn't proposed at this time. A search for similar OS features came up with slideware for an apparently dead Linux experiment, but no other references.) This project asserts a Patch/Micro release binding and the stability level is Stable. Currently, the TCP initial congestion window (cwnd) is calculated following RFC 3390. The default can also be modified using the ndd parameters tcp_slow_start_initial and tcp_slow_start_after_idle. As requested by Ericsson, they want a TCP socket option to control the initial cwnd on a per socket basis. This is to be used in their WAP gateway application. This project implements a TCP socket option, TCP_INIT_CWND. It controls both of the cases handled by the two ndd params. The semantics are described below (a diff on the tcp(7P) man page). *************** *** 147,152 **** --- 156,172 ---- erwise loses state information about a TCP connection, the connection is aborted and an error is returned to the user. + TCP follows the congestion control algorithm as described in + RFC 2581. And it also supports the initial congestion window + (cwnd) changes in RFC 3390. The initial cwnd calculation can + be overridden by the socket option TCP_INIT_CWND. An application + can use this option to set the initial cwnd to a specified + number of TCP segments. This applies to the cases when the + connection first starts and restarts after an idle period. The + process needs to have the PRIV_SYS_NET_CONFIG privilege if it + wants to specify a number greater than that calculated by RFC + 3390. + SunOS supports TCP Extensions for High Performance (RFC 1323) which includes the window scale and time stamp options, and Protection Against Wrap Around Sequence Numbers From owner-psarc Tue Dec 14 13:14:20 2004 X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2004/838 TCP Congestion Window Option From: Bill Sommerfeld To: James Carlson Cc: psarc@sac.sfbay.sun.com, Kacheong.Poon@sun.com In-Reply-To: <16831.18646.459398.47051@gargle.gargle.HOWL> References: <16831.18646.459398.47051@gargle.gargle.HOWL> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103058822.26149.26.camel@thunk> Mime-Version: 1.0 Date: Tue, 14 Dec 2004 16:13:43 -0500 Content-Length: 1315 On Tue, 2004-12-14 at 15:11, James Carlson wrote: > + TCP follows the congestion control algorithm as described in > + RFC 2581. And it also supports the initial congestion window > + (cwnd) changes in RFC 3390. The initial cwnd calculation can > + be overridden by the socket option TCP_INIT_CWND. An application > + can use this option to set the initial cwnd to a specified > + number of TCP segments. This applies to the cases when the > + connection first starts and restarts after an idle period. The > + process needs to have the PRIV_SYS_NET_CONFIG privilege if it > + wants to specify a number greater than that calculated by RFC > + 3390. I think this needs a big network health warning -- use of too large a value may cause congestive collapse in the network. Also, the algorithm in 3390 is based on both the number of segments *and* the MSS (presumably as modified by path MTU). there does not appear to be any way for a program to learn the current MSS or to adjust the CWND based on the MSS. (I'm concerned that this may be too coarse a knob. well, perhaps this is intended for use solely in a walled-garden environment where they (think they) know the MSS, but once it's out there we don't have much control over how customers use it.) From owner-psarc Tue Dec 14 15:03:35 2004 Message-ID: <41BF7128.1080701@sun.com> Date: Tue, 14 Dec 2004 15:03:04 -0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041116 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2004/838 TCP Congestion Window Option References: <16831.18646.459398.47051@gargle.gargle.HOWL> <1103058822.26149.26.camel@thunk> In-Reply-To: <1103058822.26149.26.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 1081 Bill Sommerfeld wrote: > I think this needs a big network health warning -- use of too large a value > may cause congestive collapse in the network. This is the reason why the process changing it to a value larger than that allowed by RFC 3390 requires special privilege. For a normal app, all they can do with this option is to lower it. And this is what Ericsson wants, to set it to 1 for some networks. > Also, the algorithm in 3390 is based on both the number of segments *and* the MSS > (presumably as modified by path MTU). there does not appear to be any way for > a program to learn the current MSS or to adjust the CWND based on the MSS. The option TCP_MAXSEG lets an app find out the MSS. > (I'm concerned that this may be too coarse a knob. well, perhaps this is intended > for use solely in a walled-garden environment where they (think they) know the MSS, > but once it's out there we don't have much control over how customers use it.) With open source, people can do all sorts of things already (-: -- K. Poon. kacheong.poon@sun.com From owner-psarc Tue Dec 14 15:21:02 2004 X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2004/838 TCP Congestion Window Option From: Bill Sommerfeld To: Kacheong Poon Cc: psarc@sac.sfbay.sun.com In-Reply-To: <41BF7128.1080701@sun.com> References: <16831.18646.459398.47051@gargle.gargle.HOWL> <1103058822.26149.26.camel@thunk> <41BF7128.1080701@sun.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1103066427.26684.15.camel@thunk> Mime-Version: 1.0 Date: Tue, 14 Dec 2004 18:20:28 -0500 Content-Length: 950 On Tue, 2004-12-14 at 18:03, Kacheong Poon wrote: > This is the reason why the process changing it to a > value larger than that allowed by RFC 3390 requires > special privilege. For a normal app, all they can do > with this option is to lower it. And this is what > Ericsson wants, to set it to 1 for some networks. so they have no need to increase the value, but merely want to reset it to the original one-segment VJ cwnd algorithm? do we have any evidence that anyone wants to run with a CWND value substantially larger than permitted by 3390? is there any reason why we shouldn't cap it at 2x the 3390 value even if privileged? > With open source, people can do all sorts of things > already (-: yes, but we do not have to give them an armed foot-seeking guided missile. I have not exactly fond memories of the ARPAnet backbone while it was in congestive collapse before the widespread deployment of slow-start TCP. - Bill From owner-psarc Tue Dec 14 15:50:20 2004 Message-ID: <41BF7C20.2050003@sun.com> Date: Tue, 14 Dec 2004 15:49:52 -0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041116 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2004/838 TCP Congestion Window Option References: <16831.18646.459398.47051@gargle.gargle.HOWL> <1103058822.26149.26.camel@thunk> <41BF7128.1080701@sun.com> <1103066427.26684.15.camel@thunk> In-Reply-To: <1103066427.26684.15.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 986 Bill Sommerfeld wrote: > so they have no need to increase the value, but merely want to reset it to > the original one-segment VJ cwnd algorithm? This is the example they gave me when I asked how the option to control the initial cwnd is going to be used. > do we have any evidence that anyone wants to run with a CWND value > substantially larger than permitted by 3390? It depends on what "substantially larger" means here. I've heard people who want it to be higher in their controlled environment, such as their own satellite link. But those people know exactly what they are doing. They understand the consequence of doing that. > is there any reason why we shouldn't cap it at 2x the 3390 value even if > privileged? The next question a customer who wants to have it higher will be why 2x? Why not 3x? I am fine with putting a cap on the value. But what should be the cap? Something like min(8*1460/MSS, 8)? -- K. Poon. kacheong.poon@sun.com From owner-psarc Tue Dec 14 16:00:12 2004 X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: 2004/838 TCP Congestion Window Option From: Bill Sommerfeld To: Kacheong Poon Cc: psarc@sac.sfbay.sun.com In-Reply-To: <41BF7C20.2050003@sun.com> References: <16831.18646.459398.47051@gargle.gargle.HOWL> <1103058822.26149.26.camel@thunk> <41BF7128.1080701@sun.com> <1103066427.26684.15.camel@thunk> <41BF7C20.2050003@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1103068782.26684.22.camel@thunk> Mime-Version: 1.0 Date: Tue, 14 Dec 2004 18:59:42 -0500 Content-Length: 279 On Tue, 2004-12-14 at 18:49, Kacheong Poon wrote: > The next question a customer who wants to have it higher > will be why 2x? because the IETF transport area folks seem to have been moving it by roughly a factor of 2 at once (1 packet to 2 packets to 4 packets) - Bill From owner-psarc Tue Dec 14 16:24:36 2004 Message-ID: <41BF8427.8090105@sun.com> Date: Tue, 14 Dec 2004 16:24:07 -0800 From: Kacheong Poon User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041116 X-Accept-Language: en, zh-hk, zh-tw, zh-cn MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com Subject: Re: 2004/838 TCP Congestion Window Option References: <16831.18646.459398.47051@gargle.gargle.HOWL> <1103058822.26149.26.camel@thunk> <41BF7128.1080701@sun.com> <1103066427.26684.15.camel@thunk> <41BF7C20.2050003@sun.com> <1103068782.26684.22.camel@thunk> In-Reply-To: <1103068782.26684.22.camel@thunk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Length: 700 Bill Sommerfeld wrote: > because the IETF transport area folks seem to have been moving it by > roughly a factor of 2 at once (1 packet to 2 packets to 4 packets) The original algorithm used 1. But because of an implementation mistake, the reality was like 2. And IETF accepted the reality. Then they realized that during slow start, TCP almost always sends a burst of 3 segments because of delayed ACK. So they thought that around 4K was fine and came up with a formula which could result in 4. So it was not really like a 2x increment each time (-: It is just the reality... Having said that, I am fine with 8 if PSARC thinks that is OK. -- K. Poon. kacheong.poon@sun.com From sacadmin Wed Dec 22 13:35:23 2004 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id iBMLZNac001083 for ; Wed, 22 Dec 2004 13:35:23 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.1+Sun/8.13.1) with ESMTP id iBMLYl10017278; Wed, 22 Dec 2004 16:34:47 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.1+Sun/8.13.1/Submit) id iBMLYlm0017275; Wed, 22 Dec 2004 16:34:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16841.59511.74940.914131@gargle.gargle.HOWL> Date: Wed, 22 Dec 2004 16:34:47 -0500 From: James Carlson To: psarc@sac.sfbay.sun.com cc: kacheong.poon@sun.com Subject: 2004/838 TCP Congestion Window Option X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO This fast-track request was approved at today's PSARC meeting, with a specified limit on the congestion window that the application can request. (Bill suggests double the default as a limit, small amount of room for judgment if needed, but 10x is not acceptable.) The final specification is in 'spec.txt'. -- James Carlson, IP Systems Group? Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677