Subject: [nfsv4] NFSv4.1 reply caching question

From: Mike Eisler <[email-masked]>
Date: Sun, 17 Feb 2008 08:02:36 -0800 (PST)

The spec at least implies, if not explicitly, that the entire original
reply must be cached.

I'm the process of reviewing the entire spec line by line, and am
reading the text that discusses highest slot processing. I am thinking
that if between a request and retry, or between two retries, the
replier decides it wants to re-size the slot table, it should
be able to indicate this even on a reply to retry of
SEQUENCE or CB_SEQUENCE. In other words, 
        sr_highest_slotid, sr_target_highest_slotid,
csr_highest_slotid;
        csr_target_highest_slotid
can be different on replies to retries.

Similarly, I think there is value in allowing the server
to change sr_status_flags on replies to retries in the event new 
conditions occur, or previously conditions change.

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

---

From: Robert Gordon <[email-masked]>
Date: Sun, 17 Feb 2008 20:59:12 -0600

> conditions occur, or previously conditions change.

So, putting this in another way:

sr_status_flags, sr_highest_slotid,
sr_target_highest_slotid, csr_highest_slotid,
csr_target_highest_slotid

values should always be "calculated" and
not replayed from the slot cache.

which seems sensible.

Robert.

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 18 Feb 2008 08:57:06 -0500

> values should always be "calculated" and not 
> replayed from the slot cache. 

"should always" seems just about on the verge of "SHOULD".  I think Mike
is saying "MAY".  I think the point is that either replay or
recalculation would be valid, but not an arbitrary mixture of the two.
I'm not sure that a mixture of replay on the slotid stuff and
recalculation on the status flags or vice versa is absolutely safe,
although I can't think of a case where it breaks anything.

-----Original Message-----
From: Robert Gordon [mailto:[email-masked]] 
Sent: Sunday, February 17, 2008 9:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] NFSv4.1 reply caching question

> replier decides it wants to re-size the slot table, it should be able 
> to indicate this even on a reply to retry of SEQUENCE or CB_SEQUENCE. 
> In other words,
> Similarly, I think there is value in allowing the server to change 
> sr_status_flags on replies to retries in the event new conditions 
> occur, or previously conditions change.

sr_status_flags, sr_highest_slotid,
sr_target_highest_slotid, csr_highest_slotid, csr_target_highest_slotid

values should always be "calculated" and not replayed from the slot
cache.

which seems sensible.

Robert.

---

From: Mike Eisler <[email-masked]>
Date: Fri, 22 Feb 2008 10:49:17 -0800 (PST)

In thinking about this more, I think replaying highest slot and
target highest slot values is more unsafe than re-computing them.

Let's say at time T the size of the slot table was 2 entries, and
then a T+1, it was increased to 1000 entries. Now the client retries
the request that first sent at time T. The server responds with a
target
highets slotid of 2.

Diffs are attached which say "SHOULD".

> values should always be "calculated" and not replayed from the slot
Index: nfsv41_middle_core_infrastructure.xml
===================================================================
RCS file: /cvs/stdk/NFSv41/nfsv41_middle_core_infrastructure.xml,v
retrieving revision 1.86
diff -u -w -b -r1.86 nfsv41_middle_core_infrastructure.xml
--- nfsv41_middle_core_infrastructure.xml	21 Feb 2008 12:58:17 -0000	1.86
+++ nfsv41_middle_core_infrastructure.xml	22 Feb 2008 18:44:22 -0000
@@ -2053,7 +2053,7 @@
      need only cache the results of a limited number of
      COMPOUND requests .
      The second implication derives
-     from the first, which is unlike XID-indexed reply
+     from the first, which is that unlike XID-indexed reply
      caches (also known as duplicate request caches - DRCs),
      the slot id-based reply cache cannot be overflowed.
      Through use of the sequence id to identify
@@ -2224,6 +2224,29 @@
     </t>
     </list>
    </t>
+     <section title="Caching of SEQUENCE and CB_SEQUENCE Replies" anchor="cacheseq">
+
+     <t>
+
+      When a SEQUENCE or CB_SEQUENCE operation is
+      successfully executed, its reply MUST always be
+      cached. Specifically, sessionid, sequenceid,
+      and slotid MUST be cached in the reply cache.
+      The reply from SEQUENCE also includes the highest
+      slotid, target highest slotid, and status flags. The
+      server SHOULD NOT cache these values, and instead
+      SHOULD re-compute the values from the current
+      state of the fore channel, session and/or client
+      ID as appropriate.  Similarly, the reply from
+      CB_SEQUENCE includes a highest slotid and target
+      highest slotid. The client SHOULD NOT cache these
+      values, and SHOULD re-compute the values from the
+      current state of the session as appropriate.
+
+     </t>
+
+     </section>
+
      <section title="Errors from SEQUENCE and CB_SEQUENCE"
        anchor="err_sequence">
      <t>
@@ -2272,7 +2295,7 @@
         The replier enters into its reply cache a reply consisting
         of the original results to the SEQUENCE or CB_SEQUENCE
         operation, and with the next operation in
-        COMPOUND or CB)COMPOUND having the error NFS4ERR_RETRY_UNCACHED_REP.
+        COMPOUND or CB_COMPOUND having the error NFS4ERR_RETRY_UNCACHED_REP.
         Thus if the requester later retries the request, it will
         get NFS4ERR_RETRY_UNCACHED_REP.
        </t>
@@ -3562,6 +3589,26 @@
    </section> <!-- Steps the Client Takes To Establish a Session -->
   </section> <!-- Session Mechanics - Steady State -->
 
+  <section anchor="session_inactive" title="Session Inactivity Timer" >
+  <t>
+   The server MAY maintain an session inactivity timer for
+   each session.  If the session inactivity timer expires,
+   then the server MAY destroy the session. To avoid losing
+   a session due to inactivity, the client MUST renew
+   the session inactivity timer. The length of session
+   inactivity timer MUST NOT be less than the lease_time
+   attribute (<xref target="attrdef_lease_time"/>).
+   As with lease renewal (<xref target="lease_renewal"/>),
+   when the server receives a SEQUENCE operation,
+   it resets the session inactivity timer, and MUST NOT allow the
+   timer to expire while the rest of the operations in the
+   COMPOUND procedure's request are still executing. Once the
+   last operation has finished, the server MUST set the session
+   inactivity timer to expire no sooner that the sum of the
+   current time and the value of the lease_time attribute.
+  </t>
+
+  </section>
   <section anchor="Session Mechanics - Recovery" title="Session Mechanics - Recovery">

---

From: Benny Halevy <[email-masked]>
Date: Sat, 23 Feb 2008 09:11:55 -0600

Minor nit:

                            ^^

That SHOULD be an "a" :)

Benny

On Feb. 22, 2008, 12:49 -0600, Mike Eisler <[email-masked]> wrote:
>> ------------------------------------------------------------------------
>>

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 23 Feb 2008 11:05:54 -0500

I think your argument shows that recomputing is better but it isn't more
safe.  If it is at all unsafe to replay these values, we have a protocol
issue that we have to resolve.  Delayed responses are always possible. 

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 1:49 PM
To: [email-masked]
Subject: Re: [nfsv4] NFSv4.1 reply caching question

In thinking about this more, I think replaying highest slot and target
highest slot values is more unsafe than re-computing them.

Let's say at time T the size of the slot table was 2 entries, and then a
T+1, it was increased to 1000 entries. Now the client retries the
request that first sent at time T. The server responds with a target
highets slotid of 2.

--- "Noveck, Dave" <[email-masked]> wrote:

> "should always" seems just about on the verge of "SHOULD".  I think 
> Mike is saying "MAY".  I think the point is that either replay or

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Feb 2008 08:05:05 -0800 (PST)

Good point.

How about this:

     <section title="Caching of SEQUENCE and CB_SEQUENCE Replies"
anchor="cacheseq">

     <t>

      When a SEQUENCE or CB_SEQUENCE operation is
      successfully executed, its reply MUST always be
      cached. Specifically, sessionid, sequenceid,
      and slotid MUST be cached in the reply cache.
      The reply from SEQUENCE also includes the highest
      slotid, target highest slotid, and status flags. Instead
      of caching these values, the server MAY
      re-compute the values from the current
      state of the fore channel, session and/or client
      ID as appropriate.  Similarly, the reply from
      CB_SEQUENCE includes a highest slotid and target
      highest slotid. The client
      MAY re-compute the values from the
      current state of the session as appropriate.

     </t>
     <t>
       Regardless whether a replier is re-computing highest slotid,
       target slotid, and status on retries or not, the requester
       MUST assume the values are not being re-computed whenever it
       receives a reply from a retry. Before taking action based on
       the values send from a retry, or from a non-retry that took
       a "long" time to get a response, the client SHOULD send a new
       request to determine what the current state especially if
       highest slotid, target highest slotid, and status flags are
inconsistent
       with recent responses on other slots. A "long" time is
subjective,
       and is not defined in this specification.
      </t>

     </section>

--- "Noveck, Dave" <[email-masked]> wrote:

> then a

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Feb 2008 11:44:32 -0500

OK.

"the values send" --> "the values sent"

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Monday, February 25, 2008 11:05 AM
To: [email-masked]
Subject: Re: [nfsv4] NFSv4.1 reply caching question

Good point.

How about this:

     <t>

     </t>
     <t>

     </section>

---

From: Benny Halevy <[email-masked]>
Date: Mon, 25 Feb 2008 08:59:09 -0800

>        and is not defined in this specification.

This text worries me since it's too fuzzy. To justify these recommendations
I think we need a better explanation of why they are needed. What could happen
if the client (or server for CB_SEQUENCE) got it wrong and acted upon a non up-to-date
reply and why following the recommendations above makes it better.

Benny

---

From: Robert Gordon <[email-masked]>
Date: Mon, 25 Feb 2008 11:13:56 -0600

> reply and why following the recommendations above makes it better.

The requester does not know the that replier used a cached response,
unless we add (perhaps) a bit to sr_status.

--
Robert...
"Don't Make Assumptions"

---

From: Mike Eisler <[email-masked]>
Date: Mon, 25 Feb 2008 09:14:31 -0800 (PST)

> reply and why following the recommendations above makes it better.

Then propose better text.

If you are claiming that we don't have problem with what is currently
in draft-20, then that is a different debate.

---

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Feb 2008 13:10:30 -0500

How about this for the second paragraph:   

       Regardless of whether a replier is re-computing highest slotid,
       target slotid, and status on retries or not, the requester
       MUST assume the values are not being re-computed whenever it
       receives a reply after a retry is sent, since he has no way
       of knowing whether the reply it has received was sent by the 
       server in response to the retry, or is a delayed response to
       the original request.  Therefore, it may be the case that 
       highest slotid, target slotid, or status bits may reflect
       the state of affairs when the request was first executed.  
       Although acting based on such delayed information is valid,
       it may cause the receiver to do unneeded work.  Receivers
       may choose to send additional requests to get the current 
       state of affairs or use the state of affairs reported by 
       subsequent requests, in preference to acting immediately
       on data which may be out of date.

---

From: Robert Gordon <[email-masked]>
Date: Mon, 25 Feb 2008 12:12:30 -0600

On Feb 25, 2008, at 10:05 AM, Mike Eisler wrote:

>        inconsistent with recent responses on other slots. A "long"  
> time is
>        subjective, and is not defined in this specification.
>       </t>

(i hadn't completely focused on the additional text, perhaps the  
emphasis
  could be slightly altered)

     <t>
        	The requester MUST assume the values are not being re-computed
	whenever it receives a reply. Before taking action based on
        	the values the requester SHOULD send a new request to validate
	the current state especially if highest slotid, target highest
	slotid, and status flags are inconsistent with recent responses
	on other slots.
     </t>

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 25 Feb 2008 10:59:24 -0800

>        on data which may be out of date.

This version looks much better.

Benny