[OpenAFS-devel] Rx over TCP to solve some NAT & Firewall issues?

[chas williams]

In message <33580000.1069345906@warf.ftlsystems.com>,Joshua Johnson writes:
>I don't currently see an RX mailing list or an RX project for OpenAFS, 
>should there be one?

probably not.  openafs-devel doesnt seem to have too much traffic.

>I have wondered about TCP for RX and what the implications of it could mean.

while tcp for rx might be useful i believe you would wind up 
making the same changes needed to 'fix' udp.

>Where does IPV6 fit into this?

ipv6 should eliminate nats.  i believe the rx header already reserved
enough space for ipv6 addresses.

>How involved is the current RX in the raw IO performance gap (AFS vs. NFS, 
>FTP et. all) people bring up?

i believe rx is the problem but more precisely how rx is used the
problem.  we (nrl) had some work done to put atm into afs.  rx datagrams
were sent directly over an atm vc.  atm pdu's are more like udp than
tcp but that's probably not were the gains were seen.  the 'segment'
size for rx was increased.  this created a 'new' type of jumbogram
that wasnt a bunch of little rx datagrams packaged together (like 'regular'
jumbograms).  regular jumbograms are typically handled via scatter/gather
which (IMHO) isnt well implemented on many operating systems.

i believe (and i wish i had some time to work on this -- really) that
if you just junked the current jumbogram scheme and make rx datagrams
bigger (and reducing them for congestion control) you could see some
pretty substantial performance increases.  apparently jumbograms are
the way they are because people wanted a form of congestion control on
afs (controlling number of rx datagrams in a packet).

>Anyway, sorry for my ramblings. Where is the appropriate place to toss 
>around thoughts/ideas involving RX ?

openafs-devel.