Re: [nfsv4] Fwd: New Version Notification for draft-mzhang-nfsv4-sequence-id-calibration-01.txt

[Tom Talpey <[e-mail]>]

On 3/20/2023 2:55 AM, yangjing (U) wrote:
> About draft draft-mzhang-nfsv4-sequence-id-calibration-01.txt , do you have any comments on it?

Thank you for presenting this in yesterday's WG session.

I'm not sure that I agree this is the correct approach.
A misordered sequence number is not something that should
occur in normal operation, but it can occur in certain
recovery scenarios. Your draft attempts to provide a way
for the client to reset the sequenceid, but this does not
address the underlying error! In fact, in my opinion it
dangerously makes things worse, by effectively ignoring it.

However, I agree that a more clear statement of the handling
of a misordered sequence error can be made in RFC 8881.
There is one special case, I believe, which allows the server
to return misordered from a busy reply cache entry (section
2.10.6.2 of RFC8881), but makes no statement how the client
should handle it. Also there is some rather vague language
in section 11.14.3 regarding the server, where I find the
following:

> In view of the difficulty of arriving at a mutually acceptable value
> for the correct last sequence value at the point of migration, it may
> be necessary for the server to show some degree of forbearance when
> the sequence ID is one that would be considered unacceptable if
> session migration were not involved.

"Some degree of forbearance" is not exactly normative. :)

After we understand your report some more, perhaps filing an
erratum will be appropriate to correct or improve these.

You mentioned that your and your team were not able to identify
the cause using logging on client and server. May I suggest you
try capturing a trace, or add some synthetic testing to determine
whether this is the server not validating the slot/sequence properly,
if it's the client actually sending a bad sequence into the slot,
or is one of the special cases in RFC 8881? Also, what operations
are actually receiving this misordered error? The draft correctly
mentions three possibilities, but I don't recall hearing which one
led you to this approach, or whether the new operations can be
somehow limited to recovering them.

By the way, which clients, and which servers, have you observed
this issue with?

Tom.