Subject: RE: heads up - NetApp, NFSv4, and UDP

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Nov 2002 14:15:10 -0800

Sometimes what comes for free has hidden costs.

In particular, if you use the same rpc that comes with v3,
you are going to be re-issuing requests on TCP connections,
under cirsumstances in which the v4 spec (section 3.1.1) says
you MUST NOT do so:

   When processing a request received over a reliable transport such as
   TCP, the NFS version 4 server MUST NOT silently drop the request,
   except if the transport connection has been broken. Given such a
   contract between NFS version 4 clients and servers, clients MUST NOT
   retry a request unless one or both of the following are true:

   o    The transport connection has been broken

   o    The procedure being retried is the NULL procedure 

As well as the free UDP, which seems to cause you to violate
section 3.1 of the spec:

   Where an NFS version 4 implementation supports operation over the IP
   network protocol, the supported transports between NFS and IP MUST be
   among the IETF-approved congestion control transport protocols, which
   include TCP and SCTP.

It says "the supported transports" (which I read as meaning all of them),
must be among a set in which UDP is clearly not included.  This is the result
of the final edits requested by the IESG.  So the spec says don't support
UDP, free or not.

-----Original Message-----
From: Jim Rees [mailto:[email-masked]]
Sent: Monday, November 25, 2002 4:56 PM
To: [email-masked]
Subject: Re: heads up - NetApp, NFSv4, and UDP 

Our BSD client and server will do both.  We're using the rpc that came with
the NFSv3 client and server (plus rpcsec_gss), so we get udp for free.

---

From: Trond Myklebust <[email-masked]>
Date: 26 Nov 2002 00:17:26 +0100

>>>>> " " == Dave Noveck <Noveck> writes:

     > Sometimes what comes for free has hidden costs.  In particular,
     > if you use the same rpc that comes with v3, you are going to be
     > re-issuing requests on TCP connections, under cirsumstances in
     > which the v4 spec (section 3.1.1) says you MUST NOT do so:

I hope you are not saying that it is impossible to be sharing the same
RPC engine between v2/v3 and v4?

Section 3.1.1 explicitly states that the client is allowed to break
the transport connection and then resend the request (even after it
has determined that the server is still alive). IIRC that was added
specifically in order to allow RPC engine reuse with v2 and v3.

Cheers,
  Trond

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 15:34:39 -0800

No, he's responding to the claim that it comes for free because
same rpc is used for { udp, tcp } X { v2, v3 }. Dave's point is it
isn't free because NFSv4 over TCP establishes a new convenant  that
did not exist with NFSv[23] over TCP.

NFSv[23] servers can and do cheerfully drop requests without breaking the
the TCP connection. 

	-mre

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 25 Nov 2002 19:42:04 -0500

On Monday, Nov 25, 2002, at 18:17 America/Montreal, Trond Myklebust 
> RPC engine between v2/v3 and v4?

I think the spec does make it impossible, at least unless one has large
chunks of similar code that are branched apart with something like:

	if (NFS-Version < 4) {
		...lots of stuff here...
	} else {
		...lots of not exactly identical, but very similar stuff here...
	}

> specifically in order to allow RPC engine reuse with v2 and v3.

That would be an unkind thing to deploy, since it likely will impair
user performance and drive NFS server admins nuts.  Please folks avoid
doing that sort of thing in real code.

Ran

---

From: Adam Ruprecht <[email-masked]>
Date: Mon, 25 Nov 2002 20:24:47 -0500 (EST)

On Mon, 25 Nov 2002, Noveck, Dave wrote:

>    except if the transport connection has been broken.

RFC2203 lays out a couple of cases having to do with sequence
numbers where incoming requests must be silently discarded.  Must the
server break the connection if this happens?

	Thanks,
	Adam

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 18:19:11 -0800

> server break the connection if this happens?

No. Section 3.1.1 only applies to requests that have managed to reach the NFSv4 level of
the protocol stack. For example, if the IP checksum failed on the UIP datagram
header (and if so, the pakcet is dropped), one would not expect NFSv4 to break the 
connection because the request would not have reached the code that processes NFSv4 bits. 
Likewise, when RPCSEC_GSS determines whether to drop something
dispatch routine (i.e. that have passed all physical medium, IP, TCP, XDR and RPC processing)

	-mre (who now expects someone to say that the NFSv4 RFC should make this clear
		:-| )

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 26 Nov 2002 03:57:17 +0100

>>>>> " " == RJ Atkinson <[email-masked]> writes:

     > I think the spec does make it impossible, at least unless one
     > has large chunks of similar code that are branched apart with
     > something like:

     > 		...lots of not exactly identical, but very similar

The NFSv4 RPC model is based on RFC1831 and 1832. Why should it not be
able to share an RPC engine with other protocols that are based on the
same RFCs?

The NFSv4 XDR differs from that of v2/v3, but that's a completely
different matter...

    >> Section 3.1.1 explicitly states that the client is allowed to
    >> break the transport connection and then resend the request
    >> (even after it has determined that the server is still
    >> alive). IIRC that was added specifically in order to allow RPC
    >> engine reuse with v2 and v3.

     > That would be an unkind thing to deploy, since it likely will
     > impair user performance and drive NFS server admins nuts.
     > Please folks avoid doing that sort of thing in real code.

Unlike previous versions of NFS, several operations under v4 are
subject to hard timeouts (anything that depends on a lease getting
renewed on time for instance).
Why shouldn't NFS client administators have the option of setting a
reasonable timeout period in order to try to recover before those
leases expire?

Cheers,
  Trond