[nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpcrdma-reliable-reply-00.txt

Chuck Lever <chuck.lever@oracle.com> Sun, 14 May 2017 21:42 UTC

From: Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 14 May 2017 17:38:42 -0400
References: <149479670900.2833.465621707339074721.idtracker@ietfa.amsl.com>
To: NFSv4 <nfsv4@ietf.org>
Message-Id: <4217F7CE-A264-4C62-8F2E-0FEDF853D88D@oracle.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/DiMLpKLYSvjDPbcORB2YtiN2M5o>
Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpcrdma-reliable-reply-00.txt
Precedence: list


> Begin forwarded message:
> 
> From: internet-drafts@ietf.org
> Subject: New Version Notification for draft-cel-nfsv4-rpcrdma-reliable-reply-00.txt
> Date: May 14, 2017 at 5:18:29 PM EDT
> To: "Charles Lever" <chuck.lever@oracle.com>, "Chuck Lever" <chuck.lever@oracle.com>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpcrdma-reliable-reply-00.txt
> has been successfully submitted by Charles Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpcrdma-reliable-reply
> Revision:	00
> Title:		Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
> Document date:	2017-05-13
> Group:		Individual Submission
> Pages:		16
> URL:            https://www.ietf.org/internet-drafts/draft-cel-nfsv4-rpcrdma-reliable-reply-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpcrdma-reliable-reply/
> Htmlized:       https://tools.ietf.org/html/draft-cel-nfsv4-rpcrdma-reliable-reply-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpcrdma-reliable-reply-00
> 
> 
> Abstract:
>   RPC transports such as RPC-over-RDMA Version One require reply
>   buffers to be in place before an RPC Call is sent.  However, Upper
>   Layer Protocols sometimes have difficulty estimating the expected
>   maximum size of RPC replies.  This introduces the risk that an RPC
>   Reply message can overrun reply resources provided by the requester,
>   preventing delivery of the message, through no fault of the
>   requester.  This document describes a mechanism that eliminates the
>   need for pre-allocation of reply resources for unpredictably large
>   replies.
> 
> 
> 
> 
> 
> 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

This I-D is intended as a discussion piece for Prague, as Spencer S
suggested, as part of the "NFS/RDMA Next Steps" presentation.

In order to build some consensus on what are the highest priority
issues to address in RPC-over-RDMA, I've written this document,
which itemizes a few areas that could be improved, and proposes a
general mechanism that can address these problems. There are of
course some costs to implementing and using this mechanism.

At this stage I'm most interested in hearing comments on whether
these areas are genuine problems and what kind of priority there
is for addressing them either in RPC-over-RDMA Version Two or in
an extension to it.

Also, I'd like to hear whether this format is appropriate and
valuable for this kind of discussion.

One oddity I noticed was that I submitted this document just now
(after 5pm EDT, May 14, 2017), but the date on the versions
generated by datatracker is May 13, 2017.


--
Chuck Lever

[nfsv4] Fwd: New Version Notification for draft-c… Chuck Lever