IPS WG and DA draft authors,
We definitely need a new version of this draft, as there appear to
be a number of things that need attention here:
> 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).
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
> some places and in others it says the opposite (that it isn't a
wire
> protocol) - this is confusing.
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.
> 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).
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.
> 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?
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.
> 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.
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.
> 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.
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.
> 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?
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 protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: Lars Eggert [mailto:[email protected]]
> Sent: Thursday, October 12, 2006 3:53 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.