Marker PDU Aligned Framing for TCP Specification
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, rddp mailing list <firstname.lastname@example.org>, rddp chair <email@example.com> Subject: Protocol Action: 'Marker PDU Aligned Framing for TCP Specification' to Proposed Standard The IESG has approved the following document: - 'Marker PDU Aligned Framing for TCP Specification ' <draft-ietf-rddp-mpa-09.txt> as a Proposed Standard This document is the product of the Remote Direct Data Placement Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-09.txt
Technical Summary MPA (Marker Protocol data unit Aligned framing) is designed to work as an "adaptation layer" between TCP and the Direct Data Placement [DDP] protocol, preserving the reliable, in-order delivery of TCP, while adding the preservation of higher-level protocol record boundaries that DDP requires. MPA is fully compliant with applicable TCP RFCs and can be utilized with existing TCP implementations. MPA also supports integrated implementations that combine TCP, MPA and DDP to reduce buffering requirements in the implementation and improve performance at the system level. Working Group Summary The degree to which TCP should be changed for MPA (and hence the rddp protocol stack) has been a source of controversy. The WG has adopted an approach that requires no TCP modifications, and there is now strong WG consensus for that approach. Protocol Quality The protocol has been reviewed for the rddp WG by David L. Black. There are multiple implementations of the MPA protocol, including the Request and Reply frames for connection setup added by the WG at the direction of the Transport Area. David Black (firstname.lastname@example.org) was the PROTO Document Shepherd. Lars Eggert (email@example.com) has reviewed this document for the IESG. Note to RFC Editor OLD The decision for hosts to request CRC suppression MAY be made on an administrative basis for any path that provides equivalent protection from undetected errors as an end-to-end CRC32c. NEW An administrative decision to have a host request CRC suppression SHOULD NOT be made unless there is assurance that the TCP connection involved provides protection from undetected errors that is at least as strong as an end-to-end CRC32c. End-to-end usage of an IPsec cryptographic integrity check is among the ways to provide such protection, and the use of channel bindings [NFSv4CHANNEL] by the ULP can provide a high level of assurance that the IPsec protection scope is end-to-end with respect to the ULP.