Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 22 January 2020 03:25 UTC

Return-Path: <kaduk@mit.edu>
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 4C7A312002F; Tue, 21 Jan 2020 19:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5pI8CMOPG4X; Tue, 21 Jan 2020 19:25:54 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33DC120013; Tue, 21 Jan 2020 19:25:43 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00M3PadP003330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jan 2020 22:25:38 -0500
Date: Tue, 21 Jan 2020 19:25:35 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: David Noveck <davenoveck@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rfc5661sesqui-msns@ietf.org, nfsv4-chairs@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, NFSv4 <nfsv4@ietf.org>
Message-ID: <20200122032535.GF80030@kduck.mit.edu>
References: <157665795217.30033.16985899397047966102.idtracker@ietfa.amsl.com> <CADaq8jegizL79V4yJf8=itMVUYDuHf=-pZgZEh-yqdT30ZdJ5w@mail.gmail.com> <20191223021435.GW35479@kduck.mit.edu> <CADaq8jetpqMbKgVj6xTHYqkeJZXL3WZsVgrRdooYhaK0S8uTVA@mail.gmail.com> <20200113182716.GH66991@kduck.mit.edu> <CADaq8jdELRzigMvsWsNGQmPUs0uqm2fJkuO9RPH=bXhd4q0qYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CADaq8jdELRzigMvsWsNGQmPUs0uqm2fJkuO9RPH=bXhd4q0qYw@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/B93Z5grVV8CLTnE4C7atZTxegUs>
Subject: Re: [nfsv4] Benjamin Kaduk's Discuss on draft-ietf-nfsv4-rfc5661sesqui-msns-03: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 Jan 2020 03:25:56 -0000

On Sat, Jan 18, 2020 at 08:35:57AM -0500, David Noveck wrote:
> On Mon, Jan 13, 2020 at 1:27 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> > Hi David,
> >
> > Lots of good stuff trimmed (and thank you for them!).  Just one comment for
> > this thread...
> >
> > On Thu, Jan 02, 2020 at 10:08:23AM -0500, David Noveck wrote:
> > > On Sun, Dec 22, 2019 at 9:14 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> > >
> > > > On Fri, Dec 20, 2019 at 09:46:22AM -0500, David Noveck wrote:
> > [...]
> > > > > > In a similar "discuss discuss" vein, Section 11.10.8 describes a
> > > > > > scenario that does not give much clarity, at a protocol level, into
> > > > what
> > > > > > degree of replication synchronization a client can expect from a
> > given
> > > > > > file system that advertises multiple replicas.  I recognize that
> > this
> > > > is
> > > > > > de facto just stating the deployed reality, but it's also hard to
> > feel
> > > > > > good about having this level of ambiguity in a propsed standard,
> > > > >
> > > > > It gets easier over time.  Sigh!  This would be the fourth Proposed
> > > > > Standard with this issue :-(
> > > > >
> > > > > Still I think we can do a bit better by relyimg on the three special
> > > > cases
> > > > > listed at
> > > > > the end of that section and adding something like the following
> > after the
> > > > > list:
> > > > >
> > > > >    When none of these special situations apply, there is no basis,
> > > > >    within the protool, for the client making assumptions about the
> > > > >    contents of a replica file ststem and its relationship to previous
> > > > >    file sytem instances.  This may mean that switching between file
> > > > >    system that are not read-only is not available, where either the
> > > >
> > > > Hmm, do we want to add a descriptor like "nominally identical" to "file
> > > > systems" (note: plural)
> > > >
> > >
> > > Will do.
> > >
> > >
> > > >
> > > > >    client does not use or the server does not support the
> > > > >    fs_locations_info atribute.
> > > >
> > > > That helps some.  We might consider a note in the first paragraph (near
> > > > "The namespace will typically be constructed") about the details of
> > that
> > > > being configured in an out-of-band manner.
> > > >
> > >
> > > I don't think details can be provided since this is pretty much up to the
> > > server although we can make it clear that the server constructs this on
> > > the basis of what it knows about the file system and their
> > characteristics,
> > > i.e information not really part of the protocol.
> > >
> > > How about:.
> > >
> > >    The server is responsible for contructing an appropriate namespace.
> > >    Typically, it is contructed so that applications can choose an
> > > appropriate
> > >    level of support, so that in one position in  the namespace a varied
> > set
> > >    of replicas might  be listed, while in another only those that are
> > > up-to-date
> > >    would be considered replicas.
> > >
> > >
> > > I'll think about doing that.
> >
> > I'm not so much concerned about how the server constructs the namespace (as
> > the current practice leaves that entirely up to the server), but rather how
> > the client, or some human associated with the client, learns what the
> > server did.  That is, having a fancy namespace with extra semantics doesn't
> > do you any good if no one else knows what those semantics are :)
> > I was just hoping that this document could be more explicit about "this
> > protocol doesn't give you a way to communicate the extra semantics from
> > server to client, but you probably want to do it somehow".  I don't mind
> > giving more details about the types of semantics a server might encode in
> > the namespace as well, but that's not the direction I was trying to push
> > in.
> >
> 
> OK.  I think I can address your concerns but it needs to be pointed out
> that
> in many cases of the  "extra" semanntics we are talking about, the semantics
> are clear.  This is true of trunking, referrals and migration.   In the
> case of
> "replication", we do have a lot of existing uncertainty and I will try to
> put in the
> kind of text you suggest.
> 
> This and related issues have been mentioned in a number of sub-threads and
> I intend to
> consolidate text addressing  them here.   I'm going to propose that we
> address all
> these issues by some additions to Section 11.5.4.  Specfically I propose
> revsing the
> the second paragrapgh and adding a new tthird pragraph so that the last two
> paragraphs
> read as follows;
> 
>    In the event that the occurrence of server failures, communications
>    problems, or other difficulties make continued access to the current
>    file system impossible or otherwise impractical, the client can use
>    the alternate locations as a way to get continued access to its data.
> 
>    The alternate locations may be physical replicas of the (typically
>    read-only) file system data supplemneted by possible asynchronous

(nit: "supplemented", though I made the same typo myself just now)

>    propagation of updates.  Alternatively, they may provide for the use
>    of various forms of server clustering in which multiple servers
>    provide alternate ways of accessing the same physical file system.
>    How the difference between replicas affects file system transitions
>    can be represented within the fs_locations and fs_locations_info
>    attributes and how the client deals with file system transition
>    issues will be discussed in detail in later sections.
> 
>    Although the location attributes provide some information about the
>    nature of the inter-replica transition, many aspects of the semantics
>    of posible asynchronous updates are not currently described by the
>    protocol, making it necessary that clients using replication to
>    switch among replicas undergoing change familiarize themselves with
>    the semantics of the update approach used.  Because of this lack of
>    specificity, many applications may find use of migration more
>    appropiate, since, in that case, the server, when effecting the
>    transition, has established a point in time such that all updates
>    made before that can propagated to the new replica as part of the
>    migration event.

Thanks, this covers the key point I was concerned about.

-Ben