[rddp] RDDP Atlanta minutes

[[e-mail]]

11/20/02 RDDP WG
David Black, Chair
Notes by Allyn Romanow

-- Agenda bashing
-- Work and goals
     draft-black-rdma-concerns-00.txt will be submitted as an RDDP draft to
     make it easier to find it, but the authors are not planning to submit
     for RFC status.  It's purpose it to cause people to consider issues.

-- WORKSHOP announcement (Allyn Romanow)
	Network-I/O Convergence: Experience, Lessons, Implications (NICELI)
	- SIGCOMM 2003 Workshop August 25-29, Karlsruhe Germany
	- Call for Papers - technical paper or position paper
 	- Will be at www.acm.org/sigcomm/sigcomm2003/workshop/niceli 
	- Or contact [e-mail] 

-- Review of Problem Statement and Architecture drafts (Tom Talpey)
	draft-romanow-rdma-over-ip-problem-statement-01.txt
	draft-bailey-roi-ddp-rdma-arch-01.txt

Two new versions

Problem statement done
Architecture issues
     ordering of placement and delivery
     steering tag details
     security considerations and threat analysis
See David Black if you want to work on security section of the doc

These two drafts will become RDDP WG drafts.

------
--  SCTP Mapping draft-stewart-rddp-sctp-00.txt (Randall Stewart)

Short doc, provides SCTP mechanism for knowing what each side
	expects to do
Details of ways to use SCTP features not filled in yet
     how use SCTP most effectively
     how optimize transfer with un-ordered packets
     other details
Soliciting help, work with Randy. Get in touch with David Black or Randy

-----------
--  Overview of DDP and RDMA (Renato Recio)
	draft-shah-iwarp-ddp-00.txt
	draft-recio-iwarp-rdma-00.txt

See overview slides - these explain high level functionality and
relationship of these two drafts.

------------------
-- DDP draft (Hemal Shah)
	draft-shah-iwarp-ddp-00.txt

See slides for details.

Overview of the DDP mechanism
Distinction between placement and delivery is extremely important
	Placement - self describing segments, can place in any order
	Delivery - in-order delivery, DDP notifies ULP only when all
		messages received
Only interested in LLP that provides reliable in-order delivery

STag Validation semantics - 4 models
	After discussion, the rough consensus of the room was to carry
	two of the four models, STag bound to a single stream and access
	group (protection domain model forward.  A functional reference
	model will be needed to specify the required access control
behavior;
	implementations must exhibit the externally visible behavior of the
	model (this is similar to the specification of the IPsec Security
	Policy Database and Security Association Database - see RFC 2401).

	A performance concern was raised about the consequences of access
	control.  Combining the above functional model with a functional
	model of a NIC (hardware) should help illuminate the issues here.
	
Clarifications on DDP Segmentation
	- Send segments in increasing order, for both untagged and tagged
transfers
	- No overlapping of payload is allowed among DDP segments in the
same
		message.
	- Interleaving DDP segments of different DDP messages not allowed
		at the data source.  Use multiple streams for concurrency,
not
		multiplex on the same stream

Requirements for Unreliable Transport
	Only considering reliable transports currently.  Anyone interested
		in unreliable transports should "Send Draft" .. says WG
chair.

Local interface requirement for buffers
	Need to specify? yes, need to specify access control and protection,
	but not from the perspective of specifying a full API 

Reserved ULP field in DDP Header

Remote invalidate will need to be taken up, can be dealt with online

Q&A: DDP should cleanly layer on unordered SCTP.  Should layer on ordered
	SCTP with a little care and attention.  SCTP can support immediate
placement
	and in-order delivery, provide that access to cumulative TSN is
available
	to DDP.

This will become and official WG draft (next version containing access
control text)

-------------------
 -- RDMAP (Renato Recio)
	draft-recio-iwarp-rdma-00.txt

There have been 3 issues on mailing list

(1) RDMAP Initialization - How to transition from non-RDMA to RDMA
	TCP mapping needs to look at SCTP, understand what it did (DDP
		and RDMA support announced during connection setup) and
		either do something similar, or explain why not.

(2) Security

Have begun working with Catherine Meadows, security expert, on the
	Security Directorate, lots more work needed on security.

Security Concerns 
     -STag
     -what layer is the association made at?
     -how can IPsec be used to protect an DDP RDMA stream?
     -Enumerate the threat model (e.g. DOS attack )

(3) Multi-homed hosts for SCTP
	Proposal - this issue doesn't belong here, it belongs in SCTP WG
(TSVWG)-
		a problem with multi-homed hosts.

	WG Chair - SCTP mapping draft should deal with this and say how it
		should be handled or avoided.

This will become an official WG draft (next version including access control
text)

------------------
David Black (WG Chair)- What might be the draft mapping RDMA to TCP look
like?

Reviews what happened in TSVWG meeting the previous day.  It will take a
while
to work out any proposed changes to TCP. It is premature to adopt the
Williams
draft as WG doc, although the WG chair thinks it has good stuff in it, and
the
draft suggests how to do the mapping without changes to TCP

Scott Bradner (Area Director) - reports on a discussion that took place
after the TSVWG meeting.

ADs (tsvwg chairs) are very reluctant to approve changes to TCP.
It would be necessary to put together an I-D that proves that
no possible combination of tweaked and non-tweaked TCPs could possibly
get confused, meaning that it is necessary to prove that there is no way 
that different TCPS can get confused between each other. Agrees that
it is premature to accept the Williams draft as a WG item. 

Q: Can we use the rddp WG as where the discussion takes place?
Bradner - the initial discussion was in TSVWG for the broader community.
	Detailed work can be done here, in RDDP, then go to TSVWG, for
review

---------------------
-- Mapping DDP/RDMA to TCP, IFT (Jim Williams)
draft-williams-iwarp-ift-00.txt
See slides

Open issues 
CRC -  slide proposed two CRCs if assume non-aligned PDUs as in IFT/TCP
	One CRC should be sufficient for assume aligned PDUs as in SCTP or
MPA/TCP

	- A long inconclusive discussion ensued - the issue was redirected
to
		the mailing list.

Issue - markers
Can't really discuss till figured out in TSVWG

WG Chair (David Black): MPA uses an aggressive form of markers.
Comment: Reason for markers is that they allow the ULP
	to progress to find the next PDU, after an error is found
	as opposed to just dropping the connection.

Other IFT details - not worth dealing with now.

Q: Does TCP need to be "FIXED"? does TCP placement as in SCTP
cover the needs of RDDP?

David Black - MPA and IFT appear to be at opposite ends of the
design space, thinks there might be a design strategy in between.
Will need to follow Scott's suggestion for any TCP changes.

Comment: Wants support for bufferless NICS as well as buffered NICs. 

David Black - there's no such thing as a bufferless NIC, as dealing with
	a DMA controller requires buffering - should talk in terms of the
	amount of buffering.

-- Process going forward (David Black)

Take discussion to the list
Focus on specific features rather than one approach or another
Drafts are extremes in the design space, there should be a way in between
Too early and too much unknown to charter a design team now

Question: Should RDDP write a document on what a ULP needs to do to use
DDP/RDMA?
	A reference model was mentioned- will some of this come out of a
	reference model?

David Black - ref model in two places, NIC functionality and security.

	- Another issue is the memory model. Joe Touch in TSVWG, asked, who
	owns what memory, when? It needs a state machine.  A related issue
	is what happens when there are concurrent operations on different
	streams to the same memory?  That needs to be specified minimally
	in order to avoid running afoul of multiprocessor memory coherence
issues.
	Application designer wants description of what NOT to do in both
cases.
_______________________________________________
rddp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rddp