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

["Mike Eisler" <[e-mail]>]

> 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.

I did not receive an answer. So I will not specify a netid for SCTP that
uses RPC record marking. If someone is using RPC over SCTP with RPC
record marking, they will have to register it with IANA.

>
> 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?

N/A.

>
> 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?

No objection. Per Lars' advice, I will add an IANA note to register
NFS/SCTP over port 2049.

> 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.


On Fri, December 19, 2008 2:27 pm, Mike Eisler wrote:
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>


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



_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4