Subject: RE: [nfsv4] potential changes to nfs41_prot.x (sessionid4, streamchannelattrs4, rdmachannelattrs4)

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 22 Aug 2006 13:08:53 -0400

> It is believed that with the recent changes to the association of 
> clientid to session that the additional space for a sessionid4 is 
> unnecessary and that a uint64_t should suffice.

I think I said something like that but later decided that wasn't
relevant, since you have to determine the clientid from the sessionid
alone in the SEQUENCE op.

This still leaves the question of whether 64 bits of sessionid is
enough.  Since the number of sessions per client is likely to be
small I would argue that if 64 bits is enough for clientid, then
it is enough for sessionid.  Conversely, if 64 bits isn't enough 
for sessionid, then it probably isn't enough for clientid either.

Note that we are free to increase clientid in v4.1.  Everywhere 
that clientid4 appears in the v4.0 protocol is vesigial and 
will be all zeros.  We could create a 128-bit clientid41, if we
need to.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, August 22, 2006 11:44 AM
To: [email-masked]
Subject: [nfsv4] potential changes to nfs41_prot.x
(sessionid4,streamchannelattrs4, rdmachannelattrs4)

In an attempt to solidify more nfs41_prot.x changes prior to draft-06
and hence the interim meeting, we need to resolve the following issues
if possible.

We need your input Tom if you are available.  The issues are:

44	streamchannelattrs4 is not defined
45	rdmachannelattrs4 is not defined	
29	List of NFSv4.1 data types not complete

For 44, 45, we need additional context and whether they need to change
from their current placeholder definitions of:

typedef uint32_t streamchannelattrs4;
typedef uint32_t rdmachannelattrs4;

For issue 29, I believe that this work has been done and will confirm it
for draft-06.  During the discussion of this issue during today's
conference call it was suggested that we change the current definition
from:

typedef opaque		sessionid4[16];

to

typedef uint64_t	sessionid4;

It is believed that with the recent changes to the association of
clientid to session that the additional space for a sessionid4 is
unnecessary and that a uint64_t should suffice.

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 22 Aug 2006 12:37:00 -0500

> will be all zeros.  We could create a 128-bit clientid41, if we

The server needs to be able to determine if a clientid and sessionid
are stale.  And they are global for the server (not just client/server
pair).  So is there enough space for stale/old determination given
the lifetime of the server and also considering duration of
a single instance of a server (between reboots).  How many sessions
do we expect clients to create and use?  

Given that sessions are required for almost any productive use,
I could imagine a stupid user level client (like a filemanager browser)
that might create a session for each connection to the server.

Mmmm, is 64bits enough....

Spencer