[AFS3-std] draft-deason-afs3-oob-00

[Andrew Deason]

Hi,

I've submitted an I-D for the out-of-band protocol I mentioned on the
openafs-devel list a few weeks ago:

https://datatracker.ietf.org/doc/draft-deason-afs3-oob/
http://tools.ietf.org/html/draft-deason-afs3-oob-00

That draft is intended to represent the protocol that was actually used
for the experimental/prototype implementation that is being used at one
site. I am not sure if that is the protocol we want to agree on /
standardize and use, though, due to a couple of shortcomings.

One is that the OOB address negotation information (section 5.1 union
AFSOOB_Challenge) is transmitted for every OOB transfer, which may be
noticeably inefficient. Ideally I think we would advertize/negotiate
this information separately, but this increases the complexity of the
protocol. It will be annoying if we have to maintain yet another piece
of per-server information that needs appropriate caching and
invalidation, etc.

The protocol as described requires a full RTT delay before the OOB
connection can be made because of this (since we need to wait for the
address info). But, this does simplify some error handling and other
parts of the implementation, since if we get an Rx abort, we'll get it
before we need to make the OOB connection. But we could still enforce
this delay while still keeping the addressing information in separate
RPCs, but then I would wonder what the benefit is; we might as well send
the addressing info every time.

The other limitation is that the "versioning" with the unions isn't very
useful for future-proofing, since they're not extended unions. We could
just change this to use extended unions and maybe use the standrd
address types that will someday exist. With the current protocol I was
just trying to keep the size down for the address info, so I could
decode using xdrmem in the kernel with stack-allocated memory. But
that's probably more of a hindrance in the long run.

-- 
Andrew Deason
adeason@sinenomine.net