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

Tom Talpey <tom@talpey.com> Sun, 01 March 2020 17:24 UTC

Return-Path: <tom@talpey.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 40C843A097E for <nfsv4@ietfa.amsl.com>; Sun, 1 Mar 2020 09:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5GRdNGbFamz for <nfsv4@ietfa.amsl.com>; Sun, 1 Mar 2020 09:24:24 -0800 (PST)
Received: from p3plsmtpa12-09.prod.phx3.secureserver.net (p3plsmtpa12-09.prod.phx3.secureserver.net [68.178.252.238]) (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 F103D3A097C for <nfsv4@ietf.org>; Sun, 1 Mar 2020 09:24:23 -0800 (PST)
Received: from [172.20.1.219] ([50.235.29.75]) 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
X-SECURESERVER-ACCT: tom@talpey.com
To: Benjamin Kaduk <kaduk@mit.edu>, Chuck Lever <chuck.lever@oracle.com>
Cc: nfsv4-chairs@ietf.org, nfsv4@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-rpcrdma-cm-pvt-data@ietf.org
References: <158216101788.17661.6926758160404035704.idtracker@ietfa.amsl.com> <E718C1B8-B96B-4A64-8B92-C4ABEC7B5E5F@oracle.com> <20200220195155.GJ97652@kduck.mit.edu>
From: Tom Talpey <tom@talpey.com>
Message-ID: <e74002a7-e1f1-a738-20d4-fa7d3395dd66@talpey.com>
Date: Sun, 01 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: <20200220195155.GJ97652@kduck.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfJ2pkhtyP9jDAoO9ojBMWM75+cQYNF2bkAbUUI6f15aVpwq6gf9P2X9NBus3RHSJuPLH7PDGFPPDovDq69S3bAXXbk4zFFhTeWxJ0XEnPcsbQk7RDpMs mf5YkTfvKB07GXgFVv8Kf7Y/ueVdMPDTroU64ud/+AXDbyRKo7fCvrkbJ23e9aLBKtdGmMDoKHaT/N/yW8ZDwI8XDK045iA76btdhCfRbgOFAKuoeGs/iCt3 VTrztgp5vm4ICTaoRrzoiZDJKmHU+SJpIxTkaAo7ZMVt6pBEfhlINX/JELHO6NjmuFQa0/WSbL/1+IRDscoAWQj8oaAnVZCUYZn2/Dswpi8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/FRC8GtdByufnTJBOyUZHKLRc22o>
Subject: Re: [nfsv4] Benjamin Kaduk's No Objection on draft-ietf-nfsv4-rpcrdma-cm-pvt-data-07: (with 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: 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 <noreply@ietf.org> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data/
>>>
>>>...
>>> 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 https://tools.ietf.org/html/draft-hilland-rddp-verbs-00
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.

Tom.