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

From: Tom Talpey <[email-masked]>
Date: Sun, 1 Mar 2020 09:24:23 -0800

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 <[email-masked]> 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.

---

From: Chuck Lever <[email-masked]>
Date: Sun, 1 Mar 2020 13:13:59 -0500

> On Mar 1, 2020, at 12:24 PM, Tom Talpey <[email-masked]> wrote:
> 

No objection to that phrasing, and that certainly explains why RFC 8166
does not refer directly to RC.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Tue, 3 Mar 2020 09:45:06 -0500

Hello -

> On Mar 1, 2020, at 1:13 PM, Chuck Lever <[email-masked]> wrote:
> 
> 
> 

Because this was directly commented on several times during IESG balloting,
I'm providing an update via this email thread. The new second paragraph of
the Security Considerations section will read:

   On InfiniBand, 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].  iWARP queue pairs have neither
   a datagram nor an unreliable mode, therefore they are always reliable
   connections [RFC5040].  The integrity of CM Private Data and the
   authenticity of its source are ensured by the exclusive use of
   reliable queue pairs.  Any attempt to interfere with or hijack data
   in transit on an RC connection results in the RDMA provider
   terminating the connection.

Also, the IBA reference has been moved back to the Informative References
subsection.

I will request these updates be made to the document during AUTH48, unless
there are objections or further corrections.

--
Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Tue, 3 Mar 2020 20:10:50 -0800

> there are objections or further corrections.

I agree with the changes, but stylistically I might suggest rearranging
the sentences for emphasis and flow, such as:

  The integrity of CM Private Data and the authenticity of its source
  are ensured by the exclusive use of reliable queue pairs. iWARP queue
  pairs are always reliable connections [RFC5040]. On InfiniBand, 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]. Any attempt to interfere with or hijack data
  in transit on a reliable connection in either transport protocol
  results in the RDMA provider terminating the connection.

Just a suggestion!

Tom.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
>

---

From: Chuck Lever <[email-masked]>
Date: Fri, 6 Mar 2020 11:46:56 -0500

> On Mar 3, 2020, at 11:10 PM, Tom Talpey <[email-masked]> wrote:
> 

Agreed, and pushed to my Editor's copy.

--
Chuck Lever