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.