Subject: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt

From: David Noveck <[email-masked]>
Date: Sat, 30 Jul 2016 08:56:34 -0400

This draft addresses many of the comments in Chuck's
review sent out on on 7/22.   It was written without addressing
any of the remarks in Chuck's mail of 7/27, to which I will respond
separately.

Given the possibility that this document will be amalgamated with
draft-cel-nfsv4-rpcrdma-version-two and the need to further discuss certain
matters that relate to possible changes in subsequent versions, I've been
maintaining a list of items that still need to be decided/addressed.  It is
below, together with comments about how I'm dealing with these issues.
Corrections and comments welcome.

1) Some text adjustment is needed to make it clear that the default values
specified for characteristics here only apply to Version Two and may be
changed in subsequent versions.

Have not addressed this in -01 and don't expect to do so in -02.  I believe
that this is best addressed as part of merging this with the version-two
document.

2) Need to address other questions related to the issue of the relevance of
this extension to versions beyond two.

Feel that this issue will be addressed as part of making this part of the
Version Two base protocol.

3) Need to resolve the question about whether backward-direction support is
to be REQUIRED in Version Two.

Am leaving this up to Chuck.  This may affect the need the
backwards-direction-support characteristic.

4) Decision needs to be made about a possible replacement for the word
"characteristic".  Also, use of the abbreviation XCHAR.

Am OK in principle with a replacement but feel there needs to be working
group discussion of a possible change.  Am reluctant to make this sort of
change more than once.  Feel that this is most likely to be addressed as
part of document amalgamation.

5) Decision needed on appropriate lengthening of the names of such  types
as xchrbsiz and constants such as XCHAR_RBSIZ.

Will send out a message to the working group to get input.  If useful input
received, will incorporate in a -02 or -03.  If that doesn't happen, Chuck
and I will address as part of document amalgamation.

6) Need to resolve questions about the need for information about the
presence of backward-direction chunk support.

Chuck has made strong case for removing this.  Will think about deleting
this in -02.  In any case, if this is to be part of the base Version Two,
inevitably, the bar for inclusion will be higher, so if this is still
present when the documents are combined, will need to rethink.  Also will
be affected by Chuck's decision with regard to Item #3.

7)Need to clarify whether the treatment of remote-invalidation
characteristic should be symmetric as regard to the direction if operation.

Chuck raised this in his review but I continue to believe this should be
symmetric.  If we are not in agreement on this now, need to discuss further
on the working group list.

8) Need to respond to possible Version Two XDR change with regard to remote
invalidation approach, to allow per-request information about the
occurrence of invalidation to be returned.

Waiting for Chuck's decision about whether and how to address this in
Version Two.  If this happens before the documents are combined, will
updated the remote-invalidaion-support  to reflect this change, if, as
expected, it is OPTIONAL.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sat, Jul 30, 2016 at 7:28 AM
Subject: New Version Notification for
draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt
To: David Noveck <[email-masked]>

A new version of I-D, draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt
has been successfully submitted by David Noveck and posted to the
IETF repository.

Name:           draft-dnoveck-nfsv4-rpcrdma-xcharext
Revision:       01
Title:          RPC-over-RDMA Extension to Manage Transport Characteristics
Document date:  2016-07-30
Group:          Individual Submission
Pages:          23
URL:
https://www.ietf.org/internet-drafts/draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-rpcrdma-xcharext/
Htmlized:
https://tools.ietf.org/html/draft-dnoveck-nfsv4-rpcrdma-xcharext-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-rpcrdma-xcharext-01

Abstract:
   This document specifies an extension to RPC-over-RDMA Version Two.
   The extension enables endpoints of an RPC-over-RDMA connection to
   exchange information which can be used to optimize message transfer.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Chuck Lever <[email-masked]>
Date: Sat, 30 Jul 2016 10:22:43 -0400

Hi Dave-

Thanks for pushing forward.

> On Jul 30, 2016, at 8:56 AM, David Noveck <[email-masked]> wrote:
> 
> any of the remarks in Chuck's mail of 7/27, to which I will respond separately.
> 
> Given the possibility that this document will be amalgamated with draft-cel-nfsv4-rpcrdma-version-two and the need to further discuss certain matters that relate to possible changes in subsequent versions, I've been maintaining a list of items that still need to be decided/addressed.  It is below, together with comments about how I'm dealing with these issues. Corrections and comments welcome.  
> 
> 1) Some text adjustment is needed to make it clear that the default values specified for characteristics here only apply to Version Two and may be changed in subsequent versions.
> 
> Have not addressed this in -01 and don't expect to do so in -02.  I believe that this is best addressed as part of merging this with the version-two document.  
> 
> 2) Need to address other questions related to the issue of the relevance of this extension to versions beyond two.
> 
> Feel that this issue will be addressed as part of making this part of the Version Two base protocol.  
> 
> 3) Need to resolve the question about whether backward-direction support is to be REQUIRED in Version Two.
> 
> Am leaving this up to Chuck.  This may affect the need the backwards-direction-support characteristic.

I agree that the REQUIREMENT should prescribe only the _way_ that backward-
direction support is implemented. I have a to-do to revisit this text in
rpcrdma-version-two to ensure it is broad enough to allow a hypothetical
NFSv3-only implementation to not implement any backward-direction support.

> 4) Decision needs to be made about a possible replacement for the word "characteristic".  Also, use of the abbreviation XCHAR.
> 
> Am OK in principle with a replacement but feel there needs to be working group discussion of a possible change.  Am reluctant to make this sort of change more than once.  Feel that this is most likely to be addressed as part of document amalgamation.
> 
> 5) Decision needed on appropriate lengthening of the names of such  types as xchrbsiz and constants such as XCHAR_RBSIZ.
> 
> Will send out a message to the working group to get input.  If useful input received, will incorporate in a -02 or -03.  If that doesn't happen, Chuck and I will address as part of document amalgamation.
> 
> 6) Need to resolve questions about the need for information about the presence of backward-direction chunk support.
> 
> Chuck has made strong case for removing this.  Will think about deleting this in -02.  In any case, if this is to be part of the base Version Two, inevitably, the bar for inclusion will be higher, so if this is still present when the documents are combined, will need to rethink.  Also will be affected by Chuck's decision with regard to Item #3.

To be precise, I'd like to see a justification for including this characteristic
in the initial set. There don't seem to be any ULPs or implementations that need
this signaling at the moment.

Also I don't believe we yet have a thorough understanding of what is needed.
Perhaps that can be hashed out now, but there is an admitted lack of use cases
at this time.

I'm open as to whether this characteristic might be needed later, and I believe
that the current extensibility model in V2 allows the flexibility of waiting.

> 7)Need to clarify whether the treatment of remote-invalidation characteristic should be symmetric as regard to the direction if operation.
> 
> Chuck raised this in his review but I continue to believe this should be symmetric.  If we are not in agreement on this now, need to discuss further on the working group list.

Further discussion needed, IMO:

- If a backward-direction implementation does not support chunks, then Remote
Invalidation symmetry is meaningless. That covers all backward-direction
implementations we have currently.

- A client can't speak for the server's ability to support Remote Invalidation
when acting as a requester. I believe both sides have to indicate their support
independently.

So perhaps the characteristic is not "I support backward-direction RI" but rather
"When I act as a requester, I support RI," and both sides need to send it.

But this is academic until some progress is made on 8. So...

> 8) Need to respond to possible Version Two XDR change with regard to remote invalidation approach, to allow per-request information about the occurrence of invalidation to be returned.
> 
> Waiting for Chuck's decision about whether and how to address this in Version Two.  If this happens before the documents are combined, will updated the remote-invalidaion-support  to reflect this change, if, as expected, it is OPTIONAL.

I'll start a separate thread to begin enumerating design choices.

> Subject: New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt
> URL:            https://www.ietf.org/internet-drafts/draft-dnoveck-nfsv4-rpcrdma-xcharext-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-rpcrdma-xcharext/
> Htmlized:       https://tools.ietf.org/html/draft-dnoveck-nfsv4-rpcrdma-xcharext-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-rpcrdma-xcharext-01
> 
> Abstract:

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sat, 30 Jul 2016 17:42:41 -0400

> Invalidation symmetry is meaningless.

I don't see how the fact that a particular implementation (or set of
implementations) does not have certain support, can make something
"meaningless".

> That covers all backward-direction

I realize that no backward-direction chunk-capable implementations yet
exist.  Still, they are allowed by the protocol.

> when acting as a requester. I believe both sides have to indicate
> their support independently.

> "When I act as a requester, I support RI," and both sides need to

Agree.  That will be reflected in -02.

> But this is academic until some progress is made on 8. So...

But I have to write something about this in -02 and the best choice is to
adopt your suggestion above.

On Sat, Jul 30, 2016 at 10:22 AM, Chuck Lever <[email-masked]>
wrote:

> > 1) Some text adjustment is needed to make it clear that the default
> values specified for characteristics here only apply to Version Two and may
> be changed in subsequent versions.
> >
> > Have not addressed this in -01 and don't expect to do so in -02.  I
> believe that this is best addressed as part of merging this with the
> version-two document.
> >
> > 2) Need to address other questions related to the issue of the relevance
> of this extension to versions beyond two.
> >
> > 5) Decision needed on appropriate lengthening of the names of such
> types as xchrbsiz and constants such as XCHAR_RBSIZ.
> >
> > Will send out a message to the working group to get input.  If useful
> input received, will incorporate in a -02 or -03.  If that doesn't happen,
> Chuck and I will address as part of document amalgamation.
> >
> > 8) Need to respond to possible Version Two XDR change with regard to
> remote invalidation approach, to allow per-request information about the