Subject: Why does CB_* require a return path?

From: Alfred Perlstein <[email-masked]>
Date: Thu, 30 May 2002 09:56:46 -0700

I've been studying the spec for a while and something has been bothering
me about delegations and the associated callbacks.

Specifically:

   Because callback RPCs may not work in all environments (due to
   firewalls, for example), correct protocol operation does not depend
   on them.  Preliminary testing of callback functionality by means of a
   CB_NULL procedure determines whether callbacks can be supported.  The
   CB_NULL procedure checks the continuity of the callback path.  A
   server makes a preliminary assessment of callback availability to a
   given client and avoids delegating responsibilities until it has
   determined that callbacks are supported.  Because the granting of a
   delegation is always conditional upon the absence of conflicting
   access, clients must not assume that a delegation will be granted and
   they must always be prepared for OPENs to be processed without any
   delegations being granted.

Ok, since afaik NFSv4 works over a stream (read: TCP) channel, why
not send the callbacks back over this same channel insread of
forcing complications on the client side for handling incoming
requests, fixing firewall rules and the overhead associated with
maintaining an additional connection.

There has to be some way to utilize the channel in a bidirectional
manner to squelch this potentially painful implementation detail.

I mean don't we want strong cache coherency as often as possible?

I know this causes some nits for SunRPC, however if the protocol
was modified slightly this could be done, basically why attaching
a direction bit to each message that goes over the wire.

-- 
-Alfred Perlstein [[email-masked]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 30 May 2002 12:33:18 -0500

> maintaining an additional connection.

See http://www.nfsv4.org/rfc3010updates/issues.html
Issue 145 captures (briefly) the issue you point out here.

> I mean don't we want strong cache coherency as often as possible?

As a point of correctness, delegation does not provide strong cache
coherency but rather provides the client a guarantee that no other
client will be accessing the file concurrently.  The server is
required to recall the delegation when there is a conflict with
another client.  The server is also able to recall the delegation at
will for whatever reason it thinks is reasonable.  Therefore, the
client must not depend on delegations and can only rely on the
traditional NFS cache consistency mechanisms.

> a direction bit to each message that goes over the wire.

The RPC definition already has a CALL/REPLY mechanism.  Therefore it
is possible that a client could receive CALLs on the connection it
uses for server communication.

However, there are additional issues that have not been discussed with
respect to this issue that will need to be resolved.  Some of the easy
ones are: will the RPCSEC_GSS in the reverse call direction need to
negotiate in the same way that the regular CALL mechanism does.  I
believe it will and the client will need to be prepared for this.  If
TCP is used, the connection may have been closed by either the client
or server thus making unavailable the callback path for the server.
It has been suggested that the server just postpone callbacks until
the client reestablishes a connection with the server since it must do
so to RENEW the state.  However, there may be issues of the server
identifying correctly which connections are associated with the
original delegation.  This also will get in the way of CB_GETATTR
calls where the server would like to respond in a reasonable time
frame to the original GETATTR that caused the callback to occur.  

Then there is the issue of non TCP transports.  If a client were to
implement a the required congestion control over UDP then what is the
callback path for the server.  Traditional NFS clients that use UDP
use a variety of UDP ports and the server must choose one for the
callback.  Obviously, we could limit the use of the suggested callback
modificatin to TCP or the like to resolve this but it is still a
choice.

For these reasons, I believe that this issue will be closed as no
action for the current update of RFC3010 but should be discussed for
future minor versions of NFSv4.  As we gain experience with the
delegation implementations and the callbacks, it may become imperative
that we implement/define this mechanism clearly.

-- 
Spencer

---

From: Brent Callaghan <[email-masked]>
Date: Thu, 30 May 2002 10:49:28 -0700

This was discussed in August last year - the thread beginning here:
 
   http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2001/0488.html
 
IMO it's embarrasing that NFSv4's most useful feature for
Internet users (delegation) is useless for anyone that works
behind a NAT (most of us).

	Brent

---

From: Alfred Perlstein <[email-masked]>
Date: Thu, 30 May 2002 10:51:05 -0700

> behind a NAT (most of us).

Agreed!

But anyhow, my apologies for bringing up an old topic, thanks for
the pointer and I'm glad you guys are considering this issue.

-- 
-Alfred Perlstein [[email-masked]]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/