Subject: [nfsv4] Create session and lease renewal

From: "Iyer, Rahul" <[email-masked]>
Date: Tue, 4 Sep 2007 18:29:42 -0700

Hi all,
I had a question regarding create session and lease renewals. Let's say
the following sequence of actions happens:
 
TIME               RPC
0                     EXCHANGE_ID                  // Establishes
clientid at server
1                     CREATE_SESSION           // Confirms clientid,
creates session
2                     GETATTR for lease time     // Get lease time;
value = 60
...
25                   CREATE_SESSION           // Create another session

Now, given that the client has created a new session (and thus shown
"proof of life") does it mean that the client lease is renewed or is the
client still expected to send a SEQUENCE op before the old lease expiry
time (time 62) in order to ensure that the client id/state is valid?
 
Thanks,
Regards
Rahul
 
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Benny Halevy <[email-masked]>
Date: Wed, 05 Sep 2007 14:21:29 +0300

Although it makes sense to renew the lease on CREATE_SESSION
I think it's simpler if it does not do that by itself.
The client can always precede CREATE_SESSION with SEQUENCE
if it intends to trunk it to the same client ID.

Benny 

On Sep 05, 2007, 4:29 +0300, "Iyer, Rahul" <[email-masked]> wrote:
> ------------------------------------------------------------------------
>

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Sep 2007 08:13:34 -0400

We discussed a related issue at the locking review.  The thing about
preceeding this with a sequence is that strictly speaking, the COMPOUND
is not atomic so the time of the sequence and the CREATE_SESSION (for
example) might not be the same.

So I have been thinking that the rule should be that you renew the
lease:

    At SEQUENCE.

    At any operation which creates a piece of locking state.

Otherwise, we might have the odd situation that we create a lock which
is expired from the moment is created, and that just seems weird.

The reason that this hooks up with your question, is that we have also
been considering the question of whether having a session means you have
lease.  In other words, is a session to be considered as state.  In
v4.0, the model was that you didn't have a lease until you had some type
of lock.  But now, given that SEQUENCE renews the lease, it's kind of
odd to have it renew the lease when you might not have one.

So given all that, I'm thinking that as part of the update for the
locking review, we say the lease is renewed at SEQUENCE and at any
operation that creates state and that having a session means you do have
a piece of state.  So the answer to whether CREATE_SESSION
renews/creates a lease would be "Yes".

So if there is no objection, that's what I'm going to do. 

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 7:21 AM
To: Iyer, Rahul
Cc: [email-masked]
Subject: Re: [nfsv4] Create session and lease renewal

Although it makes sense to renew the lease on CREATE_SESSION I think
it's simpler if it does not do that by itself.
The client can always precede CREATE_SESSION with SEQUENCE if it intends
to trunk it to the same client ID.

Benny 

On Sep 05, 2007, 4:29 +0300, "Iyer, Rahul" <[email-masked]>
wrote:
> Hi all,
> I had a question regarding create session and lease renewals. Let's 
> say the following sequence of actions happens:
>  
> TIME               RPC
> "proof of life") does it mean that the client lease is renewed or is 
> the client still expected to send a SEQUENCE op before the old lease 
> expiry time (time 62) in order to ensure that the client id/state is
valid?

---

From: Benny Halevy <[email-masked]>
Date: Wed, 05 Sep 2007 15:45:12 +0300

I have no objection.
If you say the sessionid represents state the same as other types of stateids
it even makes sense :-)

Benny

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Sep 2007 06:19:26 -0700 (PDT)

> So if there is no objection, that's what I'm going to do. 

Not just creating state. Say I have:

   SEQUENCE, PUTFH, READ

In NFSv4.0 we'd have just had:

   PUTFH, READ

and in NFSv4.0 the READ, because it took a stateid, renewed the
lease. 

Wouldn't be simpler to state that the lease is renewed at
SEQUENCE, and MUST NOT expire during the processing of the
remaining operations in the COMPOUND, and MUST be renewed after
the COMPOUND is executed.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Sep 2007 09:36:00 -0400

> and in NFSv4.0 the READ, because it took a stateid, renewed the lease.

True but we are not under any obligation that I can see to renew the
lease under all circumstances under which it would have been renewed in
v4.0. 

The case in which we create state is different in that it has the
potential issue that you can create state with an expired lease (but
which didn't exist when the lease was itself expired) so that the
description of lease expiration and lease revival has one more really
nasty case to deal with.

> remaining operations in the COMPOUND, and MUST be renewed 
> after the COMPOUND is executed. 

It is simpler to say, but I'm not sure that the resulting protocol is
simpler (or even as simple).  So you could have a lease renewed (at
SEQUENCE), the lease expire, have a lock created with a lease that is
expired (so maybe it vanishes as soon it is created?) and then the lease
is revived when the COMPOUND ends.  I'd like not to have describe all
the possibilities that that raises.  I think it is simpler if creation
of state is a lease-renewing/reviving event.

-----Original Message-----
From: Mike Eisler [mailto:[email-masked]] 
Sent: Wednesday, September 05, 2007 9:19 AM
To: [email-masked]
Subject: RE: [nfsv4] Create session and lease renewal

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

> operation that creates state and that having a session means you do 
> have a piece of state.  So the answer to whether CREATE_SESSION 

   SEQUENCE, PUTFH, READ

   PUTFH, READ

and in NFSv4.0 the READ, because it took a stateid, renewed the lease. 

Wouldn't be simpler to state that the lease is renewed at SEQUENCE, and
MUST NOT expire during the processing of the remaining operations in the
COMPOUND, and MUST be renewed after the COMPOUND is executed.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Sep 2007 07:49:27 -0700 (PDT)

> lease under all circumstances under which it would have been renewed

So if the lease attribute is 60 seconds, at time T SEQUENCE is
processed, and at time T+61 the READ is processed, I lose my lease,
my locks, and the READ fails?

It should be made clear in the spec if that's what we really want
to design.

I think that when this situation comes up, customers will be irate
at the insult (lost lease) to injury (because a server takes 61
seconds to process a PUTFH ... it could happen if a file system is
offline, or LDAP is offline during the export policy check) and server
implementors will rapidly
adopt my model.

I know that realistically NFS4ERR_DELAY will be returned if PUTFH
really takes 61 seconds, but doesn't detract much my point. If the
server aborts PUTFH after say 20 seconds, then unless COMPOUND
renews the lease at the end of processing, the client has just
40 seconds of lease left. So because the server, which is already
slow, fails to renew the lease, the client has to send SEQUENCE
more frequently, adding more load to the server, and exacerbating
the situation.

> SEQUENCE), the lease expire, have a lock created with a lease that is

I wrote: "MUST NOT expire during processing of the remaining
COMPOUND". If the lease is renewed at SEQUENCE, under my
suggestion it expires no sooner than the wall clock
time at when the COMPOUND
completes plus the lease attribute.

We already require the server to associate the sessionid (and
the implied client ID) of the SEQUENCE
with all remaining operations in the COMPOUND, and we already require
that a COMPOUND have just one SEQUENCE. Further requring the timer
that is the lease to be reset to the value of the lease attribute, when
SEQUENCE is seen, then paused(i.e. not flow backwards) during
the COMPOUND processing and then resuming the timer when the processing
stops is really a small thing by comparison.

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 05 Sep 2007 10:05:12 -0500

I agree with this assessment, Mike.

It is easier to understand even in the environment that
COMPOUND is not atomic in nature.  The COMPOUND is process
as a whole and for very odd, edge case reasons, it may take
a very long time (longer than the lease).

Spencer

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 05 Sep 2007 10:06:37 -0500

> description of lease expiration and lease revival has one more really

Would you mind providing a scenario where this could happen so
that we capture it in the archives so it is clear such that it
doesn't end up as a piece of NFSv4.1 esoteric knowledge.

Spencer

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Sep 2007 11:34:48 -0400

So here is a model that I think addresses my issue, the possiblity of
creating a lock while a lease is expired, and your issues, the
possiblity of encountering expired state where it was renewed by a
sequence in the same compound, and the possibility of a COMPOUND
returning when there is not much time left in the lease.

a) Lease is renewed on SEQUENCE

b) Lease is renewed upon termination of COMPOUND

c) A lease is not allowed to expire if there is any currently executing
COMPOUND for any associated session.

I think this would make it easier to reason about the protocol since any
COMPOUND will execute entirely within a single lease epoch (defined as
the period between creation/revival of a lease and lease expiration).

Note however that you could still get NFS4ERR_EXPIRED in response to
SEQUENCE/PUTFH/READ, just as could have happened in v4.0 in response to
SEQUENCE/READ, but only when lock was lost as a result of lease
expiration before the SEQUENCE happened and so in this case (for v4.1)
the sequence status bits will indicate the results of the lease
expiration event.

---

From: "Halevy, Benny" <[email-masked]>
Date: Wed, 5 Sep 2007 11:37:02 -0400

I agree too.
 
Back to the original question...
Since CREATE_SESSION specifies the clientid it can
renew the lease the same way SEQUENCE does.
Do we want to special case it in case the clientid is already
confirmed and the compound does not start with SEQUENCE?
 
Similarly this question could be asked with regards to EXCHANGE_ID 
with EXCHGID4_FLAG_UPD_CONFIRMED_REC_A and
BIND_CONN_TO_SESSION.
 
Like I said before the lease can renewed whenever the clientid is referenced,
either directly or via the sessionid and be implicitly extended throughout
the life time of the COMPOUND as Mike proposed.
 
By the way, the spec does not say whether it is allowed
to follow CREATE_SESSION with other operations
in the compound.  Theoretically I think that even if SEQUENCE precedes
CREATE_SESSION such operations could be executed in the 
context of the existing session however that seems to be confusing
and I'd vote to explicitly disallow any other operation to follow
CREATE_SESSION.
 
Benny

________________________________

From: Spencer Shepler [mailto:[email-masked]]
Sent: Wed 2007-09-05 18:05
To: [email-masked]
Cc: [email-masked]
Subject: Re: [nfsv4] Create session and lease renewal

Spencer

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Sep 2007 08:40:38 -0700 (PDT)

We are in perfect agreement; I was apparently not being clear.

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 5 Sep 2007 11:44:03 -0400

I didn't read your note carefully enough.  Sorry.

---

From: Mike Eisler <[email-masked]>
Date: Wed, 5 Sep 2007 08:50:32 -0700 (PDT)

> confirmed and the compound does not start with SEQUENCE?

My opinion is no, since the special case is not necessary.

If you want a CREATE_SESSION to renew an existing client ID's lease,
then prefix CREATE_SESSION with a SEQUENCE for another sessionid
with the same client ID.

> with EXCHGID4_FLAG_UPD_CONFIRMED_REC_A and

Ditto for the former; Prefix such an EXCHANGE_ID with SEQUENCE.

For the latter, an argument for a special case to have
BIND_CONN_TO_SESSION renew the lease is that a client might
have lost all its connections on the session. 
The state protection model (selected
when EXCHANGE_ID/CREATE_SESSION established and confirmed the
client ID) might require BIND_CONN_TO_SESSION. In that situation,
the client is in peril of losing its lease, so the sooner it can
do that, the better.

> to follow CREATE_SESSION with other operations

OK, we need to fix that.

> and I'd vote to explicitly disallow any other operation to follow

If SEQUENCE precedes CREATE_SESSION, it seems unnatural to disallow
subsequent operations.

If SEQUENCE does not precede CREATE_SESSION, the set of operations
that could possibly follow CREATE_SESSION is limited. Regardless,
I think it is reasonable to have a blanket rule that says unless
SEQUENCE starts the COMPOUND, COMPOUND can have just one operation.
> >> lease under all circumstances under which it would have been
> renewed
> >> in
> >> v4.0.
> >
> SEQUENCE,
> >> and
> >> MUST NOT expire during the processing of the remaining operations
> in
> >> the