Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)

Chuck Lever <chuck.lever@oracle.com> Tue, 11 June 2019 19:21 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 D3422120143 for <nfsv4@ietfa.amsl.com>; Tue, 11 Jun 2019 12:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com
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 5TQvflWBmkut for <nfsv4@ietfa.amsl.com>; Tue, 11 Jun 2019 12:20:57 -0700 (PDT)
Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 E24B0120176 for <nfsv4@ietf.org>; Tue, 11 Jun 2019 12:20:47 -0700 (PDT)
Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5BJE5kN147703 for <nfsv4@ietf.org>; Tue, 11 Jun 2019 19:20:46 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : content-type : content-transfer-encoding : mime-version : subject : date : references : to : in-reply-to : message-id; s=corp-2018-07-02; bh=9RUXtmGT2sURp1FtaRlZQOpL3VmnGo3Gg4R1+XimgpE=; b=VFKaOFrOdH5cWP/jWX4Xxi+74XjCby982fprK3OTIYOevVkz7lescSCUL5AaNxO7B2Bw LyS0AhF0sJ7B7IhO3lynrDxKS3xWsmGii5HBCBrFeIxV4f1Z6BhFP1ucCFuZlt17FIh1 k/xA0Ia2nvUoi5ZFE2ohzrhdkr0NSpqJ4fDllrkWUrKSfm4rUiya2iDbhXJVXhymmn2x OVRIDk5LF1hLxOs2v9ZsPoHwuJejE2hEiCG9s197/XiNOoKhPXlFgLovLh0Y/xv6kDnP exlNKSDHimd708UubQTOV0NLHoTp4OdxD09D65B1kVJ80cGjL30gYSAjze01feN6ELHs Jg==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 2t02heqd4x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Tue, 11 Jun 2019 19:20:45 +0000
Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x5BJJHTx090962 for <nfsv4@ietf.org>; Tue, 11 Jun 2019 19:20:45 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 2t024uk0wj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <nfsv4@ietf.org>; Tue, 11 Jun 2019 19:20:45 +0000
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x5BJKixJ025702 for <nfsv4@ietf.org>; Tue, 11 Jun 2019 19:20:44 GMT
Received: from anon-dhcp-171.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Jun 2019 12:20:43 -0700
From: Chuck Lever <chuck.lever@oracle.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 11 Jun 2019 15:20:42 -0400
References: <CAFt6BanN_L9EyLyf3Hfpd1nBHaRNh5-jppcXNEGugCfiFvOKww@mail.gmail.com> <3d25b43c-cbb7-1681-e647-fc4b3c6ba0ba@talpey.com>
To: NFSv4 <nfsv4@ietf.org>
In-Reply-To: <3d25b43c-cbb7-1681-e647-fc4b3c6ba0ba@talpey.com>
Message-Id: <90FF728D-F043-4CB5-B3D8-D30FB5B95B6B@oracle.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9284 signatures=668687
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906110123
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9284 signatures=668687
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906110123
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/rjvuUOfACJOCqxrUuC4LT3Xz8wc>
Subject: Re: [nfsv4] WG last call for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-02.txt (Ends May 31st)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 11 Jun 2019 19:21:02 -0000

At this point WGLC closed over a week ago, so I will assume
that there are no further pending comments on this document.
As soon as Tom is satisfied that his comments have been
addressed, I will submit the updated draft as

  draft-ietf-nfsv4-rpcrdma-cm-pvt-data-03

and it can proceed to the next step.

Tom- Thanks for your review!

I propose the following changes below to address your
comments. Feel free to follow up if you have additional
concerns.


> On May 30, 2019, at 2:30 PM, Tom Talpey <tom@talpey.com> wrote:
> 
> On 5/6/2019 12:46 PM, spencer shepler wrote:
>> All,
>> Thanks to Chuck, we have the following I-D entering working group last call.
>> “RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1”
>> We will start the review today and end on May 31^st .
>> The source of the I-D can be found here and comments should be sent to the WG alias.
>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
> 
> I have some comments on final review.
> 
> In the Abstract, it should be stated that the addition of the
> private data payload specified in the draft is an optional
> extension, and that the rpcrdmav1 protocol does not require it.

I plan to add the following two sentences to the end
of the Abstract:

NEW TEXT:

The addition of the private data payload specified in this
document is an OPTIONAL extension. The RPC-over-RDMA version
1 protocol does not require the payload to be present.


> In the Introduction final paragraph the statement "The message
> format can be extended as needed" is perhaps overly broad. I think
> the better way to state what is meant here is that the specification
> is intended to be further extensible, within the normal scope of
> such IETF work, and it defines an IANA registry for this. A forward
> reference to section 5 would help.

In the last paragraph of the Introduction:

OLD TEXT:

The message format can be extended as needed.

REPLACEMENT TEXT:

The message format is intended to be further extensible
within the normal scope of such IETF work (see Section 5 for
further details). Section 6 of the current document defines
an IANA registry for this purpose.


> In section 3.2 third paragraph two comments. First, it describes an
> advantage of avoiding a context switch. This is a local implementation
> matter, and not really something the protocol can or cannot proscribe.
> It would be state the benefit in protocol terms, such as "avoids
> processing of the invalidate completion", then go on to say which may
> enable avoiding interrupt(s) and context switch(es). Second, a nit - the
> word "upshot" is slang. Suggest "benefit".

I plan to replace the third paragraph of Section 3.2:

OLD TEXT:

An RPC-over-RDMA responder can use remote invalidation
when replying to an RPC request that provided Read or
Write chunks. The requester thus avoids dispatching an
extra Work Request, the resulting context switch, and
the invalidation completion interrupt as part of
completing an RPC transaction that uses chunks. The
upshot is faster completion of RPC transactions that
involve RDMA data transfer.

REPLACEMENT TEXT:

An RPC-over-RDMA responder can use remote invalidation
when replying to an RPC request that provided chunks.
The requester thus avoids processing an invalidation
completion for that chunk. The benefit is faster
completion of RPC transactions that involve RDMA data
transfer.


> At the end of section 3.2, the final paragraph is quite mysterious. It
> refers to "a simple signaling mechanism" and "some NFS/RDMA client".
> Really, something more needs to be said here. If this signaling
> mechanism involves a protocol payload, then definitely so. Can you
> elaborate? I admit I don't fully understand what is meant here.

I plan to replace the final paragraph of Section 3.2:

OLD TEXT:

However, it is possible to provide a simple signaling mechanism
for a requester to indicate it can deal with remote invalidation
of any STag it has presented to a responder.
There are some NFS/RDMA client implementations that
can successfully make use of such a signaling mechanism.

REPLACEMENT TEXT:

There are some NFS/RDMA client implementations whose STags
are always safe to invalidate remotely.
For such clients, indicating to the responder that remote
invalidation is always safe can allow such invalidation
without the need for more complex communication between the
requester and responder.


> In section 4, the scope of the properties are correctly confined to
> the connection on which they are exchanged. But, this does not mention
> the visibility of the properties to the upper layer consumer, which
> must be aware of them, especially when reconnecting since RDMA behaviors
> may change. I suggest a short statement in sectin 4.1 Interoperability
> Considerations to this point.

In fact these properties are not visible to the upper layer
consumer (if by "ULP consumer" you mean RPC). However, if you
mean the RPC/RDMA transport implementation, yes, it does
have to be prepared for those settings to change after a
reconnect. I've inserted a sentence at the end of the second
paragraph of Section 4 to clarify this:

OLD TEXT:

The transport properties exchanged via this mechanism are
fixed for the life of the connection. Each new connection
presents an opportunity for a fresh exchange.

REPLACEMENT TEXT:

The transport properties exchanged via this mechanism are
fixed fo the life of the connection. Each new connection
presents an opportunity for a fresh exchange. An
implementation of the extension described in this document
MUST be prepared for the settings to change upon a
reconnection.


> In section 7, the vulnerability is in the RDMA-CM protocol, not this
> protocol. And, private data is carried differently by different lower
> layers - for example in the IETF iWARP family, it's part of MPA.
> Honestly, I'm not sure this is relevant to this document. It basically
> inherits all the considerations of the protocols it extends.

I've replaced the entirety of the Security Considerations
section as follows:

OLD TEXT:

RDMA-CM Private Data typically traverses the link layer in
the clear. A man-in-the-middle attack could alter the
settings exchanged at connect time such that one or both
peers might perform operations that result in premature
termination of the connection.

REPLACEMENT TEXT:

The private data extension specified in this document
inherits the security considerations of the link layer
protocols it extends (e.g., the RDMA-CM protocol).


> Tom.


--
Chuck Lever