Subject: Regarding TCP implementation of nfs

From: kvs sivak <[email-masked]>
Date: Thu, 17 Feb 2000 10:33:16 +0000 (GMT)

Sir,
   We are students of final semester M.C.A.(Master of
Computer Applications) course at Anna iversity,
Chennai -INDIA.
As a part of our final semester project work we are
implementing NFS version 4 over Linux.
We have gone through the document :
draft-ietf-nfsv4-03-00.txt.
As regards the need for TCP implementation (as given
in section 3.1 of the above document) we will be happy
to know the exact reason for choosing TCP
implementation .We feel that UDP is more cost
effective and also if most of the files are Delegated
then bandwidth of the network will be wasted in
persistent connections for the delegatd entries.As
regards the need for a Callback path, in a UDP
implementation this could be easily determined at the
time of delegation request using a small ping routine.

Kindly reply at the earliest.

K.Sivakumar 
K.V.Subramanian

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

---

From: Gordon Waidhofer <[email-masked]>
Date: Thu, 17 Feb 2000 03:21:42 -0800

My goodness this fellow is polite ;-)

The thought that jumped to my mind is that there
has been lots and lots of discussion about TCP v. UDP,
yet the conclusions and motives for TCP are perhaps
not reflected in the NFSv4 spec. I'm not qualified,
but perhaps somebody who is could draft such a
section. If it can't be included in the spec,
then certainly among some companion material.

To [email-masked]..... I believe there
are already folks working on NFSv4 for Linux.
It is quite an ambitious undertaking, especially
as a final semester project. Perhaps the keepers
of NFSv4 on Linux have a specific portion y'all
could help with. Or, I may have something
interesting for you that is unrelated to NFS,
and less ambitious. Contact me [email-masked]
if you'd like to know more.

Regards,
	-gww

-- 
==================================================================
  Gordon W Waidhofer                    Traakan Software, Inc.
  [email-masked]                       111 Main St., Suite #5
  650-947-1583  Direct                  Los Altos, CA  94042
  650-947-1580  Main                    http://www.traakan.com
  650-947-1588  Fax

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 17 Feb 2000 08:02:44 +0000

>then certainly among some companion material.

It sounds like useful material for publication as
an Informational RFC, since it is not part of
the spec per se and that approach would not delay
the spec further on its way to standards-track RFC.

Ran
[email-masked]

---

From: Mike Eisler <[email-masked]>
Date: Thu, 17 Feb 2000 07:24:51 -0800 (PST)

> implementation 

Section 3.1 of draft-ietf-nfsv4-06.txt
states:

   The transport used by the RPC service for the NFS version 4 protocol
   MUST provide congestion control comparable to that defined for TCP in
   [RFC2581].  If the operating environment implements TCP, the NFS
   version 4 protocol SHOULD be supported over TCP.  The NFS client and
   server may use other transports if they support congestion control as
   defined above and in those cases a mechanism may be provided to
   override TCP usage in favor of another transport.

So there's no requirement that TCP be used, but it is strongly encouraged.
The objective is to minimize congestion. Do it with UDP if you can. I suspect
you'll yourself re-implementing TCP features at a level above UDP, but 
perhaps you'll make a breakthough that we can all benefit from.

	-mre

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 17 Feb 2000 09:46:38 -0600

> the spec further on its way to standards-track RFC.

What a great segue. :-)  There has been discussion
on this alias (if I remember correctly) and certainly
at the working group meetings about the need for this type of
information RFC for NFSv4.  The focus that has
been suggested is on implementation choices/suggestions/experiences
and further discussion of scenarios that would help justify
the choices made for the protocol.

I am willing to act as editor for such an RFC and now
that we have finished our last call for the protocol it
seems like a good time to solicit suggestions for content.

This is a topic that we can to the agenda for Adelaide.

Spencer