[OpenAFS] tcpoob timeline

[Troy Benjegerdes]

On Fri, Oct 26, 2012 at 06:40:38PM -0400, Jeffrey Altman wrote:
> On 10/26/2012 5:03 PM, Andrew Deason wrote:
> > On Wed, 17 Oct 2012 10:45:05 +0200
> > To provide a sense of ordering... rxgk standards work will definitely
> > precede tcp oob, though rxgk implementation may or may not. After rxgk,
> > some smaller/simpler standards docs may go through, but tcp oob may be
> > the next 'bigger' one. But the ordering here is unsure; Mike Meffie
> > should be clarifying some specifics of the new standards process within
> > the next week. I expect that around that time is when we'll discuss the
> > priority of which documents to look at; some people may disagree with my
> > guessed priorities.
> > 
> > Note that that is my thinking and my guesses for code being in the tree,
> > not for a stable release. Release scheduling is such a question mark for
> > me right now I can't even begin to guess for that.
> 
> I have significant concerns about the design of TCP OOB as it was
> described at EAKC2012.
> 
> http://conferences.inf.ed.ac.uk/eakc2012/slides/201210_eakc_oob.pdf
> 
> The argument in favor of a TCP based solution is that RX cannot go fast
> enough.  Andrew's claim is that RX cannot use a window size greater than
> 43.75K because of the 32 packet window limitation in 1.6.  The fact is
> that this limitation is not a protocol limitation but an implementation
> limitation.  Andrew points to Simon Wilkinson's past talks on RX as a
> justification for this restriction.

If we are talking about performance and filesystems, I would strongly
suggest some review of the work on InfiniBand transports for PVFS and
Lustre.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=1240573&contentType=Conference+Publications&queryText%3Dpvfs+infiniband

Simon brings up a number of good points why we have conflicting 
design goals between low latency for RPC and bulk data transfer. 

A general RX-stream-oob standard would have several benefits, but 
I'd have to agree with Jeff that performance of TCP (and the servers)
is probably not one of them.

So the key point here is probably instead of arguing about hypothetical
performance strawman as reason not to develop a standard, let's come
to some consensus on what the RPCs and assigned numbers are going to be
for afs-oob-tcp and afs-oob-rdma, and maybe afs-oob-sctp.