Subject: RE: Transport requirements for NFSv4 (take 2)

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 5 Nov 1999 10:09:30 -0800

> Comments?
> 
> 2.1.  Ports and Transports
> 
>    Historically, NFS version 2 and version 3 servers have resided on
>    UDP/TCP port 2049.  For NFS version 4, the transport in use by the
>    RPC layer must provide reasonable congestion control.  When TCP or
>    UDP is used, the default TCP port should be 2049 [RFC1700].  Using
>    the registered port for NFS services means the NFS client will not
>    need to use the RPC binding protocols as described in 
> [RFC1833]; this
>    will allow NFS to transit firewalls.

I don't think this is the intention, but the way this reads,
"the transport in use by the RPC layer must provide reasonable 
congestion control", it sounds like you can't use UDP, unless
you are willing to stretch "reasonable" quite a bit.

> 
>    To provide for interoperability and congestion control, the RPC
>    service for NFS version 4 MUST use either TCP/IPv4 or TCP/IPv6.  If
>    your network stack implements TCP/IPv4, NFSv4 SHOULD use TCP/IPv4.
>    If your network stack implements TCP/IPv6, NFSv4 SHOULD 
> use TCP/IPv6.
>    The NFS client and server may use other transports that provide
>    congestion control and in those cases a mechanism may be 
> provided to
>    override TCP usage in favor of another transport.

The phrase "MUST use either TCP/IPv4 or TCP/IPv6" sounds like 
you can't use anything else.  How about "MUST implement" or
"MUST provide support for use of"?

And again it sounds like UDP is not included here.

---

From: Peter Staubach <[email-masked]>
Date: Fri, 5 Nov 1999 10:20:16 -0800 (PST)

>    need to use the RPC binding protocols as described in [RFC1833]; this
>    If your network stack implements TCP/IPv6, NFSv4 SHOULD use TCP/IPv6.
>    congestion control and in those cases a mechanism may be provided to

Given that NFS is a client/server protocol, this seems like it only
addresses the client side without taking the server into account.
Perhaps the "SHOULD use" could be rephrased as "SHOULD be supported
over"?  The current wording seems to indicate that if your client
operating system support IPv6, then NFSv4 should use it, no matter
whether the server supports IPv6 or not.

Also, on a slightly different topic, but contained in this paragraph --
I don't think that "NFS" should be used as a noun.  In the past, it has
always been "the NFS protocol" or "NFS mounted file systems" or so on
and so forth.  Has this changed or should a review of the protocol
specification document be done to update such references?

	Thanx...

		ps

---

From: Vern Paxson <[email-masked]>
Date: Fri, 05 Nov 1999 13:35:04 PST

> It was a dark and stormy night when ... knocked, knocked, knocked on
> the portal.  The engineers looked up from their blue screens and
> realized their state of the art gateways would offer no protection
> from the Area Advisor who was about to pick up the gauntlet and lay
> down the Law.

knock knock knock :-)

The strong requirement is that NFSv4's transport must include congestion
control comparable to that defined for TCP in RFC 2581.  (I think that's
better phrasing than "reasonable congestion control", because "reasonable"
might mean different things to different people).

This can be done with UDP, though it's a fair amount of work.  It will be
easier to do with UDP when the new ECM working group delivers its "congestion
manager", but that won't happen for a number of months.

Doing it by mandating TCP is certainly simplest in terms of assuring
interoperability and stable transport implementations to build on.

If done with TCP, it should use a persistent connection between the client
and the server.  Otherwise, a fair amount of TCP's congestion control is
weakened.

As for the IPv4 / IPv6 issues, that strikes me as outside the scope of what
NFSv4 should dictate.  The congestion control requirement comes up because
it's crucial for sound network operation (as, ultimately, is the security
requirement).  I don't see a similar argument for IPv4/IPv6.

		Vern