| Newsgroups |
gmane.ietf.rddp |
| Message-ID |
<[email protected]> |
Comments to me please. Thanks, --David
RDDP WG Minneapolis meeting DRAFT 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.
-- 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
file for details. Security draft is on critical path for
completion of DDP and RDMAP - due to current state of security
draft, WG milestones are likely to slip 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. The DDP draft had an implementers note added
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.
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 issue 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, there are no better choices
of 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, and 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 come up
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 is 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-trips
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 a consideration 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 explain it.
--> 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 issues.
-- Security Draft [F]
Comprehensive presentation (see slides) due to unfortunate conflict between
Vienna RDDP session (previous meeting) in which security was discussed
and saag (Security Area) meeting.
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. Does this have performance implications?
A: The intent is that it only 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 here.
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 this 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.