Subject: [nfsv4] more re: RPCSEC_GSS Init delay

From: [email-masked]
Date: Thu, 11 Aug 2005 12:53:02 -0400 (EDT)

> NFS4ERR_DELAY isn't appropriate ... you would be returning that error
> in an overloead NULL procedure which has no place for for a program
> specific error code, nor does the response to the RPCSEC_GSS Init have
> a place.

Yep, I brain farted. I forgot that the Null RPC doesn't have a reply status
field and that the GSS token is all that is in the reply body.

> You could conceivably come up with an appropriate GSS error to return
> (GSS_S_CONTEXT_EXPIRED ?), but I don't know that RPCSEC_GSS clients will
> interpret that as _DELAY.

I'll leave this for the client guys, since it would have to be something
that gets them to "retry the authentication Initialization".

> It might be best to drop the request (and disconnect), or queue it, and
> retry to gssd.

Again, I'd like to hear what the client guys think of a disconnect.
(As for retrying the upcall, it actually was happenning, but my server
 nfsd threads were giving up after 10sec. I increased that to 1 minute
 and it resolved the case I was testing. What I'm not sure about is
 "how long" I can delay replying to the client before I'm stuck with
 the choice of "failed authentication" vs "disconnect".)

Also, I understand "disconnect" for a TCP connection, but what about
other transports in the spiffy new sessions extensions?

Thanks for any comments, rick

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:06:59 -0500

> Again, I'd like to hear what the client guys think of a disconnect.

Never mind what the client guys think -- if you have a connection with
many live contexts being used then disconnecting upon time out in
establishing a new context will be very painful, first for the client,
then for the server when the client returns to re-establish the
connection, the contexts, state... and in so doing exacerbates the gssd
timeout problem, leading to a vicious cycle of pain.

>  the choice of "failed authentication" vs "disconnect".)

Try not timing out on upcalls to gssd.  If gssd dies, then return some
generic GSS error (e.g., GSS_S_DEFECTIVE_TOKEN) and let the client
retry.

> other transports in the spiffy new sessions extensions?

Badness.  See above.

Nico
--

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 11 Aug 2005 13:07:39 -0400

>  the choice of "failed authentication" vs "disconnect".)

You want to be very careful about that, since there be replay-dragons
there. Breaking the connection in the absence of sessions also means
breaking the ordering of requests, so it should be kept to a minimum.

Isn't there some way you can deal with these requests asynchronously? In
Linux we can put the request on a "defer" queue if gssd takes too long
to respond. We then replay the entire request to the nfsd thread once
the congestion issue has been resolved.

> other transports in the spiffy new sessions extensions?

non-connection based transports with sessions are likely to have some
form of timeout+resend mechanism, so they should be fine.

Cheers,
  Trond

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 11 Aug 2005 13:15:39 -0400

> timeout problem, leading to a vicious cycle of pain.

Huh? What contexts and state would the client need to reestablish when
the server disconnects the transport? The only stuff that has state
hanging off the transport is CCM, and no-one is implementing that.

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:20:05 -0500

> hanging off the transport is CCM, and no-one is implementing that.

Ah, yes, the live contexts should continue to work.  Channel bound
contexts should be deleted upon disconnect.

But you can still have a vicious cycle if the server's gssd keeps timing
out, leading to more disconnects, leading to more reconnects...

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 11 Aug 2005 13:25:23 -0400

> out, leading to more disconnects, leading to more reconnects...

Sure. ...and as was pointed out, there are other reasons why you don't
want to disconnect if you can possibly avoid it (screws up only-once NFS
semantics).

Cheers,
  Trond

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:28:46 -0500

> want to disconnect if you can possibly avoid it (screws up only-once NFS

You already had to worry about exactly-once semantics before, but, yeah.

---

From: Robert Gordon <[email-masked]>
Date: Thu, 11 Aug 2005 12:29:38 -0500

> Again, I'd like to hear what the client guys think of a disconnect.

Ouch! -- I think just dropping the clients RPCSEC_GSS Init request
to allow it an opportunity to resend would be appropriate.

The Solaris client currently waits 30 seconds for a reply.

-- Robert

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 11 Aug 2005 12:42:22 -0500

> The Solaris client currently waits 30 seconds for a reply.

We should probably have it delete the sec context and retry for some
major status codes, such as GSS_S_DEFECTIVE_TOKEN.  That should probably
be part of the spec.

Nico
--