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

[Benjamin Kaduk <[e-mail]>]

On Sat, Jan 18, 2020 at 08:35:57AM -0500, David Noveck wrote:
> On Mon, Jan 13, 2020 at 1:27 PM Benjamin Kaduk <[e-mail]> 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 <[e-mail]> 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