[rddp] RDDP WG San Francisco Final meeting minutes
Black_David@emc.com Mon, 14 April 2003 17:32 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13288 for <rddp-archive@odin.ietf.org>; Mon, 14 Apr 2003 13:32:11 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3EHdtU08615 for rddp-archive@odin.ietf.org; Mon, 14 Apr 2003 13:39:55 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHdt808612 for <rddp-web-archive@optimus.ietf.org>; Mon, 14 Apr 2003 13:39:55 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13241 for <rddp-web-archive@ietf.org>; Mon, 14 Apr 2003 13:31:40 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1957qP-0003iv-00 for rddp-web-archive@ietf.org; Mon, 14 Apr 2003 13:34:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1957qP-0003is-00 for rddp-web-archive@ietf.org; Mon, 14 Apr 2003 13:34:13 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHdF808555; Mon, 14 Apr 2003 13:39:15 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3EHcf808490 for <rddp@optimus.ietf.org>; Mon, 14 Apr 2003 13:38:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13071; Mon, 14 Apr 2003 13:30:25 -0400 (EDT)
From: Black_David@emc.com
Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1957pC-0003i5-00; Mon, 14 Apr 2003 13:32:58 -0400
Received: from [128.222.32.10] (helo=mxic1.corp.emc.com) by ietf-mx with esmtp (Exim 4.12) id 1957pC-0003ho-00; Mon, 14 Apr 2003 13:32:58 -0400
Received: by mxic1.corp.emc.com with Internet Mail Service (5.5.2653.19) id <2PQXX7ZX>; Mon, 14 Apr 2003 13:32:19 -0400
Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CB1B@corpmx14.corp.emc.com>
To: minutes@ietf.org
Cc: rddp@ietf.org
Date: Mon, 14 Apr 2003 13:26:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [rddp] RDDP WG San Francisco Final meeting minutes
Sender: rddp-admin@ietf.org
Errors-To: rddp-admin@ietf.org
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
RDDP WG Meeting Minutes 56th IETF March 17 & 20 2003 ------------------ Thanks to Allyn Romanow for taking notes. -- TCP Mapping Requirements (David Black) This is a reminder from the WG chair in combination with the Area Directors of what is expected of the RDDP WG's TCP mapping work. (1) The "proof" requirement that two communicating stacks can't get confused about the format of communication applies to the entire RDDP protocol stack running over TCP, not just the issue of whether a modified vs. unmodified TCP is being used. 32 bits of zeroes (first marker) to distinguish what is going on is not enough, 128 bits randomly generated for the connection is enough (sufficient, but may be more than needed). Relying on ULP to do this is considerably weaker than solving the problem in RDDP. Negotiation is not required - a declaration mechanism like the SCTP adaption indication exchange is sufficient (no additional round trip is required). (2) The nfsv4 WG is starting work on application of RDDP to NFSv4. NFSv4's current level of data integrity does not require a CRC; if this remains the case for NFSv4 over RDDP, the RDDP CRC will need to be optional to use. (3) Fixed interval markers are a potential problem for software implementations (see below, as a great deal of time was spent on this issue later). -- Administrivia Reminder that the problem statement and architecture drafts are in WG Last Call. Please read and comment on the list. -- SCTP Mapping Draft (Randy Stewart) See slides (will be posted). Draft is relatively far along. Note that SCTP uses (completely) unordered delivery when carrying RDDP traffic. This requires DDP to track its operation ordering in order to enforce any delivery order requirements. -- Applicability Statement Draft (Randy Stewart for Caitlin Bestler) Plan has changed to a 3 draft approach - (1) TCP mapping, (2) SCTP mapping, and (3) an applicability statement draft covering both mappings. Lode Coene (editor of SCTP's applicability statement, which set a good example) has agreed to help out with the RDDP applicability statement (many thanks). Advice from the WG chairs and ADs: A good applicability statement is guidance on utility, not advertising to promote usage. An important target audience is ULP designers who are looking advice on whether to use RDDP and with which transport. Both the SCTP mapping draft and applicability statement draft were approved to be official RDDP WG drafts - next versions will have draft-ietf-rddp-* names. -- Allyn Romanow - NICELI Workshop reminder and security update For NICELI, see: http://www.acm.org/sigs/sigcomm/sigcomm2003/workshop/niceli/ Security update - folks working on this issue are making good progress with Catherine Meadows (security advisor). Initial draft will be posted for discussion in the next 2-3 weeks. -- DDP Update - Hemal Shah couple of small changes. -- RDMAP Update - Paul Culley (for Renato Recio) a couple of small changes (no presentation slides) -- TCP mapping - MPA Update - Paul Culley Packing of multiple ULPDUS into single TCP segment is now allowed. MPA is now specified as an "adaptation layer" for RDDP that must be explicitly enabled by higher-level protocol (i.e., DDP/RDMA or ULP further up the stack). - IFT update - Jim Williams Added adaption indication, based to some extent on the one used with SCTP. CRC is optional and negotiable Markers are negotiable, with some details to be fleshed out. Speculative placement proposed for use when markers not provided - this received a rather negative reaction in the meeting. -- TCP mapping issues David Black worked through several major outstanding issues for the WG: (1) Alignment and TCP Mapping This is about aligning transmitted ULPDUS (w/RDDP headers) to TCP segment boundaries. David Black summarized from the mailing list discussion and made a proposal Alignment is not required for interoperability, the RDDP receiver cannot rely on it, but it is a potentially useful optimization. Therefore, the proposal is to treat alignment as an implementation optimization only, and hence not use any MUST or SHOULD (in the RFC 2119 sense) for alignment, but instead use (at most) lower case "should" along with a description of the circumstances in which alignment is a useful optimization. This represents rough consensus of the Working Group participants in the room. Additional note from WG chair: While nothing is certain, this approach is very likely to be acceptable to the tsvwg (Transport Area) WG, where past alignment work has generated controversy. (2) Markers - this generated a *lot* of discussion, mostly focused on marker interval. Markers are motivated by a need to regain synchronization for placement after a packet drop or reordering without having to waiting for retransmit. Markers allow finding where the header is in byte stream. MPA currently requires markers at 512 byte fixed intervals A potential problem with markers is the overhead for existing stacks For example, for an 8KB transfer, 1 send operation becomes 16 sends (Some people suggest fewer than 16 because can use gather technique.) This overhead is a potential problem for a software implementation. Markers have been motivated by flow through designs that may be overly optimized, especially given above rough consensus on alignment. The discussion focused on buffering requirements, and whether a link frame per connection is required - it clearly is in the worst case, but there are enough shorter packets/frames (e.g., about 500 bytes on Ethernet) that on average across multiple connections, one can use less, and hence a marker interval shorter than the max link frame size (e.g., about 1500 bytes for Ethernet without jumbo frames) does save implementation resources. There was at least one comment that Markers should be optional. There is no rough consensus, but David notes that there is a lot of support for markers and the 512 byte interval in particular. (3) NFSV4 and CRCs The nfsv4 WG charter now includes NFSV4 over RDDP problem statement and requirements. NFS does not require stronger data integrity than TCP/IP checksums, so a mandatory RDDP CRC may be excessive although optional RDDP CRC could be useful. The argument in the other direction is that RDDP is new and wants to provide a better level of service (data integrity), so demanding that all users of RDDP step up to that level of service is within reason. After much discussion the conclusion is to defer the issue of whether to require CRC usage for further input from the nfsv4 WG's requirements work. -David concludes: alignment - there is rough consensus in the room, will recheck on list. marker interval - there is clear support for a 512B interval CRC - will defer "MUST use" issue until nfsv4 WG is further along in considering requirements for RDDP with NFSv4. Hope to close remaining issues in this space by summer IETF (Vienna) _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] RDDP WG San Francisco Final meeting minutes Black_David
- Re: [rddp] RDDP WG San Francisco Final meeting mi… Caitlin Bestler