Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with DISCUSS and COMMENT)

Chuck Lever <chuck.lever@oracle.com> Thu, 13 February 2020 15:02 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 4B834120013; Thu, 13 Feb 2020 07:02:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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, 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 vaXygVVIGTvE; Thu, 13 Feb 2020 07:02:17 -0800 (PST)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 8F803120122; Thu, 13 Feb 2020 07:02:17 -0800 (PST)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01DEwYrZ026197; Thu, 13 Feb 2020 15:02:12 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-2020-01-29; bh=wTuk+wWkA/wI9CcgV1mbjYtYGjB0p2AR7Dwk3a9f/gM=; b=hhc2jjqGvMDrdVvOd65g/9iStE5p4mcM5RVTVzyym6hnDywfIJhnxwHydCKp0ggdmc6v ByT9gfG7XCHdHb4wTKumwXFBBGTrL3uXK4Nmz65NOv0y5m7cM9t6+zSzdq0cTC35oPTw O2lnyogd67S6eK+HBda5aOA+ST9y/vQr44WQ8QLjqv0zRUtqofy27XqsSRDKkMexm+mf EJWVqzr+89O3NyfAiN6vGUOkte6rLIoz7eLcB3dj/ApsFYEvwF3/SxqNq5Uz+7yF2Zlh jVc46a8FlPye2AXOGe7WEGM5Y7L3mVNzaq06mFNjR5t77zxDaa5PTuyYPC3pmwTE9h+S bw==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2y2k88jhcu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 13 Feb 2020 15:02:10 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 01DEvU6R168732; Thu, 13 Feb 2020 15:02:09 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2y4k36q67r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 13 Feb 2020 15:02:07 +0000
Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 01DF26ii028278; Thu, 13 Feb 2020 15:02:06 GMT
Received: from anon-dhcp-152.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 13 Feb 2020 07:02:06 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CALaySJL_0ui2LD9JXjGxdP1OazwiqNr=wwBm+=q9Fb0QEbcp2A@mail.gmail.com>
Date: Thu, 13 Feb 2020 10:02:05 -0500
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org, Tom Haynes <loghyr@gmail.com>, Spencer Shepler <spencer.shepler@gmail.com>, Brian Pawlowski <beepee@gmail.com>, nfsv4-chairs@ietf.org, NFSv4 <nfsv4@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E146C19F-BAC2-4E63-8F6C-9EB9B70B5867@oracle.com>
References: <158157273498.18108.1561637139623742133.idtracker@ietfa.amsl.com> <7EE70561-C534-4C7B-B3A3-D7C3B3542D1E@oracle.com> <CALaySJL_0ui2LD9JXjGxdP1OazwiqNr=wwBm+=q9Fb0QEbcp2A@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9529 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=991 adultscore=0 bulkscore=0 malwarescore=0 phishscore=0 suspectscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130119
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9529 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 impostorscore=0 clxscore=1015 spamscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002130119
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/sD_bHa_3xx7mPFEvO5e4DR7Quj0>
Subject: Re: [nfsv4] Barry Leiba's Discuss on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with DISCUSS and COMMENT)
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: Thu, 13 Feb 2020 15:02:19 -0000


> On Feb 13, 2020, at 9:30 AM, Barry Leiba <barryleiba@computer.org> wrote:
> 
> Hi, Chuck, and thanks for the quick response.
> 
>>> — Section 5.2 —
>>> 
>>>  A sender computes the encoded
>>>  value by dividing the buffer size, in octets, by 1024 and subtracting
>>>  one from the result.
>>> 
>>> Is the buffer size necessarily a multiple of 1024?  If so, where is that
>>> specified?  If not, what is the encoded value when the buffer size is, say,
>>> 2000?  Is it zero?  Or one?
>> 
>> Good catch! Buffer sizes are not constrained to 1024-byte length alignment.
>> 
>> Further, if a sender posts, say, a 2032-byte message to a receiver that uses
>> a 2000-byte buffer, a Receive error occurs that typically results in
>> connection loss.
>> 
>> IMO Section 5.2 should instruct the sender to round the actual buffer length
>> down to the nearest 1024-byte multiple before encoding. Would that clarify
>> the issue for you?
> 
> Yes, that would be quite clear.

Looking at Section 5.2 now, it appears that the encoding computation performs
the rounding implicitly. IMO instructing that the sender rounds down first
would be redundant. Here's what I've come up with instead:

   Inline threshold sizes from 1KB to 256KB can be represented in the
   Send Size and Receive Size fields.  These inline threshold values
   provide a pair of 1024-octet-aligned maximum message lengths that
   guarantee Send and Receive operations do not fail due to length
   errors.

   A sender computes the encoded value by dividing its actual buffer
   size, in octets, by 1024 and subtracting one from the result.  A
   receiver decodes this value by performing the inverse set of
   operations: it adds one to the encoded value and then multiplies that
   result by 1024.

   The client uses the smaller of its own send size and the server's
   reported receive size as the client-to-server inline threshold.  The
   server uses the smaller of its own send size and the clients's
   reported receive size as the server-to-client inline threshold.


Perhaps not as clear as one could hope. Comments/suggestions are welcome.


--
Chuck Lever