Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt
Chuck Lever <chuck.lever@oracle.com> Mon, 22 August 2016 18:11 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 6C2A012B02F for <nfsv4@ietfa.amsl.com>; Mon, 22 Aug 2016 11:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.548, 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 MgyqPY8Txr-v for <nfsv4@ietfa.amsl.com>; Mon, 22 Aug 2016 11:11:08 -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 30C46126D74 for <nfsv4@ietf.org>; Mon, 22 Aug 2016 11:11:08 -0700 (PDT)
Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u7MIB6IQ002433 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 18:11:07 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u7MIB6Pc010108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2016 18:11:06 GMT
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u7MIB0lc023779; Mon, 22 Aug 2016 18:11:06 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 22 Aug 2016 11:11:00 -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: <CADaq8jeb6P_1mG9++T=Ff31WBeJi-bD7NqUBQM4GOscxquiDxQ@mail.gmail.com>
Date: Mon, 22 Aug 2016 14:10:59 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E2207C2-EC6D-4C44-9024-56D103563617@oracle.com>
References: <147155138353.27840.7944779905916585881.idtracker@ietfa.amsl.com> <CADaq8jeb6P_1mG9++T=Ff31WBeJi-bD7NqUBQM4GOscxquiDxQ@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/i2AbMDJFuGcsgA6Rtjuafg9O88s>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt
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: Mon, 22 Aug 2016 18:11:11 -0000
Remarks on rpcrdma-xcharext-02. - Credit accounting There's no discussion of RPC-over-RDMA credit accounting in this document. There needs to be some discussion of credit consumption. In particular: Requesters will have to have posted extra receive buffers (over and above credits for forward channel replies and backchannel requests) to deal with XCHAR messages. Likewise, responders will need to post similar extra receives for this purpose. Perhaps both peers should reserve one credit, and the specification should insist that these operations are always single-threaded on a connection. Alternately, when xcharext is merged into rpcrdma-version-two, there might be a generic discussion of non-RPC-payload-bearing messages that could cover this issue. - Overloading the term "initial" Section 3 introduces an "initial set of transport characteristics" and Section 4.1 defines "ROPT_INITXCH: Specify Initial Characteristics". I think the use of "initial" means different things in these two cases? Instead: Section 3 could propose "initially-defined" characteristics. Section 4.1 could define ROPT_STARTXCH (like STARTTLS). I'm not attached to that name, but it probably shouldn't be ROPT_INITXCH if Section 3 defines "initial characteristics". ROPT_CONNXCH ROPT_FIRSTXCH ROPT_EARLYXCH - Section 4.4 The text in this section has been clarified to address previous reviewer comments; thanks! There are a number of syntax and grammatical errors that still need to be addressed (most often, a few words are repeated in some sentences). The "argument structure" of ROPT_UPDXCH is: struct optinfo_updxch { xcharval optupdxch_now; bool optupdxch_pendclr; }; I prefer optupdxch_new instead of optupdxch_now; "_now" suggests this field records a time and/or date stamp. It would help me to understand why a receiver needs to distinguish between these types of notification. For instance, if pendclr is false, this could be either a rejection of a pending change request, or it could be an unsolicited change notification. How does the receiver make use of the difference? Instead of a boolean, an enumeration of update event types would be a little friendlier, and could be expressed in the same amount of space (since an XDR boolean consumes 4 octets on the wire). Based on the discussion in Section 4.4, we have: enum optupdxch_event_type { OPTUPD_UNSOL = 1, OPTUPD_MORE = 2, OPTUPD_DONE = 3, OPTUPD_REJECT = 4, }; But since the rdma_xid field is not used to tie change requests to these change update notifications, I'm not sure why the receiver needs to know that a pending request has been completed. I think REJECT might be more interesting than the difference between UNSOL, DONE, and MORE. There is a bit of a race here: a sender could send an unsolicited update notification at the same time the receiver requests a change of the same xchar. Could that result in a non-deterministic outcome? Would it ever be reasonable to send two or more updates simultaneously for the same XCHAR? (Requiring single-threading here would prevent that from occurring). What if the sender emits two optinfo_updxch messages: both with pendclr set to false, but one with an intermediate value, and one with the original value. The result on the receiver could depend on the order in which these messages arrive. Possibly some text regarding the ordering of these messages is needed. What happens if the receiver of ROPT_REQXCH drops the request? Is there a timeout after which ROPT_REQXCH may be sent again? What happens if an ROPT_RESPXCH is dropped? If ROPT_REQXCH is sent again, the reply is : ROPT_RESPXCH with the requested value marked done ? ROPT_RESPXCH with a rejection (no change was done) ? ROPT_UPDXCH with the requested value and pendclr set to true ? I don't see language that disallows any of these responses. Which one means "I already set this value" ? Sorry if I missed that. Assuming that both sides support ROPT_UPDXCH, can an implementation use ROPT_UPDXCH exclusively instead of ROPT_INITXCH? Assuming that both sides support ROPT_UPDXCH, may a peer change an XCHAR and not send an unsolicited ROPT_UPDXCH? > On Aug 18, 2016, at 4:23 PM, David Noveck <davenoveck@gmail.com> wrote: > > This is updated and it add some vowels (and consonants too) the field and type names. In particular "rq" --> "req". > > I'm aware that some people find "XCHAR" confusing. If someone has an idea for a replacement, please propose it on the list. If the working group is OK with it, I'll produce a -03 incorporating it. > > > ---------- Forwarded message ---------- > From: <internet-drafts@ietf.org> > Date: Thu, Aug 18, 2016 at 4:16 PM > Subject: New Version Notification for draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt > To: David Noveck <davenoveck@gmail.com> > > > > A new version of I-D, draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt > has been successfully submitted by David Noveck and posted to the > IETF repository. > > Name: draft-dnoveck-nfsv4-rpcrdma-xcharext > Revision: 02 > Title: RPC-over-RDMA Extension to Manage Transport Characteristics > Document date: 2016-08-18 > Group: Individual Submission > Pages: 23 > URL: https://www.ietf.org/internet-drafts/draft-dnoveck-nfsv4-rpcrdma-xcharext-02.txt > Status: https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-rpcrdma-xcharext/ > Htmlized: https://tools.ietf.org/html/draft-dnoveck-nfsv4-rpcrdma-xcharext-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-dnoveck-nfsv4-rpcrdma-xcharext-02 > > 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 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 -- Chuck Lever
- Re: [nfsv4] Fwd: New Version Notification for dra… Chuck Lever
- Re: [nfsv4] Fwd: New Version Notification for dra… David Noveck
- Re: [nfsv4] Fwd: New Version Notification for dra… karen deitke
- [nfsv4] Fwd: New Version Notification for draft-d… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… karen deitke
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… karen deitke
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck
- Re: [nfsv4] New Version Notification for draft-dn… Chuck Lever
- Re: [nfsv4] New Version Notification for draft-dn… karen deitke
- Re: [nfsv4] New Version Notification for draft-dn… David Noveck