From owner-freebsd-current@FreeBSD.ORG Fri Dec 3 00:40:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D8B106564A for ; Fri, 3 Dec 2010 00:40:51 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4902B8FC18 for ; Fri, 3 Dec 2010 00:40:48 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 8B0007E84A; Fri, 3 Dec 2010 11:40:45 +1100 (EST) Message-ID: <4CF83C8C.7010508@freebsd.org> Date: Fri, 03 Dec 2010 11:40:44 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.12) Gecko/20101117 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ivan Voras References: <4CDD0A71.7020708@freebsd.org> <4CF788D7.8020905@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: [HEADS UP] Significant TCP work committed to head - CUBIC & H-TCP committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 00:40:52 -0000 Hi Ivan, On 12/03/10 00:07, Ivan Voras wrote: > On 12/02/10 12:53, Lawrence Stewart wrote: > >> For the really interested (by now I suspect my audience is down to 0, >> but still), you might want to load siftr and enable/disable it during >> each test run and make your very own plot of cwnd vs time to see what's >> really going on behind the scenes. >> >> Ok that's enough for now, but much more is on the way. Please let me >> know if you have any feedback or run into any problems related to this >> work. > > Hi, > > My question isn't very constructive but I'd like to know more about this > topic. Have you seen this: > > http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html > http://developers.slashdot.org/story/10/11/26/1729218/Google-Microsoft-Cheat-On-Slow-Start-mdash-Should-You Yes I'd seen the first one and just skimmed the slashdot thread now. > ? In short: is the existance of slow-start a property of (New)Reno and No, mostly unrelated. Slow start is one of 4 separate but related algorithms which control a TCP flow's behaviour during startup and general operation. See RFC5681 for useful discussion of the algorithms. NewReno unfortunately is an overloaded term. In congestion control circles, NewReno is used to refer to the congestion avoidance behaviour of "increase cwnd by 1 max seg size per RTT and backoff cwnd by half when congestion (3 dup ACKs) is detected" (which is the same basic behaviour as Reno BTW). NewReno also refers to a set of tweaks (RFC3782) to TCP's fast recovery algorithm (helps recover from multiple losses in a window when SACK isn't available). > will some of the new algorithms make it less "cautious", i.e. faster? I > don't think it's critical but I'm often noticing it, especially on bulk > transfers over LAN. With respect to slow start, no. Congestion control algorithms tend to focus on the increase/decrease of cwnd during congestion avoidance mode, which is transitioned to after slow start completes. Slow start is left untouched. There are proposals to modify/replace slow start e.g. RFC4782 and 'JumpStart' [1]. The reason Google and Microsoft are fiddling with things are because they typically only need to push a small amount of data, so waiting for slow start to complete eats up unnecessary RTTs. Google are pushing in the IETF at the moment to have the initial window bumped to 10 segments (see the tcpm, iccrg and tmrg IRTF/IETF mailing lists if interested). There is some push back happening though and the discussions are interesting. Cheers, Lawrence [1] http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf