[rddp] RDDP DRAFT San Francisco Minutes

[[e-mail]]

Thanks to Allyn for taking notes.  Send
corrections to me and/or the list please.

Thanks,
--David



RDDP WG Meeting Minutes **DRAFT**
56th IETF
March 17 & 20 2003
------------------

-- 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

-- 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp