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

Rick Macklem <rick.macklem@gmail.com> Mon, 10 April 2023 20:59 UTC

Return-Path: <rick.macklem@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164D6C151551 for <nfsv4@ietfa.amsl.com>; Mon, 10 Apr 2023 13:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03NTwLhKCC7T for <nfsv4@ietfa.amsl.com>; Mon, 10 Apr 2023 13:59:04 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8AFCC18870B for <nfsv4@ietf.org>; Mon, 10 Apr 2023 13:58:46 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id h193so2898436pgc.6 for <nfsv4@ietf.org>; Mon, 10 Apr 2023 13:58:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681160326; x=1683752326; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sK0ku1y5/YGfsN9eW2yZzc54yKBir+jI9C4oXOwKKes=; b=Vzyvn7AdTJenfcT1APk7NCU73MuKbkLEyNVOa10ILGUvjuhaTYCNcmI7hHWuyQ0lQW 2BWw0kPKJX3RRmMgCGn9t8f0WeEdUXfp1ESWVqFAxQQS/3N2M9PJ/HazAzQaA3I346Og dWT8DG24A9nH1gNyEiFSzAsJAgXSx/0ykm3kcY27xrdt+UuJRu9JGXw9wlf2RLF6GRLw 16C/HXSmijlMeXkO6XGvuR15r77WbydX6aSG0pYzzo+yH+q2p0MC7bWTF6VuvnV8OwG7 44H/q+PQTUrf8rxn4FZ2IKO+UeLwDfGml0D/LDjYqu4S2bBHKPY9QxISfA+AgokGdbSq 8sjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681160326; x=1683752326; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=sK0ku1y5/YGfsN9eW2yZzc54yKBir+jI9C4oXOwKKes=; b=Kl5lRHW2ZsAajr57Hwx8XGg+fo1qQrCtafXSPGMWoU9HrSfcbxFfsUM+PmevJmoUOn LkqGL3BGnwHdCiDOAyQXyTiYZ5ewMFKSJCWUcn/qwYgP0PLJsQMGVQA1DcXCYeG5F6nL ufzWlvS54HU8OQJCo5PGOF/mMlCfCoog/WjyRuerWiNyKtWGODxbGGBGPq91MNIjg9Up aJ1tbglGlJvPFHcEp5lW96emGIMqMV+lZKtPrkxOYyvfKv2z2orQInut6u4PZw5Cf4Mt shyB8duukZQ2uFN6PxXyHbWmXFA2GiTBNqYv/g1sAUOrse0Ztto8PVzJHLJZxGCUglDN oYng==
X-Gm-Message-State: AAQBX9cYoeuwHBT8FgtECKkfchbf3sGa1/x1h2QebWMz/H4abn/ha+0q I+vKBUF7fYF18r8uZ9czj8eZ6gOTFJhE1Yizd/h9VKa0Vw==
X-Google-Smtp-Source: AKy350ay6vuuDfZ+Ij2TUQ1Y5VulIRgnJ4DBxXv7rVWx1YgZHhguSGD8mWV9tB9RcOZDBV3a4OCQ0bymBs2qMTMbkIw=
X-Received: by 2002:a63:2c4c:0:b0:513:90ed:3c22 with SMTP id s73-20020a632c4c000000b0051390ed3c22mr3021938pgs.2.1681160325840; Mon, 10 Apr 2023 13:58:45 -0700 (PDT)
MIME-Version: 1.0
References: <83389b42bb0f49509c757cdabd5c6b3f@huawei.com> <CAM5tNy7F9Yf8rJQqy4rOwtcK_FSa+SuRsG=9KenB=mG9Wqv6MA@mail.gmail.com>
In-Reply-To: <CAM5tNy7F9Yf8rJQqy4rOwtcK_FSa+SuRsG=9KenB=mG9Wqv6MA@mail.gmail.com>
From: Rick Macklem <rick.macklem@gmail.com>
Date: Mon, 10 Apr 2023 13:58:35 -0700
Message-ID: <CAM5tNy56P0XxrDU==hjocvtBuY9DO2JrOn8PThyfBxRorbW74g@mail.gmail.com>
To: "yangjing (U)" <yangjing8=40huawei.com@dmarc.ietf.org>
Cc: Thomas Haynes <loghyr@gmail.com>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/pfdfopOGEB1A9vK2uBBZ9fr-v6o>
Subject: Re: [nfsv4] Draft is updated following your comments, Thanks//答复: draft-mzhang-nfsv4-sequence-id-calibration-01
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2023 20:59:05 -0000

On Mon, Apr 10, 2023 at 1:15 PM Rick Macklem <rick.macklem@gmail.com> wrote:
>
> 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?
An additional comment:
- If the client knows that the outstanding RPC request on the
  session/slot/sequenceid that got a misordered error reply
  is one where "exactly once" semantics is not required,
  then I can see that the client implementor might be able to
   safely resynchronize the sequenceid.
  To do this, I do not think your extensions are needed.
   If the client issues an RPC that consists of only the
   Sequence operation repeatedly, with the sequenceid incremented
   by one each attempt after waiting for a reply to the previous
   attempt, it should get NFS_OK within a few attempts.
   Then the correct sequenceid to be used for the session/slot is known.

rick

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