Current status of the DFS working group

[Peter Honeyman <[e-mail]>]

Many of the issues we raised in earlier meetings fall in two
categories:  problems with Sun/RPC as transport layer, and
inadequacies with NFS authentication/authorization.  Unless
there is strong sentiment otherwise, I propose that we table
issues relating to authentication and authorization -- they are
important, but independent of our special concerns: NFS as a
consumer of Internet resources.

SUN/RPC ISSUES

1. Adaptive retransmission strategy

Personally, I believe that the static retransmission strategy in
Sun/RPC is the biggest problem posed by WA/NFS.  My impression
is that the vendors are *not* addressing this issue.

BSD has a new approach with their TCP over NFS; this offers as
much potential in addressing NFS' wasteful ways as a bushel of
Sun/RPC hacks.

Where does this leave us?

I'm not comfortable recommending that people "write their
vendor", and it's too soon to tell whether BSD/TCP/NFS offers a
high-performance solution to the WA/NFS problem.  So I don't
know what to recommend here.

2.  Hard mounts vs. soft mounts

Because of the defective retransmission algorithms in Sun/RPC
implementations, soft mounts are usually incapable of providing
high quality service.  Yet, hard mounts guarantee that failed
requests due to dropped frags, for example, are guaranteed to
fail forever.

The conventional wisdom is that hard, interruptible mounts
offers the best compromise.

I'm not prepared to make a recommendation one way or the other
on this.  Any takers?

3. Timeout parameters

Other than suggesting that administrators adjust timeout
parameters to match local conditions, is there anything concrete
we can offer?  I personally believe that we need a system that
works on its own, not a better method of guessing the conditions
between client and server.

4.  Transaction ID caching

This is a vendor issue.  My impression is that all the major
vendors have implemented the Juszczak cache.

5.  Read and write size

Now that the MTU discovery RFC is here, we should expect UDP/NFS
implementations to employ MTU discovery to select transfer sizes
for WA/NFS.  Any idea how to make this a reality?

6.  UDP checksum for WAN

At last, a recommendation that administrators can act on.  But
who knows the magic incantation to turn on UDP checksum?  It
seems a bit much to recommend

	echo 'udpcksum/W1' | adb -w -k /vmunix /dev/mem

Is this actually a vendor issue?


AUTHENTICATION/AUTHORIZATION ISSUES

7.  Reserved socket myth

Is this our issue?  It's only marginally germane to the WA/NFS
problems, and is not specific to NFS.

8.  Mutual distrust among client and server

As in 7, this may not be our issue.

9.  Periodic FSIRAND

Ditto.

10. Setuid handling

Ditto.

11. IP address verification at mount time

Ditto.

12. IP address verification at access time

Ditto.

13. Root and anonymous mapping

Ditto.

14. Generalized user identity mapping

Ditto.

15. Export controls

We are at the mercy of the supporting tools offered by vendors,
e.g., Yellow Pages.  What impact can we hope to make here?  In
any event, this too is not a WA/NFS issue.

16. Kerberized NFS

At last, progress to report:  UMich plans to drop their KNFS,
and adopt Transarc's.  To my knowledge, MIT and Transarc have
not resolved their differences.  And I'm told Sun has a
Kerberized NFS in development.  Yikes!

OTHER ISSUES

17. Cache timeout management

Is this a WA/NFS issue?  Because of the conflict between
statelessness and performance, NFS cache consistency semantics
are weak.  I don't think the DFS-WG can do much about that.

18. SNMP for NFS

This is important.

19. NFSSTAT and NFSWATCH

Where do we go with these?  NFSSTAT is proprietary and operating
system specific.