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

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 18 Oct 2006 19:34:36 -0700 (PDT)

Hi Lars,

Thanks for the careful review.  I plan to submit a new revision of the draft in a day or so.  Following are my responses/resolutions.

Mallikarjun

>   Has idnits (unused references, tabs, non-ASCII characters, etc.) and

Now fixed (most of them).  I just didn't know what to do about 
non-ASCII character complaints - idnits is flagging every hyphen as a non-ASCII 
character for some reason....

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

David responded to this.  Just to make it very clear, I tweaked the Abstract to say the following:
".....While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols.  Each such Datamover protocol, to be defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually....."
Hope that makes it clearer.

>   some places and in others it says the opposite (that it isn't a wire
>   protocol) - this is confusing.

Datamover protocol is one artifact within the umbrella DA architecture.  While the former is a wire protocol, the latter is not.  The draft has been pretty careful to consistently separate the two out.

>Section 2.1, paragraph 1:
>   Paragraph probably needs to be updated to reflect recent history  
>(RDMA
>   done, not proposed anymore).

Done.

>
>
>Section 2.2, paragraph 2:
>   Nit: would not capitalize "architecture" here (and later)

Subjective.  I now changed "Architecture" to "DA architecture"

>Section 3, paragraph 1:
>   Might want to point out that RDMA over SCTP also exists (and cite
>   corresponding ID).

David responded to it, no changes made here.

>Section 5.4, paragraph 3:
>>         shared memory etc.) is really upto the implementations.
>
>   Nit: s/upto/up to/

Done.

>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?

Per your & David's feedback, I changed the last sentence to read:
 "A TCP connection is an example of a Transport Connection."

>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.

True, the sentence can be misleading for it is too terse.  I rephrased it to:
A target iSCSI layer being notified of an ungraceful connection termination by the Datamover layer when the underlying Transport Connection is torn down due to receiving a  TCP RESET is one example when the Connection_Terminate_Notify Operational Primitive is invoked.

>
>
>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.

David had already responded to this.  I did what David suggested, replaced the paragraph with a single sentence:
DA architecture does not have any IANA considerations.

>Section 15, paragraph 2:
>
>   Some of these are also listed as authors.

Not sure who, I double checked the list.

>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?

If it's okay, I'd prefer to leave this section in the DA draft, because 
the text is too DA-ish to belong to iSER draft.

----- Original Message ----
From: Lars Eggert <[email-masked]>
To: [email-masked]
Cc: [email-masked]; [email-masked]
Sent: Thursday, October 12, 2006 12:53:11 AM
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

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 25 Oct 2006 17:21:15 +0200

> character for some reason....

I'm not sure what template you use, but the easy answer is to  
manually edit the ASCII version in a text editor to replace these.

Also, there are some idnits other than about non-ASCII characters,  
please fix these, too: http://tools.ietf.org/wg/ips/draft-ietf-ips- 
iwarp-da/draft-ietf-ips-iwarp-da-04.nits.txt

> ".....While DA defines the architectural functions required of the  
> class of Datamover protocols, it does not define any specific  
> Datamover protocols.  Each such Datamover protocol, to be defined  
> in a separate document, provides a reliable transport for all iSCSI  
> PDUs, but actually....."

It does, thanks.

> A target iSCSI layer being notified of an ungraceful connection  
> termination by the Datamover layer when the underlying Transport  
> Connection is torn down due to receiving a  TCP RESET is one  
> example when the Connection_Terminate_Notify Operational Primitive  
> is invoked.

I'd suggest to rephrase this to make it clearer that there may be non- 
TCP Transport Connections:

A target iSCSI layer being notified of an ungraceful connection  
termination by the Datamover layer when the underlying Transport  
Connection is torn down. Such a Connection_Terminate_Notify  
Operational Primitive may be triggered, for example, by a TCP RESET  
in cases where the underlying Transport Connection uses TCP.

> the text is too DA-ish to belong to iSER draft.

That's actually why I thought it might make sense to move it.  
Currently, nothing in the iSER draft makes it clear that iSER is an  
instantiation of the Datamover architecture. The first mention of  
Datamover in iSER - other than in the terminology section - is buried  
in a bullet in section 2.2. This should be much more prominently stated.

Lars