[rddp] rddp Yokohama DRAFT minutes

[[e-mail]]

Thanks to Mike Smith for taking notes.  Here are
the draft minutes.  Please comment either privately
or to the list - the final minutes will be sent to
the secretariat around the end of this week.

Thanks,
--David

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

Chair: David L. Black ([e-mail])

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

_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp