From owner-freebsd-net@FreeBSD.ORG Thu Jan 24 23:27:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 931D9117; Thu, 24 Jan 2013 23:27:53 +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 4D7EFDFC; Thu, 24 Jan 2013 23:27:53 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 832DA7E820; Fri, 25 Jan 2013 10:27:51 +1100 (EST) Message-ID: <5101C377.7010907@freebsd.org> Date: Fri, 25 Jan 2013 10:27:51 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: Some questions about the new TCP congestion control code References: <201301141604.29864.jhb@freebsd.org> <50F5137F.1060207@freebsd.org> <201301151427.50932.jhb@freebsd.org> <51013702.8040707@freebsd.org> <51014150.50101@networx.ch> In-Reply-To: <51014150.50101@networx.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: freebsd-net@freebsd.org, John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 23:27:53 -0000 On 01/25/13 01:12, Andre Oppermann wrote: > On 24.01.2013 14:28, Lawrence Stewart wrote: >> On 01/16/13 06:27, John Baldwin wrote: >>> One other thing I noticed which is may or may not be odd during this, >>> is that >>> if you have a connection with TCP_NODELAY enabled and you fill your >>> cwnd and >>> then you get an ACK back for an earlier small segment (less than >>> MSS), TCP >>> will not send out a "short" segment for the amount of window space >>> released. >>> Instead, it will wait until a full MSS of space is available before >>> sending >>> a packet. I'm not sure if that is the correct behavior with >>> TCP_NODELAY or >>> if we should send "short" segments in that case. >> >> We try fairly hard not to send runt segments irrespective of NODELAY, >> but I would be happy to see that change. I'm not aware of any "correct >> behaviour" we have to adhere to - I think it would be perfectly >> reasonable to have a sysctl set the lowest number of bytes we'd be >> willing to send a runt segment for and then key off TCP_NODELAY as to >> whether we try hard to send an MSS worth or send as soon as we have the >> min number of bytes worth of window available. > > This is classic silly window syndrome prevention applied to the CWND. Yes, but I think we could provide knobs to relax the behaviour where the latency vs header/payload overhead tradeoff swings in favour of latency. I guess, John, I should first ask if you know why you were only getting such small ACKs back? Were you sending full MSS segments in the first place or doing some sort of PUSH to try and expedite getting some smaller chunk of data to the other end which triggered a small segment and corresponding small ACK? > Sending a small segment when the window opens just a bit isn't going to help > much and I wouldn't be game to make such a blanket statement - that very much depends on the situation. I think John's use case is relevant and we currently aren't very helpful towards it. > mostly clogs the network. How so? We're not in the 80's any more. If I pay for X MBps of service, I expect to be able to use it in any way I choose. Packet size is irrelevant, but there are obvious efficiencies to be gained by maximising the amount of payload in each segment. > This is actually a side effect of ABC (appropriate byte counting) where not > the ACK's are counted but the bytes ACK'ed. Disabling ABC will solve this > problem. I don't follow. How is what John described above related to ABC? Cheers, Lawrence