RE: MPA CRC check issue from San Diego

Wading through all the emails on this topic, I think the
rough consensus of the RDDP WG is that Paul Culley's proposed
new text for Section 1.1 is an acceptable solution to this issue:

	"MPA includes a CRC check to increase the ULPDU data integrity
	to the level provided by other modern protocols, such as SCTP 
	[RFC2960].  It is possible to disable this CRC check, however
 	CRCs MUST be enabled unless it is clear that the end to end
	connection through the network has data integrity at least as 
	good as a MPA with CRC enabled (for example when IPSEC is 
	implemented end to end).  DDP's ULP expects this level of data 
	integrity and therefore the ULP does not have to provide its 
	own duplicate data integrity and error recovery for lost data."

Specific disagreements with this text should be posted to the list.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Culley, Paul
> Sent: Wednesday, August 11, 2004 9:12 AM
> To: [email protected]
> Subject: [rddp] MPA CRC check issue from San Diego
> 
> 
> >From the San Diego Workgroup minutes:
> 
> 	iSER is a protocol that uses MPA (RDDP mapping to TCP) for
> iSCSI.
> 
> 	The iSER draft authors have found MPA's current CRC requirements
> 	text to be insufficient for iSER usage of MPA, and hence 
> 	currently impose stronger requirements. iSER requires that RDDP 
> 	provide at least CRC32-class integrity, but the current MPA
> draft 
> 	text allows CRC32C to be disabled in situations where that would
> 
> 	not be the result.
> 
> 	The RDDP WG's rough consensus has been that ULPs can assume at 
> 	least CRC-class integrity from RDDP. Hence the sense of the room
> 
> 	is that the MPA draft text needs to be tightened to do this and 
> 	remove the need for iSER to add requirements to MPA.
> 
> 	ACTION: MPA draft authors to propose specific new text on 
> 	reflector.
> 
> Current text (section 1.1):
> 	"MPA includes a CRC check to increase the ULPDU data integrity
> to 
> 	the level provided by other modern protocols, such as SCTP 
> 	[RFC2960].  This check may be disabled with agreement by 
> 	providers and administrators at both ends of a connection.  This
> 
> 	disabling of CRCs should only be done when it is clear that the 
> 	connection through the network has data integrity at least as 
> 	good as a CRC (for example when IPSEC is implemented end to
> end).  
> 	DDP's ULP expects this level of data integrity and therefore the
> 
> 	ULP SHOULD NOT have to provide its own duplicate data integrity 
> 	and error recovery for lost data."
> 
> Also section 5.2:
> 	"An MPA implementation MUST implement CRC support and MUST 
> 	either:
> 	(1) always use CRCs
> 	or
> 	(2) only negotiate the non-use of CRC on the explicit request of
> 
> 	the system administrator, via an interface not defined in this 
> 	spec.  The default configuration for a connection MUST be to use
> 
> 	CRCs.
> 	(3) The MPA provider at either peer MAY ignore its 
> 	administrator's request that CRCs not be used.
> 
> 	The decision for one host to request CRC suppression MAY be made
> 
> 	on an administrative basis for any path that provides equivalent
> 
> 	protection from undetected errors as an end-to-end CRC32c."
> 
> Section 5.2 appears to be sufficiently strong to deal with the iSER 
> issue.  The proposal is to modify the section 1.1 text as follows:
> 
> 	"MPA includes a CRC check to increase the ULPDU data integrity
> to 
> 	the level provided by other modern protocols, such as SCTP 
> 	[RFC2960].  It is possible to disable this CRC check, however
>  	CRCs MUST be enabled unless it is clear that the end to end
> 	connection through the network has data integrity at least as 
> 	good as a MPA with CRC enabled (for example when IPSEC is 
> 	implemented end to end).  DDP's ULP expects this level of data 
> 	integrity and therefore the ULP does not have to provide its 
> 	own duplicate data integrity and error recovery for lost data."
> 
> Paul R. Culley
> HP Fellow
> 281-514-5543
> 
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rddp
>