Subject: [Ips] AD review of draft-ietf-ips-iwarp-da

From: Lars Eggert <[email-masked]>
Date: Thu, 12 Oct 2006 16:53:11 +0900

Hi,

please find the AD review of draft-ietf-ips-iwarp-da-03.txt below. In  
a nutshell: No major issues but a number of comments and nits that  
might best be handled by a new revision before IESG review.

Lars

---<snip>---

   Has idnits (unused references, tabs, non-ASCII characters, etc.) and
   boilerplate issues (some due to boilerplate changes during the
   too-long AD review - mea culpa).

   Document talks about the "Datmover protocol" as a wire protocol in
   some places and in others it says the opposite (that it isn't a wire
   protocol) - this is confusing.

Section 2.1, paragraph 1:
 >         There are new industry and standards initiatives to develop
 >         Remote Direct Memory Access (RDMA) and Remote Direct Data
 >         Placement (RDDP) technologies to work over IP fabrics.  The
 >         principal value proposition of these technologies is that
 >         they enable one end node to place data in the final intended
 >         buffer on the remote end node, thus eliminating the data copy
 >         that traditionally happens in the receive path to move the
 >         data to the final buffer.  The data copy avoidance in turn
 >         eliminates unnecessary memory bandwidth consumption, substan-
 >         tially decreases the reassembly buffer size requirements, and
 >         preserves CPU cycles that would otherwise be spent in
 >         copying.

   Paragraph probably needs to be updated to reflect recent history  
(RDMA
   done, not proposed anymore).

Section 2.2, paragraph 2:
 >           a)      Provide guidance to Datamover protocol designers
 >                   with respect to the functional boundary between
 >                   iSCSI and the Datamover protocols.  This  
guidance is
 >                   critical since a significant part of the [RFC3720]
 >                   protocol definition is left unchanged by this
 >                   Architecture and the iSCSI notions from [RFC3720]
 >                   (e.g., tasks, ITTFrom [email-masked] Thu Oct 12 11:31:29 2006
To: [email-masked]
From: Lars Eggert <[email-masked]>
Date: Thu, 12 Oct 2006 16:53:11 +0900
Cc: [email-masked], [email-masked]
Subject: [Ips] AD review of draft-ietf-ips-iwarp-da

Hi,

please find the AD review of draft-ietf-ips-iwarp-da-03.txt below. In  
a nutshell: No major issues but a number of comments and nits that  
might best be handled by a new revision before IESG review.

Lars

---<snip>---

   Has idnits (unused references, tabs, non-ASCII characters, etc.) and
   boilerplate issues (some due to boilerplate changes during the
   too-long AD review - mea culpa).

   Document talks about the "Datmover protocol" as a wire protocol in
   some places and in others it says the opposite (that it isn't a wire
   protocol) - this is confusing.

Section 2.1, paragraph 1:
 >         There are new industry and standards initiatives to develop
 >         Remote Direct Memory Access (RDMA) and Remote Direct Data
 >         Placement (RDDP) technologies to work over IP fabrics.  The
 >         principal value proposition of these technologies is that
 >         they enable one end node to place data in the final intended
 >         buffer on the remote end node, thus eliminating the data copy
 >         that traditionally happens in the receive path to move the
 >         data to the final buffer.  The data copy avoidance in turn
 >         eliminates unnecessary memory bandwidth consumption, substan-
 >         tially decreases the reassembly buffer size requirements, and
 >         preserves CPU cycles that would otherwise be spent in
 >         copying.

   Paragraph probably needs to be updated to reflect recent history  
(RDMA
   done, not proposed anymore).

Section 2.2, paragraph 2:
 >           a)      Provide guidance to Datamover protocol designers
 >                   with respect to the functional boundary between
 >                   iSCSI and the Datamover protocols.  This  
guidance is
 >                   critical since a significant part of the [RFC3720]
 >                   protocol definition is left unchanged by this
 >                   Architecture and the iSCSI notions from [RFC3720]
 >                   (e.g., tasks, ITTs) are leveraged by the Datamover
 >                   protocol.

   Nit: would not capitalize "architecture" here (and later)

Section 3, paragraph 1:
 >         Figure 1 illustrates an example of the architectural layering
 >         of iSCSI and Datamover layers, in conjunction with a TCP/IP
 >         implementation of RDMAP/DDP layers in an iSCSI end node.
 >         Note that RDMAP/DDP/MPA, and TCP protocol layers are shown
 >         here only as an example and in reality, DA is completely
 >         oblivious to protocol layers below the Datamover layer.

   Might want to point out that RDMA over SCTP also exists (and cite
   corresponding ID).

Section 5.4, paragraph 3:
 >         shared memory etc.) is really upto the implementations.

   Nit: s/upto/up to/

Section 5.5, paragraph 1:
 >         The term "Transport Connection" is used in this document as a
 >         generic term to represent the end-to-end logical connection
 >         as defined by the underlying reliable transport protocol.
 >         For this revision of this document, a Transport Connection
 >         means only a TCP connection.

   What about RDMA over SCTP? Or, rather, isn't the Transport Connection
   an RDMAP connection and hence independent of TCP or SCTP anyway?

Section 9.2, paragraph 4:
 >         A target iSCSI layer being notified of the arrival of TCP
 >         RESET is an example of when the Connection_Terminate_Notify
 >         Operational Primitive is invoked.

   RDMAP RESET? TCP events should be hidden.

Section 12, paragraph 1:
 >         If a well-known port is chosen as the mechanism to identify a
 >         Datamover protocol on TCP, the well-known port must be
 >         registered with IANA.  Because the use of the well-known port
 >         is specific to the Datamover protocol in such a case, the
 >         resulting IANA considerations from such use must be specified
 >         by the specific Datamover protocol.  DA itself does not have
 >         any specific IANA considerations.

   Datamover protocol sits on top of RDMAP and would need to be
   registered in an IANA registry there, rather that with a TCP port
   number.

Section 15, paragraph 2:
 >         In addition, the following individuals had reviewed and
 >         contributed to the improvement of this document.  The authors
 >         are grateful for their contribution.

   Some of these are also listed as authors.

Section 16.1, paragraph 1:
 >         This section discusses the specific considerations for RDMA-
 >         based and RDDP-based Datamover protocols.

   Shouldn't this section move to the iSER draft?

-- 
Lars Eggert                                     NEC Network Laboratories

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

---

From: [email-masked]
Date: Thu, 12 Oct 2006 15:45:48 -0400

IPS WG and DA draft authors,

We definitely need a new version of this draft, as there appear to

>    too-long AD review - mea culpa).

Make sure the new version passes the ID Nits checker at:
	http://tools.ietf.org/tools/idnits/
*before* submitting.  That checker keeps getting upgraded, so it'll
probably find some things that it wasn't looking for in mid-2005.

>    Document talks about the "Datamover protocol" as a wire protocol in

This needs some careful attention, as the problem starts in the
Abstract:

     The new Datamover protocol provides a 
     reliable transport for all iSCSI PDUs,

A Datamover protocol for iSCSI is one that satisfies the requirements
of the Datamover architecture described in this draft - iSER is the
first
example.

I've called attention to significant things that Lars found below -
things
I don't mention should just be done.

>    Might want to point out that RDMA over SCTP also exists (and cite

Unfortunately, iSCSI over SCTP doesn't exist at this point in time, so
implying that there is iSCSI datamover support over SCTP would be wrong.
This is a reason to not point out RDMA over SCTP's existence.

>    an RDMAP connection and hence independent of TCP or SCTP anyway?

It's actually a transport connection over whatever transport is used,
and
while I would not mention SCTP, this text probably ought to be
generalized
as iSER (a Datamover protocol) has been implemented over InfiniBand.

>    RDMAP RESET? TCP events should be hidden.

This needs to be rephrased to talk about a transport connection being
torn
down as the consequence of arrival of a TCP RESET.  The Datamover
protocol
(iSER in this example) will see the loss of the connection, even though
it
may not see the details of why the connection was lost.

>    registered in an IANA registry there, rather that with a TCP port

RDMAP does not have a native notion of port numbers - one of the design
decisions made in that protocol was to not add a level of demux beyond
TCP ports.  The paragraph is correct as written, although it could be
generalized to allow a Datamover protocol to add its own level of demux
on top of TCP.  I think the best thing to do is remove this paragraph
and replace it with a sentence saying that DA has no IANA
considerations.

>    Shouldn't this section move to the iSER draft?

I don't think so - it's mostly commentary on applying the DA model
described in this draft.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]] 
> Sent: Thursday, October 12, 2006 3:53 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: AD review of draft-ietf-ips-iwarp-da
> 
> Hi,
> 

(RDMA
>  >                   iSCSI and the Datamover protocols.  This guidance
is

---

From: Lars Eggert <[email-masked]>
Date: Tue, 17 Oct 2006 17:01:24 +0900

Hi,

FYI, the ID tracker has this document as going for Informational,  
whereas the charter has it going for PS. I assume the charter is  
correct and will change the target in the ID tracker.

Lars

---

From: [email-masked]
Date: Wed, 18 Oct 2006 01:24:14 -0400

The ID tracker is correct - this is going for Informational.

Thanks,
--David (ips WG chair)

> Sent: Tuesday, October 17, 2006 4:01 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Ips] AD review of draft-ietf-ips-iwarp-da
> 
> Hi,
>