Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-03 review
Chuck Lever <chuck.lever@oracle.com> Fri, 20 May 2016 16:41 UTC
Return-Path: <chuck.lever@oracle.com>
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 8D5FF12DDD6 for <nfsv4@ietfa.amsl.com>; Fri, 20 May 2016 09:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.646
X-Spam-Level:
X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 fBFwAECPRIvy for <nfsv4@ietfa.amsl.com>; Fri, 20 May 2016 09:41:19 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 D31C712DDD5 for <nfsv4@ietf.org>; Fri, 20 May 2016 09:41:18 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4KGfHc4027654 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Fri, 20 May 2016 16:41:18 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u4KGfHX7028127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <nfsv4@ietf.org>; Fri, 20 May 2016 16:41:17 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u4KGfGB3022764 for <nfsv4@ietf.org>; Fri, 20 May 2016 16:41:17 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 20 May 2016 09:41:16 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <6da90b6b-bb58-d241-0d74-dc421358c97c@oracle.com>
Date: Fri, 20 May 2016 12:41:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <9ECFBBD5-9359-46AB-B1CC-7FCBF06C40A8@oracle.com>
References: <6da90b6b-bb58-d241-0d74-dc421358c97c@oracle.com>
To: Karen <karen.deitke@oracle.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/VeZhhf-6mnT6zfgwjmSJd8fggIo>
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-03 review
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 20 May 2016 16:41:20 -0000
Hi Karen- Thanks for the review. I'll respond below to questions and non-editorial comments. I'll merge the other comments before the next revision. > On May 20, 2016, at 12:11 PM, Karen <karen.deitke@oracle.com> wrote: > > Hi Chuck, > > Here is some feedback on draft-ietf-nfsv4-rpcrdma-bidirection-03 > Karen > > > Abstract section: > > The use of the word "recent" seems relative to time. 5 years later, recent will no longer be recent. Not sure how much of a big deal this is, just seems maybe instead of putting "recent minor versions of NFSv4", a more precise explanation would be "With the introduction of NFSv4.0". > > > 2.1 > > "This traditional form of ONC RPC message passing is referred to as operation in the "forward direction"." > > "as operation in the forward direction" seems awkward. "is referred to as the "forward direction"." seems a bit more concise and clearer. > 2.2 > Same as in section 2.2 in "This form of message passin is referred to as operation in the "backward direction." > > Also again the use of the word recently, as in "Not until recently", seems that "Not until NFSV4.0" would be clearer. > > 3.1 > "An NFSv4 "delegation" is simply a promise made by a server that it will notify a client before another agent is allowed access to a file" > > another agent? seems "a different client" would be clearer. A server may also host application programs, which can open files too. When a local application opens a file delegated to a client, the server would recall that delegation. So "agent" means other clients, or programs running on the server. > 3.2 > > "Without a backward direction RPC-over-RDMA capability, an NFSv4.1 client must additionally connect using a transport with backward direction capability to use as a backchannel." > > I understand the point, and agree, but the sentence seems mumbled. Maybe its confusing to me because of the use of the word backward direction. Maybe backward direction needs to be defined as a connection that is initiated by a requestor, but also used to accept requests from the respondor, in which the requestor then reponds? Not sure if that wording is any clearer, but the idea that the requests are sent from the side that did not create the connection? Isn't the definition in section 2.2 sufficient? > 4 > > "For an RDMA Send operation to work, the receiving peer must have posted an RDMA Receive Work Request (WR) to provide a receive buffer in which to land the incoming message. > > why is the posted receive buffer being called a posted receive work request? Seems this would be clearer > "For an RDMA Send operation to work, the receiving peer must have posted an RDMA receive buffer as the location in which the RDMA send request will land." Each receive buffer is posted by posting a Receive Work Request on the QP's receive queue. "Posting a receive buffer" is a more colloquial way of saying it, posting a Receive Work Request is perhaps more precise. An argument could be made for switching to one terminology or the other throughout the document. But which one is more clear? Opinions? > And similarly > > > "If a receiver hasn't posted enough Receive WRs to land incoming Send operations..." > > If a receiver hasn't posted enough receive buffers to accept incoming send requests" > > (Why is Receive capitalized?) > > > 4.1 > > "When message direction is not fully determined by context" > > "fully determined by context" thats confusing, what does that really mean? I think this means when the rdma header does not directly indicate if the message is a call or reply, but the wording is confusing. That means that in some cases the receiver can guess accurately which direction the message was going, based on the context of the operation, even without having an RPC message payload. I'm open to suggestions. I think some prefer that the document simply state that direction is always unknown in cases where an RPC message payload is not present. That kind of opens a can of worms with RDMA_ERROR, which is needed to report that the client does not support backward direction operation. > 4.2 > > "If a sender transmits a message for a receiver which has no prepared receive buffer" > > the word "posted" not "prepared" was used earlier, to be consisted "posted" would read more clearly than "prepared" > > 4.2.2 > "A forward direction RPC-over-RDMA service endpoint" > > > did you mean "server" instead of "service"? > > "To receive incoming backward direction replies, an RPC-over-RDMA server endpoint must pre-post a receive buffer for each backward direction Call it sends" > > What prevents a buggy, or hacking client from sending more requests that forward credits and preventing a reply in the backward direction from arriving? Could a buggy or hacky client cause a denial of service by sending more than credit number of requests? Guess that could happen in the standard single direction and would result in the connection closing. Maybe not an issue? The same issue exists in the forward direction. > 5.1 > > last sentence, "and the header's msg_type field MUST conatin the value CALL", > > for more clarification "and the RPC header's msg_type field", this is a nit... > > 5.4 > > "If an ONC RPC client has no work to do, it may be some time before it re-establishes a transport connection. Backward direction Requesters must be prepared to wait indefinitely for a connection to be established before a pending backward direction ONC RPC Call can be retransmitted." > > I don't believe there are currently an non-idempotent backchannel operations, but if there ever were to be, seems that the client should detect if it has any drc replies and re-create the bi-directional, or even one way backchannel connection, right after it detects the connection is gone. Does backward direction RPC/TCP do this? It certainly would be an issue for a backward-only connection. The client would have to notice that the connection was down and re-establish it quickly. > Not addressed, and obvious to the implementer, but should it be mentioned that send buffers in the backward direction MUST be the same size as the posted receive buffers on the receiving side? That is the backward connection must use the same send/recv buffer sizes and this can not be negotiated? Well, the I-D used to say that the buffer sizes are the same in both direction, but I guess I chopped it out at some point. I'll have to go back and look for it. -- Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-03 r… Karen
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Karen
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Karen
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Spencer Shepler
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… David Noveck
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Chuck Lever
- Re: [nfsv4] draft-ietf-nfsv4-rpcrdma-bidirection-… Spencer Shepler