Re: [Ips] IPS WG Last Call Complete: iSER revisions

["Mallikarjun C." <[e-mail]>]

 > While the acronym RCP for RDMA-Capable Protocol is correct, it
 > detracts from readability.  A lot of people will initially
 > mis-read it as the Unix remote copy utility (e.g., see item 6. in
 > Section 2.2, Architectural Goals).  The generic term "RDMA" should
 > be substituted for "RCP" in phrases such as "RDMA functionality",
 > "RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
 > the RCP acronym, or at least greatly reduce its use.

I suggest considering "RCAP" as an alterantive in that case.

I have some concern with a generic "RDMA" substitution because such a 
usage doesn't distinguish the "iSER-required" (as defined in section 
4.1) RCAP protocol stack from the general RDMA concept.  And "RDMA" 
itself is a sufficiently general term that doesn't lend itself to 
redefinition in the iSER draft.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


[e-mail] wrote:
> First of all, this message announces the conclusion of the WG Last
> Call on the iSER changes to support non-iWARP RDMA transports,
> such as InfiniBand.  I have a number of editorial changes below
> that will require further editing, but not another WG Last Call.
> 
> Also, the proposed editing changes to iSER introduced some
> technical changes:
> - RDMA Read after an RDMA Write on the same stream must be
> 	strictly ordered by the RDMA protocol.  (Section 4.1,
> 	3rd item)
> - Generalization of login phase description to allow use of
> 	a non-byte-stream messaging protocol. (Section 4.1, next
> 	to last item, and a few other places).
> - Failure to negotiate iSER may cause connection close in
> 	order to restart traditional iSCSI over TCP/IP (Section
> 	5.1, end of 2nd paragraph).
> While I believe all of these changes have been discussed in
> the past, for process purposes, as WG chair, I believe that
> it is the rough consensus of the IP Storage WG that these
> technical changes should be made to the iSER draft.  See:
> http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iser-05_candidate.txt
> 
> Anyone who disagrees needs to post to the list ASAP with a
> technical rationale for their disagreement.
> 
> On to the editorial changes that are needed:
> 
> -- (1) Motivation text has a gap --
> 
> The generalization of the iSER text to support InfiniBand
> has exposed a problem in the Motivation section (2.1) of
> the iSER draft - the discussion jumps from SNIC to generic
> RDMA capable controller without explaining why.  To address
> this, the following text:
> 
>    With these defined techniques in [RFC3720], a Network Interface
>    Controller customized for iSCSI (SNIC) could offload the TCP/IP
>    processing and support direct data placement.
> 
>    Supporting direct data placement is the main function of an
>    RDMA Capable Protocol (RCP).
> 
> should be changed to:
> 
>    With these defined techniques in [RFC3720], a Network Interface
>    Controller customized for iSCSI (SNIC) could offload the TCP/IP
>    processing and support direct data placement, but most iSCSI
>    implementations do not support iSCSI "markers", making SNIC
>    marker-based direct data placement unusable in practice.
> 
>    The iWARP protocol stack provides direct data placement functionality
>    that is usable in practice, and in addition, there is also interest
>    in using iSCSI with other RDMA protocol stacks that support direct
>    data placement, such as the one provided by InfiniBand.  The generic
>    term RDMA-Capable Protocol is used to refer to the RDMA functionality
>    provided by such protocol stacks.
> 
> -- (2) RCP acronym is a problem --
> 
> While the acronym RCP for RDMA-Capable Protocol is correct, it
> detracts from readability.  A lot of people will initially
> mis-read it as the Unix remote copy utility (e.g., see item 6. in
> Section 2.2, Architectural Goals).  The generic term "RDMA" should
> be substituted for "RCP" in phrases such as "RDMA functionality",
> "RDMA messages", "RDMA services", "RDMA layer" etc. to eliminate
> the RCP acronym, or at least greatly reduce its use.
> 
> -- (3) RDMA Capable Protocol needs to be generic ---
> 
> There are several issues here, all of which revolve around the fact
> that RDMA Capable Protocols are not specified by iSER, and the iSER
> draft needs to accommodate new ones that haven't been designed, yet.
> 
> - Section 2.3, item 6.  Change "RCP guarantees data integrity." to
> "The RCP MUST ensure data integrity." or "The RCP is responsible for
> ensuring data integrity."  This draft does not specify any RCP.
> 
> Section 5.1, top of p.33.  Same problem: "RCP provides error detection
> based on 32-bit CRC for all iSER Messages."  This needs to be generalized
> to say that the RCP MUST or is responsible for providing error detection
> that is at least as good as a 32-bit CRC.
> 
> RCP or whatever wording replaces it needs to be generic - go over the
> draft and pretend that there was an RDMA over carrier pigeon protocol
> and make sure that none of the wording would need to change to support
> trying to run iSER over that ... well, maybe not RDMA over carrier pigeon,
> but perhaps something like RDMA over MPEG (not as ridiculous as it
> sounds, as MPEG is the link format for some satellite links).
> 
> -- (4) Other minor stuff --
> 
> The text describing InfiniBand seems to be ok, even the use of
> InfiniBand in Figure 1.  Section 14.4 comes closest to the line,
> but it's probably ok.
> 
> Section 7.3.9 needs to explain the else case for "If the underlying
> transport is TCP,"  The byte-stream requirement is applicable only
> to TCP, but the location of this phrase at the start of this section
> could make the entire paragraph or section applicable only to TCP.
> The other places that use this phrasing don't appear to have analogous
> problems, but should be double-checked.
> 
> Delete the [VERBS] reference, as that draft has expired and will
> not become an RFC.  If that's not acceptable, reference an RDMAC
> verbs draft in a publicly available place.
> 
> -- Next Step --
> 
> The iSER authors should prepare and submit a -05 draft in accordance
> with the above guidance (including the rough consensus of the RDDP WG
> on the technical changes).  Please make sure the draft passes the
> draft checker at http://tools.ietf.org/tools/idnits/idnits.pyht
> before submitting.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 
> _______________________________________________
> Ips mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips