Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)

Tom Talpey <> Sun, 01 March 2020 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40C843A097E for <>; Sun, 1 Mar 2020 09:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X5GRdNGbFamz for <>; Sun, 1 Mar 2020 09:24:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F103D3A097C for <>; Sun, 1 Mar 2020 09:24:23 -0800 (PST)
Received: from [] ([]) by :SMTPAUTH: with ESMTPSA id 8SKFj1rSKd1ia8SKFjRsnR; Sun, 01 Mar 2020 10:24:23 -0700
X-CMAE-Analysis: v=2.3 cv=R/R95uZX c=1 sm=1 tr=0 a=VA9wWQeJdn4CMHigaZiKkA==:117 a=VA9wWQeJdn4CMHigaZiKkA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=9_GkQF5BqLnqClYylyYA:9 a=QEXdDO2ut3YA:10 a=mYAOWqAtFUkA:10 a=1dbGxDndw2gA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=pHzHmUro8NiASowvMSCR:22 a=xoEH_sTeL_Rfw54TyV31:22
To: Benjamin Kaduk <>, Chuck Lever <>
Cc:,, The IESG <>,
References: <> <> <>
From: Tom Talpey <>
Message-ID: <>
Date: Sun, 1 Mar 2020 09:24:23 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: =?utf-8?q?MS4wfJ2pkhtyP9jDAoO9ojBMWM75+cQYNF2bkAbUUI6f15aVp?= =?utf-8?q?wq6gf9P2X9NBus3RHSJuPLH7PDGFPPDovDq69S3bAXXbk4zFFhTeWxJ0XEnPcsbQk?= =?utf-8?q?7RDpMs_mf5YkTfvKB07GXgFVv8Kf7Y/ueVdMPDTroU64ud/+AXDbyRKo7fCvrkbJ2?= =?utf-8?q?3e9aLBKtdGmMDoKHaT/N/yW8ZDwI8XDK045iA76btdhCfRbgOFAKuoeGs/iCt3_VT?= =?utf-8?q?rztgp5vm4ICTaoRrzoiZDJKmHU+SJpIxTkaAo7ZMVt6pBEfhlINX/JELHO6NjmuFQ?= =?utf-8?q?a0/WSbL/1+IRDscoAWQj8oaAnVZCUYZn2/Dswpi8=3D?=
Archived-At: <>
Subject: Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Mar 2020 17:24:26 -0000

On 2/20/2020 11:51 AM, Benjamin Kaduk wrote:
> Hi Chuck,
> On Thu, Feb 20, 2020 at 10:13:26AM -0500, Chuck Lever wrote:
>> Hi Ben, thanks for your comments! Responses and questions below.
>>> On Feb 19, 2020, at 8:10 PM, Benjamin Kaduk via Datatracker <> wrote:
>>> Benjamin Kaduk has entered the following ballot position for
>>> draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: No Objection
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> Please refer to
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> The document, along with other ballot positions, can be found here:
>>> Section 6
>>>    The RPC-over-RDMA version 1 protocol framework depends on the
>>>    semantics of the Reliable Connected (RC) queue pair (QP) type, as
>>>    defined in Section 9.7.7 of [IBA].  The integrity of CM Private Data
>>> It's interesting to see such a reference to [IBA], when IIUC the RFC
>>> 8166 protocol is not limited to Infiniband as the underlying transport.
>> Correct, RPC/RDMA can operate on iWARP and RoCE as well. However:
>>   - both of those RDMA fabric types also support RC QPs, and
>>   - [IBA] appears to be the only publication where "RC QP type"
>>     is defined, though I could be wrong.
>> I don't read this text as suggesting that RPC/RDMA cannot operate
>> on those alternate fabrics, but perhaps I am "too close to the
>> code".
> I don't read it that way, either; I was just noting that it was surprising
> that this is the only reference available.  If it is, then it is, though,
> so no need to change anything.

The term "RC" or "Reliable Connected" is an InfiniBand-specific term.
The iWARP protocol has neither a datagram nor unreliable mode, therefore
it is an "RC" transport by definition, in InfiniBand-speak.

I do agree that referring normatively to the IB Architecture is odd,
and perhaps unnecessary. Alternatively, the sentence could be relaxed
to avoid this IB-specific term, and describe the situation in an
informative way. "Supports RC-type Infiniband and iWARP Queue Pairs."

There is a document describing the iWARP consumer-visible semantics,
in 2003's
However, this document was never adopted as an RDDP work item, and
was not developed further. It is nonetheless an excellent reference
and is frequently referred to.