RE: [Ips] DDP message interleaving

[This discussion seems more appropriate to the rddp reflector so I've
copied that and suggest we move over there if more is needed]

Caitlin,

In the general case, the RDMAP protocol and the ULPs built on it are
designed to rely on in order delivery of messages. A lower layer
protocol that sends out of order but reorders before the packets leave
the llp at the receiver (e.g. TCP retransmission of dropped packets) is
okay. A lower layer level that allowed interleaving but didn't have a
mechanism to undo it at the receiver, would have to be protocol aware to
an extent that would be a layering violation. 

The particular example show doesn't cause a problem at the receiver
because the last segment of each message occurs in the right order so
the message completions in DDP and RDMAP will occur in the correct
order. However, one could have something else like:

Message 1 - tagged (e.g. the last RDMA data transfer of an SCSI Read
over iSCSI/iSER) FPDU frame TO = 0, L = 0, T = 1 FPDU frame TO = 1000, L
= 0, T = 1

Message 2 - untagged (e.g. the status message indicating that the SCSI
Read has completed) FPDU frame MSN = 0, M0 = 0, L = 1

If those frames were interleaved and sent:

FPDU frame TO = 0, L = 0, T = 1
FPDU frame MSN = 0, M0 = 0, L = 1
FPDU frame TO = 1000, L = 0, T = 1

RE: RE: [Ips] DDP message interleaving

Pat Thaler wrote:
> [This discussion seems more appropriate to the rddp reflector
> so I've copied that and suggest we move over there if more is needed]
> 
> Caitlin,
> 
> In the general case, the RDMAP protocol and the ULPs built on
> it are designed to rely on in order delivery of messages. A
> lower layer protocol that sends out of order but reorders
> before the packets leave the llp at the receiver (e.g. TCP
> retransmission of dropped packets) is okay. A lower layer
> level that allowed interleaving but didn't have a mechanism
> to undo it at the receiver, would have to be protocol aware
> to an extent that would be a layering violation.
> 
> The particular example show doesn't cause a problem at the
> receiver because the last segment of each message occurs in
> the right order so the message completions in DDP and RDMAP
> will occur in the correct order. However, one could have
> something else like:
> 
> Message 1 - tagged (e.g. the last RDMA data transfer of an
> SCSI Read over iSCSI/iSER) FPDU frame TO = 0, L = 0, T = 1
> FPDU frame TO = 1000, L = 0, T = 1
> 
> Message 2 - untagged (e.g. the status message indicating that
> the SCSI Read has completed) FPDU frame MSN = 0, M0 = 0, L = 1
> 
> If those frames were interleaved and sent:
> 

I-D ACTION:draft-ietf-rddp-security-09.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: DDP/RDMAP Security
	Author(s)	: J. Pinkerton, et al.
	Filename	: draft-ietf-rddp-security-09.txt
	Pages		: 56
	Date		: 2006-5-1
	
This document analyzes security issues around implementation and 
   use of the Direct Data Placement Protocol(DDP) and Remote Direct 
   Memory Access Protocol (RDMAP). It first defines an architectural 
   model for an RDMA Network Interface Card (RNIC), which can 
   implement DDP or RDMAP and DDP. The document reviews various 
   attacks against the resources defined in the architectural model 
   and the countermeasures that can be used to protect the system. 
   Attacks are grouped into those that can be mitigated by using 
   secure communication channels across the network, attacks from 
   Remote Peers, and attacks from Local Peers. Attack categories 
   include spoofing, tampering, information disclosure, denial of 
   service, and elevation of privilege.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-09.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

RDDP Draft status update

A brief summary of where our (the WG's) 6 outstanding
drafts stand:

The applicability and security drafts should be going
through IESG review (and hopefully approval) this month.

We should have Lars Eggert's comments on the RDMAP and DDP
drafts within the next week - at that point, I will want
the authors to rapidly revise the drafts to deal with those
comments and Jon Peterson's prior comments.  The resulting
draft versions should go to IETF Last Call this month.

A week or so after that, we should have Lars Eggert's
comments on the MPA and SCTP drafts.  If those two drafts
are revised quickly, they could also enter IETF Last Call
in May, and then there would be a good chance of getting
them through IESG review before the Montreal meetings.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david <at> emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

Tag offset question

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

RE: Tag offset question

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp

I-D ACTION:draft-ietf-rddp-mpa-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote Direct Data Placement Working Group of the IETF.

	Title		: Marker PDU Aligned Framing for TCP Specification
	Author(s)	: P. Culley, et al.
	Filename	: draft-ietf-rddp-mpa-04.txt,.pdf
	Pages		: 74
	Date		: 2006-5-31
	
MPA (Marker Protocol data unit Aligned framing) is designed to work
as an "adaptation layer" between TCP and the Direct Data Placement
[DDP] protocol, preserving the reliable, in-order delivery of TCP,
while adding the preservation of higher-level protocol record
boundaries that DDP requires.  MPA is fully compliant with applicable
TCP RFCs and can be utilized with existing TCP implementations.  MPA
also supports integrated implementations that combine TCP, MPA and
DDP to reduce buffering requirements in the implementation and
improve performance at the system level.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rddp-mpa-04.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rddp-mpa-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-rddp-mpa-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
rddp mailing list
rddp <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rddp