[OpenAFS] Re: tcpoob timeline

[Andrew Deason]

On Sat, 27 Oct 2012 16:31:59 +0100
Simon Wilkinson <simonxwilkinson@gmail.com> wrote:

> I do believe that we can make the current RX implementation
> significantly faster - and that this will aid both bulk and metadata
> operations. However, it is unlikely that we can ever reach the raw
> performance of TCP, especially when TCP is aided by in-kernel DMA
> splitting packet decoding across multiple cores, and by specialised
> firmware in the network cards themselves.

Yes, I meant to respond to this part of the 'RX Performance' talk in
Edinburgh, but I forgot about it by the time to ask questions came
around.

I'm sure something UDP-based can be faster than TCP given certain
conditions. But since so many pieces of networking software and hardware
give TCP special treatment and optimizations, practically speaking, I
find it unlikely to meet or exceed TCP bandwidth for many real-world
scenarios with existing equipment. That is, until Rx becomes popular
enough that devices start to have e.g. hardware acceleration for Rx.
That doesn't sound very likely.

It's possible for a UDP-based protocol to behave very well, and in some
situations exceed TCP. I don't think Rx should be such a protocol, since
I think we should be focusing on making filesystems instead of
researching flow control. Er, not that current speed improvements are
unwelcome; it should be faster, but spending the time making it TCP-fast
just seems like wasting time reinventing TCP.

(Random tidbit: the original request for this project was to use a
userspace UDP-based bulk transfer protocol. The only reason I didn't go
for that was because it lacked a kernel interface.)

-- 
Andrew Deason
adeason@sinenomine.net