From owner-freebsd-net@FreeBSD.ORG Fri Jan 11 01:24:25 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30CC16A417; Fri, 11 Jan 2008 01:24:25 +0000 (UTC) (envelope-from lastewart@swin.edu.au) Received: from outbound.icp-qv1-irony-out2.iinet.net.au (outbound.icp-qv1-irony-out2.iinet.net.au [203.59.1.107]) by mx1.freebsd.org (Postfix) with ESMTP id 55CE413C45B; Fri, 11 Jan 2008 01:24:25 +0000 (UTC) (envelope-from lastewart@swin.edu.au) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPhQhkd8qBDq/2dsb2JhbACpfA X-IronPort-AV: E=Sophos;i="4.24,269,1196607600"; d="scan'208";a="264939163" Received: from unknown (HELO newbox.caia.swin.edu.au) ([124.168.16.234]) by outbound.icp-qv1-irony-out2.iinet.net.au with ESMTP; 11 Jan 2008 10:14:10 +0900 Message-ID: <4786C2DA.3030407@swin.edu.au> Date: Fri, 11 Jan 2008 12:14:02 +1100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.4 (X11/20070625) MIME-Version: 1.0 To: Randall Stewart References: <20071219123305.Y95322@fledge.watson.org> <4786338D.5050801@cisco.com> In-Reply-To: <4786338D.5050801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: James Healy , arch@freebsd.org, Robert Watson , net@freebsd.org Subject: Transport layer congestion control ideas (was Re: Coordinating TCP projects) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2008 01:24:26 -0000 Hi Randall, Comments inline... Randall Stewart wrote: > Robert: > > One thing I would like to point out for one of Lawrence's project > is that SCTP is also hanging around in the kernel and as > part of one of our URP's (which is also where Lawrence's project > came from.. if I remember right)... we added "selectable" > congestion control to SCTP.. well it was not really a URP > come to think of it.. but what I kept an intern busy doing > last summer :-) > > Now, the SCTP code DID NOT do kernel loadable CC modules > like Lawrences... which is cool.. so .. I wonder.. > > Would it be possible to take what Lawrence did and generalize > it so that *ANY* transport could use it.. i.e. both TCP and SCTP. > This would yeild an interesting advantage in that any time one > added a CC algorithm all transports would have access to them. Interesting idea... some thought would be required to figure out how to abstract the differences between transports into a generic set of information passed to a CC algorithm to do its job. Nothing specific comes to me immediately as I'm not familiar enough with the SCTP implementation to identify commonalities relevant to CC off the top of my head, but I suspect it wouldn't be *that* much work. Would require some changes to our current KPI. Not sure what changes to SCTP would be involved. Certainly interested to hear/discuss ideas on this to flesh out whether it's something worth pursuing. > > Not having looked at the patches yet, what may be missing in > the TCP code is to select amongst multiple CC algorithms... we > actually have this down to the SCTP association level.. So I > can in theory have different associations out of the same > box using different CC modules... Our TCP patch currently supports the use of a different CC algo per connection (read: per tcb), and allows selection of a system wide default CC algo via sysctl (which can be used crudely to change algos used by connections at initialisation). Jim and I just finished adding the {set|get}sockopt plumbing 2 days ago that allows overriding the system default CC algo on a TCP socket (both at initialisation and dynamically during use). It'll be in Perforce shortly after a bit more testing. As a first step towards streamlining TCP/SCTP CC interactions, I imagine it would be straight forward enough to generalise the sockopt plumbing a bit more to specifcy a "TRANSPORT_CONGESTION" sockopt instead of the currently used "TCP_CONGESTION" and have your SCTP code also respond to set/gets of this option on SCTP sockets. Given you already have the modular CC capabilities, it should be a minor addition. Happy to send you our patch if you want a squiz at it. > > There might be some good ideas we can harvest from both approaches > and make available to all transports... Too many cool ideas! :) Let the good times (and ideas) roll on. [snip Robert's initial email] Cheers, Lawrence