[nfsv4] 答复: nfsv4 Digest, Vol 227, Issue 18

Send nfsv4 mailing list submissions to
	nfsv4@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/nfsv4
or, via email, send a message with subject or body 'help' to
	nfsv4-request@ietf.org

You can reach the person managing the list at
	nfsv4-owner@ietf.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of nfsv4 digest..."

Today's Topics:

   1. Re: Fwd: New Version Notification for
      draft-mzhang-nfsv4-sequence-id-calibration-01.txt (Yang Jing)

----------------------------------------------------------------------
Message:1
Date: Thursday, 6 April 2023
From: Yang Jing <yangjing8@huawei.com>
To: nfsv4@ietf.org
Subject: Re: [nfsv4] Fwd: New Version Notification for
	draft-mzhang-nfsv4-sequence-id-calibration-01.txt

> -----邮件原件-----
> 发件人: nfsv4 [mailto:nfsv4-bounces@ietf.org] 代表 nfsv4-request@ietf.org
> 发送时间: 2023年4月1日 3:00 AM
> 收件人: nfsv4@ietf.org
> 主题: nfsv4 Digest, Vol 227, Issue 18
> 
> Send nfsv4 mailing list submissions to
> 	nfsv4@ietf.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/nfsv4
> or, via email, send a message with subject or body 'help' to
> 	nfsv4-request@ietf.org
> 
> You can reach the person managing the list at
> 	nfsv4-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of nfsv4 digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Fwd: New Version Notification for
>       draft-mzhang-nfsv4-sequence-id-calibration-01.txt (Tom Talpey)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 31 Mar 2023 12:02:14 -0400
> From: Tom Talpey <tom@talpey.com>
> To: nfsv4@ietf.org
> Subject: Re: [nfsv4] Fwd: New Version Notification for
> 	draft-mzhang-nfsv4-sequence-id-calibration-01.txt
> Message-ID: <f57c7b56-7812-58a1-ae45-447c9e7ba933@talpey.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> 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.
> 

Thank you for your comments Tom.

> 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.
> 

This draft is talking about after misordered sequence happens, what the client and the server should do to minimize the impact.
Compared with the current implementation which tries to reset the sequenceid by dropping the session, 
the new way is to try to get the correct sequenceid without impacting on the normal slots of this session.

> 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.
> 

I agree with you, RFCs for nfsv4.1 does not clarify what requester should do if misorder error returned. 
But the question is still there, what the requester should do? This draft is answering this question. ^_^

> 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.
> 

Just like you mentioned, misorder sequence does not happen on normal scenario(It may happen due to network error, or software bug, or some others), 
so it is very difficult to capture the packages. 
Since the error code is defined in the specification, the behaviors should also be clear and be better. 

Thank you Tom
Best Regards

Jing

> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> 
> ------------------------------
> 
> End of nfsv4 Digest, Vol 227, Issue 18
> **************************************