Current Meeting Report
Slides


2.8.14 Remote Direct Data Placement (rddp)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 07/05/2002

Chair(s):
David Black <black_david@emc.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Technical Advisor(s):
Allyn Romanow <allyn@cisco.com>
Stephen Bailey <steph@cs.uchicago.edu>
Mailing Lists:
General Discussion: rddp@ietf.org
To Subscribe: rddp-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/rddp/current/maillist.html
Description of Working Group:
The purpose of this WG is to enable Remote Direct Data Placement (rddp) capabilities with IP transport protocols, in particular with SCTP. RDDP capabilities refer to the ability to place data directly from the NIC into application buffers, without intensive CPU usage. This strategy avoids the costs of data copying and enables using IP as a method for high speed buffer to buffer transfer, allowing IP to replace special purpose networks currently in use. Remote Direct Memory Access (RDMA) is an example of this concept.

Conceptually, RDDP functionality can be viewed as consisting of two layers. First the direct data placement capability, which is accomplished through a tag and a lookup table on the NIC. Above this core functionality, an RDDP control protocol is needed to specify how the direct data placement can be used, for example READ and WRITE commands.

The work of the WG is to accomplish four items:

1) A (transport independent) protocol core to support direct data placement from the NIC into specified memory, usually application buffers.

2) A (transport independent) protocol core layered on top of the direct data placement protocol that specifies control of RDDP.

3) A mapping of the direct data placement protocol onto SCTP, for standards track, including a clear applicability statement of the expected service from the mapping.

4) A mapping of the direct data placement protocol onto TCP, for informational, because TCP's service is a less good match to RDDP, including an applicability statement of the issues regarding the service available from the mapping.

The working group will ensure that the resulting technology will be secure and will not enable new attacks on systems supporting RDDP. The WG will not modify existing Internet transport protocols, but may forward issues it discovers in such transport protocols that are not full Internet Standards to the appropriate IETF WGs for their consideration.

Goals and Milestones:
OCT 02  Submit Internet-Draft including problem statement and achitecture
OCT 02  Submit Initial draft of Remote Direct Data Placement protocol (RDDP)
OCT 02  Submit Initial draft of RDMA control protocol, to be named.
DEC 02  Initial draft mapping the RDDP core and control onto SCTP including A/S
FEB 03  Initial draft informationally mapping the RDDP core and control onto TCP, including A/S
MAR 03  Submit problem statement/architecture to IESG for consideration as an informational publication
MAR 03  Area Director review of charter and progress, with possible rechartering or closure.
JUL 03  Submit Remote Data Placement Protocol (RDDP) to IESG for consideration as a Proposed Standard
JUL 03  Submit RDMA control protocol (named TBD) to IESG for consideration as a Proposed Standard
OCT 03  Submit mapping the RDDP core and RDMA control onto SCTP including detailed applicability statement to IESG for consideration as a Proposed Standard
OCT 03  Submit mapping the RDDP core and RDMA control onto TCP including detailed applicability statement to IESG for consideration as informational RFC
No Current Internet-Drafts
No Request For Comments

Current Meeting Report

 IETF Remote Direct Data Placement (rddp) WG
Meeting minutes - July 18, 2002, Yokohama, Japan
-------------------------------------------------

Chair: David L. Black (black_david@emc.com)

-- Agenda Bashing and Administrivia

rddp is now an IETF Working Group, formed based on the ROI (RDMA Over the
Internet) BOFs in Salt Lake City and Minneapolis.

The mailing list is up and running at rddp@ietf.org. To subscribe, send email to
rddp-request@ietf.org. Use of the rdma list at Yahoo Groups for IETF work has
ceased.

-- Charter and Goal/Milestone review and discussion

The official WG charter is available at:

http://www.ietf.org/html.charters/rddp-charter.html

The four work items on the charter encompass the entire scope of the WG's
activities. TCP framing was deliberately omitted from that list - TCP framing
work belongs in the Transport Area (tsvwg) WG. The rddp WG is not permitted to
standardize changes to transport protocols - it may recommend (minor) SCTP
specification changes to the tsvwg WG, but TCP specification changes are not
permitted. The rddp WG has a rechartering scheduled for March 2003 whose outcome
(e.g., whether the WG will be allowed to continue) will be based to a large
extent on the progress made between now and then.

The rddp WG is expected to work on mapping its functionality to both SCTP and
TCP - see the charter. Work to apply RDDP mechanisms to protocols other than
SCTP and TCP is outside the current charter - those interested in such work,
including generic IP-layer mechanisms applicable to all protocols that use IP,
should submit Internet-Drafts as a basis for further discussion. The planned WG
draft mapping RDDP to TCP is currently intended to become an Informational RFC
rather than a standards track RFC - any decision to change this is best done
with a draft in hand, so consideration will be deferred to the rddp WG
rechartering currently scheduled for March 2003. On the subject of compatibility
with proprietary interconnects/protocols that already support RDDP-like
functionality (often called RDMA), the guidance from the Area Director is that
the WG should not go out of its way to be incompatible, but likewise, heroic
efforts motivated solely by such compatibility are also inadvisable.

The RDMA Consortium (www.rdmaconsortium.org) was brought up. This industry
consortium was organized to work on providing functionality over TCP, and has a
goal of transferring its work to the IETF and putting itself out of business.
The RDMA consortium was formed at a time where there was some confusion over
whether and to what extent the IETF would permit RDDP work over TCP - that
confusion has now been resolved by the rddp WG charter (such work is permitted,
but SCTP comes first). The WG chair will work with the RDMA consortium towards
their goal of moving their work into the IETF. It should be understood that "the
fix is not in" - while the RDMA Consortium is very likely to submit drafts
describing its work, that does not preclude others from writing drafts on the
same or similar topics for consideration by the WG.

-- RDMA Concerns Draft (draft-black-rdma-concerns-00.txt)

This draft was based on concerns arising from the Minneapolis BOF and evolved to
its current form via discussion at an end2end Research Group meeting. This draft
is input to the rddp WG, and is not expected to become an RFC.

The topic of potential Intellectual Property Rights issues was raised. The only
official way to notify the IETF of such issues is to send an IPR notice to the
IETF - mailing list discussions are not "official notice". If anyone knows of an
IPR claim for which they believe a notice should have been sent to the IETF but
was not, a private email should be sent to the WG chair as an initial step.

An issue was raised about the absence of "application integrity" from the RDMA
concerns draft - in addition to "system integrity" concerns, the overwrites made
possible by RDDP functionality open up potential attacks on applications via
overwriting data between the time that an application checks the data and the
time that the application makes use of the data. This concern will be included
in the -01 version of the RDMA concerns draft.

-- Problem Statement and Requirements drafts
(draft-romanow-rdma-over-ip-problem-statement-00.txt)
(draft-talpey-rdma-over-ip-requirements-00.txt)

-01 versions of both drafts with minor revisions should hit the Internet-Draft
servers shortly after the Yokohama meeting week.

The rddp WG is tasked to produce a problem statement/architecture draft along
with specifications of an RDDP protocol and an RDDP control protocol (for RDMA
functionality) and mappings of those protocols to SCTP and TCP . The problem
statement draft will be expanded with architecture text to become the first of
these drafts (one possible source is draft-bailey-roi-ddp-rdma-arch-00.txt).
Randy Stewart has a draft (draft-stewart-sctp-roi-00.txt) that could serve as
the basis for the mapping to SCTP.

There was a discussion about the relationship between RDDP operation sizes (as
invoked by protocols above RDDP) and transport segment sizes (based on network
Path MTU). These sizes ought to be independent, which entails segmentation and
reassembly in the RDDP layer with the goal of providing an RDDP header in each
transport segment; SCTP's ability to operate without SCTP fragmentation helps,
but there are some unavoidable situations in the face of Path MTU changes where
transport segments may have to be sent without an RDDP header in each segment.

-- Other Business and/or Discussion

The division of work for applying RDDP to various protocols will probably be
similar to the way that the IETF handles MIBs - the rddp WG will do the basic
work to define the RDDP mechanisms, and then other WGs will handle
application/mapping to their respective protocols. For the specific case of SRP
(SCSI RDMA Protocol), the IP Storage (ips) WG is one possible place to do that
application/mapping work even though the protocol is specified by T10.

For interface specifications (e.g., application interface to RDDP implemented in
hardware), drafts are welcome (including the envisioned division of
functionality between hardware and software), but the IETF has not generally
been enthusiastic about specifying APIs and the like, and does not use API
specifications to drive protocol definitions. The RDMA Consortium is currently
working on verbs (abstract API definition), and it may be appropriate to allow
that work to continue there rather than transferring it to the IETF.

Slides

None received.