Re: [nfsv4] Draft is updated following your comments, Thanks//答复: draft-mzhang-nfsv4-sequence-id-calibration-01

On Sun, Apr 9, 2023 at 11:39 PM yangjing (U)
<yangjing8=40huawei.com@dmarc.ietf.org> wrote:
>
> The draft is updated as https://www.ietf.org/archive/id/draft-mzhang-nfsv4-sequence-id-calibration-02.txt
Here are a few generic comments about the draft (I know nothing about
detailed formatting, etc).

1 - It is my understanding that new operations can only be added to
minor version 2 and not
     minor version 1.
2 - I largely agree with what Tom Talpey said in his comments. I think
you need to figure out
     how/when the sequenceid is getting messed up.
     Note that it is my understanding that the main purpose of
sessions is to achieve
     "exactly once RPC semantics" (the fact that the reply cache is
bounded in size is a nice
     added feature, but not the principal purpose).
     As such, a sequenceid being misordered implies that "exactly
once" semantics could
     already have been broken by a software bug in the client.

     You note that the misordered sequenceid could be caused by
"network partitioning".
     In a correct implementation that should not be the case. After a
network partition heals,
     the client should re-send all outstanding RPCs with the same
Session/slot/sequenceid
     as was used in the original RPC request message. These should
succeed (no misordered
     error reply) using cached replies, as required.
     --> If a client's recovery from network partitioning is not doing
this, then it needs to be
           fixed.
     --> As above, if a misordered sequenceid error reply is due to a
client bug, then that
           must be fixed, since "exactly once" semantics may already be broken.
The common client bug that results in a misordered sequenceid error
reply happens when
an in-progress RPC gets interrupted before the RPC reply is processed.
This is not a case
where your suggested extension should be used, since the in-progress
RPC may still be
"in-progress". Although I am not sure there is a 100% correct way for
a client to handle
the need to interrupt an in-progress RPC, marking the session slot as
broken and no
longer using it is the best approach I am aware of. (I suspect you
might be referring to
the Linux client and I cannot comment on how it handles interruption
via signals or
timeouts for session slots, since I am not a Linux client implementor.)

It sounds like migration might be an exception to the above, but it
should be addressed
specifically (as Tom Talpey notes).

3 - If your extension were used by a client, how would the client know
whether or not
     there are still RPC(s) in-progress that have been assigned that
session/slot/sequenceid?

rick

> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4