Re: [Gen-art] Genart last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06

Chuck Lever <chuck.lever@oracle.com> Tue, 28 January 2020 15:53 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3B21209B3; Tue, 28 Jan 2020 07:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 z_ay9cAZcEQc; Tue, 28 Jan 2020 07:53:00 -0800 (PST)
Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 BA7FC1209B4; Tue, 28 Jan 2020 07:53:00 -0800 (PST)
Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id 00SFYJ8u160175; Tue, 28 Jan 2020 15:52:58 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=8QI2Z/KLCH04Y9ekiOE0JWSnSe3O8WbuMdH8WYQyKgo=; b=n7KnLC2TGaVFDSdkVxQmE/v3UbcQrJu0JtYOYHoYOvtN0tq6IuDz5twWozjysDTESYWp CPVw2u1QcZuFyYN13jUm4M4RB6fmXJm9Z0kGQpGZpQLSmfHyGnOGjEC58ZqMeyHyRaRO JHEKJUi9PBKzcS64hab1PXHokK4rO+WlTtm7R5SQNoQGSJpdXyDrpVEiL4rR7hQYudp9 nVaEfSPqcSmRZVaooN4E3l5UzPzUgch0CZQsV50H1xdpPQmPbGConoq376YcmoIl0blH He2OQn0kChvAJcwO/PRdIVqdZKa2k9t5NLDsmKw5U48QBnAILylcMjXsFq3lSliOiFJF qQ==
Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 2xrdmqf7qh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Jan 2020 15:52:58 +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 00SFYBhY149100; Tue, 28 Jan 2020 15:50:57 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 2xth5h0wp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Jan 2020 15:50:57 +0000
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 00SFouL4002973; Tue, 28 Jan 2020 15:50:56 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 28 Jan 2020 07:50:56 -0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <158015386640.23917.3626035422388212873@ietfa.amsl.com>
Date: Tue, 28 Jan 2020 10:50:54 -0500
Cc: gen-art@ietf.org, draft-ietf-nfsv4-rpcrdma-cm-pvt-data.all@ietf.org, nfsv4@ietf.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <301328AC-ECCC-41FA-A8E5-F81A9A7FDAF9@oracle.com>
References: <158015386640.23917.3626035422388212873@ietfa.amsl.com>
To: Suhas Nandakumar <suhasietf@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9514 signatures=668685
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-1911140001 definitions=main-2001280123
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9514 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-2001280123
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/OnQzmATTLNspGIH18enr6gbDbe0>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2020 15:53:03 -0000

Hi Suhas -

Thanks for your review and comments! My responses are below.


> On Jan 27, 2020, at 2:37 PM, Suhas Nandakumar via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Suhas Nandakumar
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-nfsv4-rpcrdma-cm-pvt-data-??
> Reviewer: Suhas Nandakumar
> Review Date: 2020-01-27
> IETF LC End Date: 2020-01-27
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Thanks for the work. This document is clear in the problem to be
> solved . This document is ready to be published as it-is, however I do have few
> clarification questions for my own understanding
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 1. The draft doesn't specify normative procedures on sender/receiver behavior
> when certain fields are missing (say size of all zeroes). Should the draft say
> recommended procedures for handling these scenarios ?

Section 4 defines the format, which is fixed in size. Section 4.1.1 in
particular mandates the behavior when a perfectly-formed RPC-over-RDMA
private message is not received.

Zero is a permitted value for the size fields. Section 5.2 explains how
to compute the actual buffer size. If those fields contain zero, the
actual send and receive buffer sizes would be 1024 octets.

"Recommended procedures" are scattered about, but IMO the cases are
covered appropriately. If you see one that isn't, or one that could be
made more clear, please let me know.


> 2. Also i didn't see fallback procedures to be followed when the server
> reported size isn't of much use to the sender of the data . In such case the
> sender might decide to go with existing explicit RDMA data transfer operations
> instead of failing the connection ?

If I understand your question, you mean when an RPC message to be
transmitted is larger than the buffer sizes reported in the private
data. Section 3.5 of RFC 8166 explains how the RPC-over-RDMA protocol
handles that situation.

I see the confusion: Section 3.1 of the current document could be more
precise about the risks of exceeding the inline threshold size. The
second paragraph could instead read:

"If an incoming RDMA message exceeds the size of a receiver's inline
threshold, the receive operation fails, and the RDMA provider typically
terminates the connection.  To convey an RPC message larger than a
receiver's inline threshold without risking receive failure, the sender
must use explicit RDMA data transfer operations, which are more expensive
than RDMA Send."


--
Chuck Lever