From owner-freebsd-net@FreeBSD.ORG Thu Feb 14 02:01:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04CE712A; Thu, 14 Feb 2013 02:01:10 +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 BFD6ADC1; Thu, 14 Feb 2013 02:01:09 +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 4463F7E81E; Thu, 14 Feb 2013 13:01:08 +1100 (EST) Message-ID: <511C4563.7010405@freebsd.org> Date: Thu, 14 Feb 2013 13:01:07 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> In-Reply-To: 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: Andre Oppermann , John Baldwin , net@freebsd.org 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, 14 Feb 2013 02:01:10 -0000 On 02/14/13 05:37, Adrian Chadd wrote: > On 13 February 2013 02:27, Andre Oppermann wrote: > >> Again I'd like to point out that this sort of modification should >> be implemented as a congestion control module. All the hook points >> are already there and can readily be used instead of adding more special >> cases to the generic part of TCP. The CC algorithm can be selected per >> socket. For such a special CC module it'd get a nice fat warning that >> it is not suitable for Internet use. >> >> Additionally I speculate that for the use-case of John he may also be >> willing to forgo congestion avoidance and always operate in (ill-named) >> "slow start" mode. With a special CC module this can easily be tweaked. > > There are some cute things that could be done here - eg, having an L3 > route table entry map to a congestion control (like having an MSS in > the L3 entry too.) This is an area I've thought about and would form the basis for an interesting applied research project. On a related tangent, we (CAIA) also have some ongoing research looking at using different CC algorithms per subflow of a multipath TCP connection. > But I'd love to see some modelling / data showing competing congestion > control algorithms on the same set of congested pipes. Doubly so on > multiple congested pipes (ie, modelling a handful of parallel > user<->last-mile<->IX<->various transit feeds with different levels of > congestion/RTT<->IX<->last mile<->user connections.) You all know much > more about this than I do. :-) There is quite a bit of relevant literature out there. You could start with some of the stuff CAIA has had a hand in (e.g. [1]) and follow the citation trail from there... Cheers, Lawrence [1] http://caia.swin.edu.au/urp/newtcp/papers.html