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

Chair: David L. Black ([email protected])

-- 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 [email protected]. To subscribe, send email to
[email protected]. 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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.