Date: Thu, 10 Jan 2008 10:02:37 -0500 From: Randall Stewart <rrs@cisco.com> To: Robert Watson <rwatson@freebsd.org> Cc: James Healy <jhealy@swin.edu.au>, arch@freebsd.org, Lawrence Stewart <lastewart@swin.edu.au>, net@freebsd.org Subject: Re: Coordinating TCP projects Message-ID: <4786338D.5050801@cisco.com> In-Reply-To: <20071219123305.Y95322@fledge.watson.org> References: <20071219123305.Y95322@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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... There might be some good ideas we can harvest from both approaches and make available to all transports... Just some thoughts mind you :-) R Robert Watson wrote: > > Dear all, > > It is rapidly becoming clear that quite a few of us have Big Plans for > the TCP implementation over the next 12-18 months. It's important that > we get the plans out on the table now so that everyone working on these > projects is aware of the larger context. This will encourage > collaboration, but also allow us to manage the risks inevitably > associated with having several simultaneous projects going on in a very > complex software base. With that in mind, here are the large projects > I'm currently aware of: > > Project Flag Wavers Status > ------- ----------- ------ > TCP offload Kip Macy Moving to CVS and under > review and testing; one > supporting device driver. > > TCP congestion control Sam Leffler, At least one prototype > Rui Paulo, implementation, to move to p4 > Andre Oppermann, > Kip Macy, > Lawrence Stewart, > James Healy > > TCP overhaul Andre Oppermann Glimmer in eye, to move to > p4. > > TCP lock granularity/ Robert Watson Glimmer in eye, to occur in > increased parallelism p4. > > TCP timer unification Andre Oppermann, Previously committed, and to > Mike Silbersack be reintroduced via p4. > > Monitoring ABI cleanup Robert Watson Glimmer in eye, to occur in > p4. > > Looking at the above, it sounds like a massive amount of work taking > place, so we will need to coordinate carefully. I'd like to encourage > people to avoid creating unnecessary dependencies between changes, and > to be especially careful in coordinating potentially MFCable changes. > There are (at least) two conflicting scheduling desires in play here: > > - A desire to merge MFCable changes early, so that they aren't entangled > with > un-mergeable changes. This will simplify merging and also maximize the > extent to which testing in HEAD will apply to them once merged to > RELENG_7. > > - A desire to merge large-scale infrastructural changes early so that > they see > the greatest exposure, and so that they can be introduced > incrementally over > a longer period of time to shake each out. > > Both of these are valid perspectives, and will need to be balanced. I > have a few questions, then, for people involved in these or other projects: > > (0) Is your project in the above list? If not, could you send out a reply > talking a bit about the project, who's involved, where it's taking > place, > etc. > > (1) What is your availability to shepherd the project through its entire > cycle, including early prototyping, design review, development, > implementation review, testing, and the inevitable long debugging tail > that all TCP projects have. > > (2) When do you think your implementation will reach a prototype phase > appropriate for an expanded circle of reviewers? When do you think it > might be ready for commit? Keep in mind that we're now a month or > so into > the 18-month cycle for 8.0, and that all serious TCP work should be > completed at least six months before the end of the cycle. > > (3) What potential interactions of note exist between your project and the > others being planned. Are there explicit dependencies? > > (4) Do you anticipate an MFC cycle for your work to RELENG_7? > > I'd like for us to create a wiki page tracking these various projects, > and pointing at per-project resources. Once the discussion has settled > a bit, I can take responsibility for creating such a page, but will need > everyone involved to help maintain it, as well as to maintain pages (on > the wiki or elsewhere) regarding the status of the projects. I think it > also makes a lot of sense for participants in the projects to send > occasional updates and reports to net@/arch@ in order to keep people who > can't track things day-to-date in the loop, and to invite review. > > At the end of the day, we must be clear: the only way even a fraction of > these projects can happen in time for 8.0 is if there is careful > planning, coordination, and exception care taken in the review and > testing of the changes. We cannot have the 8.0 release cycle put at > risk the way the 7.0 cycle was due to inadequately reviwed and tested > patches entering the tree under the assumption that problems would > somehow be magically found and fixed before the release by the > relatively small population of -CURRENT users. Experience tells us that > changes must be extensively reviewed and tested before they enter the tree. > > I'm really looking forward to the 8 development cycle, and the work > that's in the pipeline is really very exciting. It will take quite a > bit of dedication to make it all happen, but if even only a small part > of it happens, it will still be very good news. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4786338D.5050801>