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

From: David Noveck <[email-masked]>
Date: Sun, 5 Jun 2016 20:21:23 -0400

I've just submitted draft-dnoveck-nfsv4-rpcrdma-rtrext-00 following up on
my earlier I-D draft-dnoveck-nfsv4-rpcrdma-rtissues-00.  Unlike that
earlier informational document, I'm hoping that this (and
draft-dnoveck-nfsv4-rpcrdma-xcharext also) could be the basis for
standards-track working group documents, once we get Version One on its way
and draft-cel-nfsv4-rpcrdma-version-two is turned into a working group
document.

I had originally planned to submit this document closer to the  IETF96
document cutoff (July 7) but I'm doing it now based on the issues that came
up with regard to the recent discussion of the suitability of
rpcrdma-bidirection for various extensions.  Given that these basic ideas
are being discussed without even a tentative public design about how they
might be realized, a lot of the discussion seemed to be taking place in a
vacuum, with people making very different assumptions about the needs these
extensions might have with regard to the underlying infrastructure.   So I
think having a concrete proposal, especially with regard to message
continuation, might help that discussion, as well as being interesting in
its own right.

With regard to packing multiple RPC messages into a single RPC-over-RDMA
transmission, I don't have a concrete proposal to offer right now.  I think
it is less important from a performance point of view than these other
extensions and I'm not working on it right now.  Ironically, an earlier
version of this document did include support for that, but I dropped it
because I was uncomfortable with a document that was over fifty pages.   I
don't want to bring it back right now, but if people are interested in
discussing this option, I could add a few slides about the issues in an
IETF96 talk mainly dealing with the extensions that do have documents
submitted.  People should let me know if they are interested in hearing
about other possible extensions.

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Jun 5, 2016 at 8:13 PM
Subject: New Version Notification for
draft-dnoveck-nfsv4-rpcrdma-rtrext-00.txt
To: David Noveck <[email-masked]>

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

Name:           draft-dnoveck-nfsv4-rpcrdma-rtrext
Revision:       00
Title:          RPC-over-RDMA Extensions to Reduce Internode Round-trips
Document date:  2016-06-05
Group:          Individual Submission
Pages:          38
URL:
https://www.ietf.org/internet-drafts/draft-dnoveck-nfsv4-rpcrdma-rtrext-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-rpcrdma-rtrext/
Htmlized:
https://tools.ietf.org/html/draft-dnoveck-nfsv4-rpcrdma-rtrext-00

Abstract:
   It is expected that the RPC-over-RDMA transport will, at some point,
   allow protocol extensions to be defined.  This would provide for the
   specification of OPTIONAL features allowing participants who
   implement the OPTIONAL features to cooperate as specified by that
   extension, while still interoperating with participants who do not
   support that extension.

   A particular extension is described herein, whose purpose is to
   reduce the latency due to inter-node round-trips needed to effect
   operations which involve direct data placement or which transfer RPC
   messages longer than the fixed inline buffer size limit.

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