Subject: [rddp] RDDP WG final Minneapolis minutes

From: [email-masked]
Date: Thu, 20 Nov 2003 09:45:17 -0500

RDDP WG Minneapolis meeting minutes
Tuesday, November 11, 2003, 0900-1130
-----------------------------------------

Letters in [square brackets] are the first letter of
file name of presentation that goes with each agenda item
in the proceedings.

-- Agenda Bashing and Administrivia [A]

No changes to agenda posted to mailing list.

-- Status of Drafts [B]

WG chair reviewed status of WG drafts.  See presentation
for details.  Security draft is on critical path for completion
of DDP and RDMAP - due to the current state of the security
draft, WG milestones are likely to move out by one IETF
meeting (about 3-4 months).

-- RDMA Applicability Statement [C]

In good shape.

-- DDP and RDMAP drafts [D]

Both are relatively stable, and have received minor updates
since Vienna.  An implementers note has been added to the DDP
draft to say that absence of a pre-allocated buffer for an
inbound untagged transfer does not need to immediately cause
an error that results in connection teardown - this was based
on extensive list discussion that concluded that implementations
should be allowed to keep a few "hidden" buffers to avoid (or
delay) the consequences of tearing down a connection.

The WG chair plans an initial WG Last Call on these drafts during
December, BUT they cannot be forwarded to the ADs/IESG until the
security draft is complete, and work on that draft will probably
cause additional changes to the DDP and RDMAP drafts.

-- SCTP Mapping [no presentation]

In relatively good shape.  One important open issue is that the
SCTP mapping allows Active/Active startup, whereas the TCP mapping
only allows Active/Passive.  This needs to be consistent across
both mappings, and will be resolved on the list - see Action Items
on this topic under the next agenda item.

-- TCP Mapping [E]

A number of changes have been made since the Vienna meeting:
- The Start Key is now 2 separate frames, so that it differs in
	each direction.
- Now using Initiator/Responder terms to designate roles in Active/
	Passive connection setup.  Discussion during the meeting
	suggested that while Initiator is also used to describe
	SCSI operation, there are no better terms readily available.
- "Private Data" support added.  Intention was to match SCTP support
	for this.
- Added support for "Immediate Startup" (RDDP protocols start up
	immediately at start of TCP connection) and example.

+ Active/Active startup issue. 

Draft authors prefer not to support Active/Active because it is
hard to get right in a "dual stack" system that switches between an
ordinary TCP (or SCTP) stack and an RDDP-enhanced one (e.g., in
hardware).  This needs to be taken to the list and resolved once
for both transports (either both TCP and SCTP support Active/Active, 
or neither does).  Action Items:

1) Draft authors to describe this problem including a sufficient
	functional model/description for a "dual stack" system to
	explain the implementation difficulty.
2) WG chair to ask on list whether any ULPs that are (or can be)
	anticipated to use RDDP need, want, or would benefit from
	Active/Active startup.

In connection with 2), it was asked whether SDP (Sockets Direct
Protocol) could become an RDDP WG work item.  The answer is "yes,
it could" - SDP draft authors should consult with WG chair (who
will consult with ADs as appropriate) when the SDP draft appears.
SDP does not require Active/Active startup, as sockets are
Active/Passive (listener is passive).

Immediate startup (RDDP starts when TCP connection is established) 
favors Active/Passive due to connection handshake - initiator of
handshake should initiate RDDP setup on the established TCP
connection.  SCTP uses adaption indications for this purpose.  Note
that in this case, the implementation has to "guess" what mode the
connection will start in, and if that "guess" is wrong, the
processing of data in the wrong mode on the wrong "stack" in a
"dual stack" system is likely to be unrecoverable - recovery would
have to be via connection close and some sort of retry (doing
something different to avoid a repetition).  Needs to be discussed
on list as part of above "dual stack" discussion.

+ Minor issues (see slides)

- Is single bit difference in Initiator vs. Responder start frame
	formats ok?  Probably, but needs to be discussed on list.
- How to reference Verbs draft, since IETF may not publish it?
	Informative reference to RDMAC version of verbs draft as an
	**example** should be ok.  Verbs draft cannot be used to
	impose requirements on RDDP.

+ Startup round-trip overheads

When ULP has exchanged data without RDDP and wants to switch into
RDDP mode, the resulting synchronization costs a round trip.  The
"dual stack" issue is an important motivation here.

For immediate startup, the first message of the setup round trip
can be combined with the TCP ACK that concludes the TCP connection
setup handshake, thus reducing the cost to half a round trip, but
that cost appears to be necessary in order to support private data
in a "dual stack" implementation.  Reducing this cost only helps if
Active/Active setup is required, or first data transfer is from TCP
Listener.

An issue was raised on the list about the MPA private data mechanism,
but no one at the meeting could reconstruct it accurately.

--> Needless to say, the "dual stack" issues need significant
discussion on the list, as consideration of this class of implementation
has had significant influence on the design decisions.  As part of this,
it will be necessary to check whether SCTP's use of adaption indications
changes any of these "dual stack" issues.

-- Security Draft [F]

Comprehensive presentation (see slides) due to an unfortunate conflict
in Vienna between the RDDP session in which security was discussed
and saag (Security Area) meeting.  The WG chair will do his best to
ensure that this sort of conflict does not occur in the future.

The sense of discussion in the room was that the partial trust taxonomy
and resulting matrix on slide 17 was not needed in the main body of the
security draft, but could be moved to an appendix or separate draft.
The main body of the security draft does need to discuss important
usage scenarios and the assumptions about what involved parties won't
do in order to set up applicability of threats and countermeasures to
those scenarios.

STag invalidation is an important countermeasure, and the current
structure of RDDP functionality requires the ULP to check that
invalidation occurred and that the correct/expected STag was
invalidated.  If not, the ULP will need to do something (e.g.,
invalidate the STag that should have been invalidated).

Q: Draft introduces Privileged Resource Manager as a mandatory
	functional component.  How does this affect performance?
A: The intent is that it not be involved in high-frequency
	operations, but more work is needed to define the precise
	functionality of the Privileged Resource Manager and check
	if there are problems.

It was noted that some countermeasures (e.g., limits on amount of
non-pageable host memory) may be part of the host OS itself as
opposed to the RDDP implementation.

--> Action Item: The "dual stack" architecture that came up in the
MPA draft discussion has security implications, as the point of
"stack switch" is an obvious place for an attacker to try something
(e.g., louse up the stack switch so that the connection has to be
abandoned).  MPA draft authors to look into this and post results
of their investigation to list.

-- iSER/DA drafts [G]

These two individual submission drafts concern iSCSI extensions for
use of RDMA (RDDP).  They were presented for the information of the
WG, but will not become RDDP WG work items.

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