From owner-freebsd-net@FreeBSD.ORG Fri Aug 31 16:37:50 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A0F16A41A for ; Fri, 31 Aug 2007 16:37:50 +0000 (UTC) (envelope-from mallman@icir.org) Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by mx1.freebsd.org (Postfix) with ESMTP id CAA9E13C480 for ; Fri, 31 Aug 2007 16:37:49 +0000 (UTC) (envelope-from mallman@icir.org) Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id l7VFcmB9022294; Fri, 31 Aug 2007 08:38:48 -0700 Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 85C92ED7F47; Fri, 31 Aug 2007 11:38:42 -0400 (EDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C7D3E294405; Fri, 31 Aug 2007 11:38:15 -0400 (EDT) To: Randall Stewart From: Mark Allman In-Reply-To: <469CA4F3.4080302@cisco.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Zombie MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_bOundary"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 31 Aug 2007 11:38:15 -0400 Sender: mallman@icir.org Message-Id: <20070831153815.C7D3E294405@lawyers.icir.org> Cc: James Healy , freebsd-net@freebsd.org, Andrew Subject: Re: Odd congestion window behaviour [ was: Draft email to freebsd-net ] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mallman@icir.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2007 16:37:50 -0000 --=_bOundary Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sorry, I am way behind. > IMO if you want to follow the true spirit of RFC3390 and RFC2581 then > yes.. you should ONLY use RFC3390 (or 2581) to set your initial > cwnd. > > I am adding Mark Allman on this to get his opinion.. Mark, here > is your big chance to chime in on something that has had your > name in comments in FreeBSD code for years... > > Basically let me referesh your memory in case you are not on > net@freebsd.org (or you can go look at the thread). > > Currently FreeBSD will dig into its hostcache and set the > cwnd of a new connection to the previous value with some constraints.. > > James posted these a fe days ago when noting funny behavior. > > I chimed in and said really IMO using the previous cwnd > of old connections is NOT a good idea.. (I can see using > the previous ssthresh.. but not cwnd).. and it is exactly > why our SCTP implementation DOES NOT do this.. > > What do you think Mark (since your name is in the comments > to justify this action).. I am not sure I follow this. The place where I know my name is (was) in the code is about spurious RTOs, not caching CC state between connections. In general, I think caching CC state between connections can be useful. But, one needs to be careful on how you do it and there is (as far as I know), no well vetted and specified way to cache CC state. I.e., if some connection uses a cwnd of X bytes and then ends and another connection comes along.... (a) Can that connection just use a cwnd of X bytes? (b) Does it matter how long after the first connection ends that the second connection is initiated? (c) If it matters, how long should we view the cwnd of X as being valid? (d) Should the value of X decay? (e) Should a TCP doing this be required to pace to mitigate the burstiness of simply starting with a big cwnd? Etc. So, it seems to me that there are really lots of questions that need to be carefully thought about and answered before one used such a scheme. That said, I do support the general concept and wish someone would write down some specifics that the community could agree to. allman --=_bOundary Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFG2DXnWyrrWs4yIs4RAiGvAJ9KLopaXbhkRHQkXB4aNEMkeqSZjACfR63M pvwgCtQ1sno23Hx+Hf7Tnig= =RQ+6 -----END PGP SIGNATURE----- --=_bOundary--