Coordinating TCP projects

[Robert Watson]

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