Subject: heads up - NetApp, NFSv4, and UDP

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Nov 2002 17:30:55 -0800

You get two out of three, i.e., NetApp's first NFSv4 server will not
support UDP, and will support just TCP initially. We dropped UDP support
because:

	1. The v4 specification says it is permitted only if there is a
		congestion control mechanism. We do not have a RPC/UDP
		congestion control mechanism for our replies (and I personally
		don't know what that would mean) and callbacks.

	2. It's one less row in an every growing multi-dimensional
		matrix (sec=, proto=, vers=) of stuff to test.

So, all you client makers ... please make sure your NFS clients, especially
yourr mount commands, do the right thing when NFSv4/UDP is not supported.

Are any other servers going to support NFSv4/UDP? If so, why?
Ditto clients?

	-mre (posting from eisler.com because he wants his Network Appliance
		address to stay spam free)

---

From: Jim Rees <[email-masked]>
Date: Mon, 25 Nov 2002 16:55:36 -0500

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: Jim Rees <[email-masked]>
Date: Mon, 25 Nov 2002 17:53:13 -0500

I would say the section is misleading at best.  If udp is not allowed, it
should not be mentioned in a way that suggests it can be used.

Is there an rfc that lists the "IETF approved" transports?  Should rfc3010
refer to it by number so those of us doing implementations can find it?

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Nov 2002 16:31:42 -0800

No, I'm just saying that if you just assume that what works for v3
will work for v4 unchanged, you may be unpleasantly surprised.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Monday, November 25, 2002 6:17 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: heads up - NetApp, NFSv4, and UDP

>>>>> " " == 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