Subject: RE: [nfsv4] is this a valid locking sequence?

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 2 Sep 2003 11:34:09 -0700

> Most of this is useful when working over unreliable transports
> (e.g. UDP). 

That would be when it is most useful but my interpretation of
the spec is that UDP is not among the transports that should
be supported.

The second paragraph of section 3.3, says:

   Where an NFS version 4 implementation supports operation over the IP
   network protocol, the supported transports between NFS and IP MUST be
   among the IETF-approved congestion control transport protocols, which
   include TCP and SCTP.  To enhance the possibilities for
   interoperability, an NFS version 4 implementation MUST support
   operation over the TCP transport protocol, at least until such time
   as a standards track RFC revises this requirement to use a different
   IETF-approved congestion control transport protocol.

UDP is not among the "the IETF-approved congestion control transport 
protocols" and so I interpret that as implying that UDP MUST NOT be 
supported, although the IETF doesn't have any enforcement mechanism 
if you choose to support it.  Idea for a horror movie with a small
deeply-disturbed following: Engineer slighly violates spec, thinking
nobody will notice.  Then deals with the IETF-demon, or is it his
conscience, or is he just nuts? :-)

> Except in the case of connections being dropped, it is mostly 
> unneeded. 

Except in the case of connections being dropped, I would say it
is totally unneeded, but that case does exist.

> If someone wants to mandate reliable transports I would gladly 
> rip the seqid out in a future version.

Reliable transports per se are not mandated but the requirement
about congestion control efectively does that.  However you still
have the issue of connections being dropped.  Is it possible to
mandate that connections never be dropped except when the client
or server fail?

-----Original Message-----
From: David Robinson [mailto:[email-masked]]
Sent: Friday, August 29, 2003 1:10 PM
To: Ronald E Bretschneider
Cc: [email-masked]
Subject: Re: [nfsv4] is this a valid locking sequence?

Ronald E Bretschneider wrote:
> Section 8.1.5 says "Note for requests that contain a sequence number, for
> each lock_owner, there should be no more than one  outstanding request".
> What does "one outstanding request" mean? Does the request mean the RPC
> operation or does it mean the completion of the asynchronous lock grant? As
> an example, does this mean that if a lockowner has issued a blocking lock
> request which has been denied, must the client poll for the results before
> issuing a subsequent locking request on behalf of this lockowner?

The sequence numbers provide at-most-once semantics, in this context
and outstanding request is an RPC that the client has sent but has
not received an RPC reply. It is illegal to send a new RPC with a
new sequence number until the reply of the previous RPC has
been received.

The server should keep track of the last seqid that it has
seen (N) and responded to. If it see's N again it is an
indication that its reply has been lost and this is
a retransmit.  If it see's a value < N, then this is a
replayed request that got lost in the ether and should
be dropped. If it see's N+1 it is simply a new request
and updates the last seen to be N+1.  If it see's a value
greater than N+1 the client is broken as it MUST NOT send
N+2 until it has seen the reply to N+1 which the server has
not yet seen or sent.

Most of this is useful when working over unreliable transports
(e.g. UDP). Except in the case of connections being dropped,
it is mostly unneeded. If someone wants to mandate reliable
transports I would gladly rip the seqid out in a future version.

	-David

> 
> In other words, is the following locking sequence valid? Certainly each
> lock request is in a different compound RPC.
> /* blocking request, cfh=f1 */
> 
> Lock  locktype=writew_lt
>       reclaim=false
>       offset=0
>       length=100
>       locker.lock_stateid=x1
>       locker.lock_seqid=y
> /* server returns NFS4ERR_DENIED */
> 
> /* blocking request, different range than the previous request, cfh=f1 */
> lock  locktype=writew_lt      blocking request for a different range
>       reclaim=false
>       offset=1000
>       length=200
>       locker.lock_stateid=x1
>       locker.lock_seqid=y+1
> 
> Does the server allow this request, or must the client poll for the granted
> lock before being allowed to issue the second lock request?
> 
> thanks,
> Ron
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
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: David Robinson <[email-masked]>
Date: Tue, 02 Sep 2003 14:34:03 -0500

> the spec is that UDP is not among the transports that should

Yes, but in the initial design of V4 things were done with a
wink and a nod knowing that it was to help make UDP work
well.  Much of this was before the IETF mandate. In hindsight
I think that was a mistake, to which I contributed.

> mandate that connections never be dropped except when the client

But it is quite feasible to have an unreliable transport with
congestion control, UDP is clearly not one of them.

While I haven't thought through all the details, but if we were
to mandate that NFS run over a connection oriented transport
there are a number of things we could do to take advantage
of knowing when a connection is dropped. A dropped connection
prevents the long lost packet from reappearing in from the ether
so the case where seqid < N or seqid > N+1 is "impossible". Introducing
mechanisms to create the notion of a session where state is
(re-)established when a connection is made. The client knows what
its last stateid was and its last unacknowledged state changing
operation was, if the current server state is the client's
current state then the last op was not completed, if different
it only needs to get the last response replayed, maybe adding
an explicit "replay" bit. Haven't worked the details, but if
we decide to be more strict in our transport requirements
we have some opportunities to clean up the common cases.

	-David