Date: Fri, 11 Jan 2008 12:14:02 +1100 From: Lawrence Stewart <lastewart@swin.edu.au> To: Randall Stewart <rrs@cisco.com> Cc: James Healy <jhealy@swin.edu.au>, arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, net@freebsd.org Subject: Transport layer congestion control ideas (was Re: Coordinating TCP projects) Message-ID: <4786C2DA.3030407@swin.edu.au> In-Reply-To: <4786338D.5050801@cisco.com> References: <20071219123305.Y95322@fledge.watson.org> <4786338D.5050801@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4786C2DA.3030407>