Re: AD review of draft-ietf-ips-iwarp-da
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 <lars.eggert@xxxxxxxxxxxxx>
To: ips@xxxxxxxx
Cc: ips-ads@xxxxxxxxxxxxxx; ips-chairs@xxxxxxxxxxxxxx
Sent: Thursday, October 12, 2006 12:53:11 AM
Subject: 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
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
