[nfsv4] Re: seqids after changing slot table size

[NeilBrown <[e-mail]>]

On Sat, 16 Nov 2024, David Noveck wrote:
> 
> 
> I'm convinced.  The next draft of rfc5661bis will address this issue.
> 

Hi,
 I would like to offer some thoughts on how this issue could be
 addressed.

 The issue is that retiring of DRC slots is mentioned in the RFC but
 details are scarce.  It is not clear whether or when either peer can be
 sure that that the other has retired a slot, or exactly what that
 means.  It *is* clear on some cases where the peer *cannot* retire a
 slot.

 I think there are broadly two issues.  One is how to deal with the lack
 of specificity in the text.  The other is how to be sure that resetting
 the seqid for a slot (which might be implied when a slot is retired)
 doesn't result in any risk of a request from before the retirement being
 processed after the retirement.

 It is possible for a request to be sent on one connection, then for
 that connection to be closed and the same request (session,slot,seq) to
 be sent on another connection.  The seqno ensures that if both
 instances are received it is only handled once.  Reusing a seqno
 *quickly* defeats this.  It is already possible to reuse seqno after
 2^32 requests but this is not quick enough to cause a problem.  We must
 ensure that the reuse that can happen when a slot is retired and the
 seqno is reset is also delayed enough - though maybe not quite that
 much.

 It is clear that if the requester indicates a particular max slot
 number is in use, the replier indicates a new max-slot number to use
 (not less than the max in use, but less than the previous max-to-use),
 and if the requester sends another request on the same slot with the same
 or less max-slot number in use, then the replier can discard cached
 replies in slots higher than the agreed max.

 I believe that the replier SHOULD NOT discard the seqno together with
 the cached reply.  If it subsequently increases the max-slot number it
 should allow the requester to use either the next seqno in the original
 sequence, or 1.  If the requester uses 1, then the stored seqno for all
 subsequent slots can at that point be discarded.

 I believe the requester is never required to discard the seqno for any
 slot that it has used (while the session is still active) but may
 choose to if:
   1/ it has never resent any request on that slot or a later slot or
   2/ it has resent a request on that or a later slot but the connection
      that the original was sent on, which is now closed of course, has
      received a confirmation of closure from the replier or has been
      closed for one full lease time.

 As an extra caution I wonder if the replier should wait not only for a
 confirmation of the reduced max-slot number but should wait to see a
 confirmation on every connection that is bound to the session.  This
 could be important if a retired slot had only seen 1 request so seeing
 seqno=1 could be an old or new request.  If the request is being
 careful as described above that shouldn't be a problem, but we cannot
 be sure that all current implementations are that careful.

 Implementing this may have to wait for an idle connection to be
 closed.  However it could be problematic if a connection is bound to
 two session, but only one session is using it.  In that case it would
 not be closed due to idleness, but would not present a confirming
 request for the session of interest.  Possibly the replier could
 generally decide that one lease-time is sufficient to wait before
 retiring slots, but can do it more quickly if a confirmation request is
 received on each connection.  As lease-time is typically less than
 idle-connection-timeout, this is likely the more efficient approach.

Thanks,
NeilBrown