[Ips] IPS WG Last Call Complete: iSER revisions

[[e-mail]]

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