[nfsv4] Stream transports that preserve boundaries, RPC, and Record Marking

https://datatracker.ietf.org/idtracker/draft-ietf-nfsv4-rpc-netid/comment/89786/
has a comment regarding,

http://tools.ietf.org/html/draft-ietf-nfsv4-rpc-netid-05.txt

that notes that some connection oriented transports preserve message
boundaries, and thus RPC record marking would technically not be
needed.

Thus I need to be explicit about each of netids specified for each transport
that provided reliable, in-order deliver.

But just because a transport supports boundary preservation doesn't
mean we should necessarily dispose of it.

For example SCTP. SCTP uses pretty much the same idea as RPC record
marking, except that I find SCTP's approach to be much less
error prone. I.e. in SCTP  data chunks
there are two bits: B and E. If B is set, the chunk in the SCTP packet
is the beginning of the record. If E is set it is the end of the record.
RPC record marking only has the equivalent of the E bit, and the result is
that if an RPC sender is not careful. Given the number of data
corruption issues I've found with NFS/TCP clients that mess up the
record marking, if I ever wrote a explicit specification for NFS/SCTP
I would state that the client and server MUST support the ability
to use native SCTP record marking.

The only advantage I can see to specifying a netid for sctp that has
RPC record marking is for the case when the sender wants to send a
really long record, and the in-kernel interfaces (e.g. some socket API)
cannot cope with say a 5 Gigabyte message, due to overflow of
32 bit integers, or SCTP receiver
implementations that try to buffer entire messages (perhaps
because the receiver's receive APIs are not capable of marking boundaries
across multiple calls to the receive interface).

Three questions for the WG:

1. Do existing RPC/SCTP implementations use record marking?
If so, I will specify a variant of a netid for SCTP that uses
record marking in addition to one that does not.

2. Assuming the answer to 1 is no, how do people feel about specifying
a netid for SCTP and another similar transports that has the
"unnecessary" record marking option?

3. NFSv4 specifies port 2049 for TCP and UDP. We will want it to
use 2049 for SCTP (right?). Is there any objection to using 2049 for the
variant of RPC/SCTP that does NOT use RPC record marking?
If we find that we need NFSv4/RPC/SCTP w/ RPC record marking, we would
need a new port from IANA. This is because RPC requests do not include the
netid, and thus there's no way, that I can see, to have
on the same port, streams with record marking and streams without record
marking.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4