[rddp] DDP PROTO writeup

Black_David@emc.com Thu, 29 September 2005 17:18 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL23f-0006Rl-Kz; Thu, 29 Sep 2005 13:18:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL23e-0006Rd-AI for rddp@megatron.ietf.org; Thu, 29 Sep 2005 13:18:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23426 for <rddp@ietf.org>; Thu, 29 Sep 2005 13:18:54 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2BK-0007xA-OA for rddp@ietf.org; Thu, 29 Sep 2005 13:26:56 -0400
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8THIrlj005213 for <rddp@ietf.org>; Thu, 29 Sep 2005 13:18:54 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <RT6ADS09>; Thu, 29 Sep 2005 13:18:53 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6EED@CORPUSMX20A.corp.emc.com>
To: rddp@ietf.org
Date: Thu, 29 Sep 2005 13:18:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.29.18
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Subject: [rddp] DDP PROTO writeup
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
Sender: rddp-bounces@ietf.org
Errors-To: rddp-bounces@ietf.org

The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt)
is being used for the DDP draft.  Here is the PROTO writeup:

              Direct Data Placement over Reliable Transports 
                     draft-ietf-rddp-ddp-05.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

   1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

   1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited review outside the WG.

   1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

   1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

   1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG as a whole understands and agrees with this document.

   1.f) [... not sent to the WG ...]

   1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits checker doesn't like the page separators or absence thereof
(it thinks the document is 1 page).  It says everything else is ok.

   1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are two normative references to Internet-Drafts:

o draft-ietf-rddp-rdmap - publication has been requested along
	with this draft.
o draft-ietf-rddp-mpa - publication will be requested within
	the next 2 weeks.

   1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

   1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

   Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol 
   (ULP) to send data to a Data Sink without requiring the Data Sink to 
   Place the data in an intermediate buffer - thus when the data 
   arrives at the Data Sink, the network interface can Place the data 
   directly into the ULP's buffer. This can enable the Data Sink to 
   consume substantially less memory bandwidth than a buffered model 
   because the Data Sink is not required to move the data from the 
   intermediate buffer to the final destination. Additionally, this can 
   also enable the network protocol to consume substantially fewer CPU 
   cycles than if the CPU was used to move the data, and removes the 
   bandwidth limitation of only being able to move data as fast as the 
   CPU can copy the data. 

   DDP preserves ULP record boundaries (messages) while providing a 
   variety of data transfer mechanisms and completion mechanisms to be 
   used to transfer ULP messages. 

-- Working Group Summary

   DDP provides two mechanisms, a Tagged Buffer mechanism for Remote
   DMA transfers where the network communication contains a destination
   memory offset, and an Untagged Buffer mechanism that supports
   socket-like sends where the receiver chooses the buffer on its own.
   The WG has strong consensus that both mechanisms are required in order
   for an implementation to exercise control over all memory buffer
   resources used for network communication.

-- Protocol Quality

   The protocol has been reviewed for the rddp WG by David L. Black.

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp