RE: MPA CRC normative text (was DRAFT San Diego minutes)

 

You say potahto, I say potato... 

 

In other words, both, neither, and possibly anything in between.

 

In re-reading the spec, it would appear as though the specified behavior
is:

 

            An implementation MUST support CRCs

            An implementation MUST default to CRCs enabled (i.e. set the
C bit in the MPA Request/Reply)

            An implementation MAY disable CRCs if the system
administrator tells it to (but the implementation can ignore the
administrator).

            The process of override of the default MUST be invisible to
the ULP.

 

Thus we don't have a specific escape clause if a specific Stream has
IPSec enabled - but IPsec is generally enabled administratively, so to
get the same effective result with the above statements, the
administrator just has to take one additional step (enable IPSec,
disable MPA CRC). 

 

So what's missing? iSER has no guarantee that the administrator has not
turned off CRC (and not enabled IPsec). And it has no guaranteed way of
turning off CRC if IPsec is enabled, unless it calls itself a "system
administrator" rather than an application. Again, you say potahto, I say
potato.

 

I'm not sure this is broken folks...

 

 

 

Jim

 

 

 

________________________________

From: Somesh Gupta [mailto:[email protected]] 
Sent: Thursday, August 12, 2004 4:31 PM
To: Jim Pinkerton; Julian Satran; [email protected]
Cc: [email protected]
Subject: RE: MPA CRC normative text (was [rddp] DRAFT San Diego minutes)

 

Jim,

 

I think it is a mix of the application and the administrative
requirements.

 

I think an application so paranoid about its data integrity as to insert
an

end-to-end CRC or redundany (and I hope my banking app does that) will
benefit from

not having any other layer in the middle provide performance reducing

integrity from which it does not benefit.

 

And then there is security and reliability that one wants at the
infrastructure level.

That is best provided by administrative policy.

 

Is iSER an application or an infrastructure component?

 

Somesh

	-----Original Message-----
	From: Jim Pinkerton [mailto:[email protected]]
	Sent: Thursday, August 12, 2004 2:53 PM
	To: Somesh Gupta; Julian Satran; [email protected]
	Cc: [email protected]
	Subject: MPA CRC normative text (was [rddp] DRAFT San Diego
minutes)

	Renaming the subject line.

	 

	To me Somesh's point devolves into the classic argument of who
owns this issue - the application or the administrator? Personally, I
don't see why we should decide here. Saying the administrator has the
unique ability to dictate levels of error detection robustness when we
have a diverse set of protocols running on the system (SCTP, TCP, UDP,
RDMAP, etc) seems odd.

	 

	Another way of thinking about it is some applications are so
paranoid about error detection that they embed a data check in their
data - and take a perf hit because of it. Some applications that sit on
top of storage embed this all the way to the disk. They are perfectly
fine with trading off performance for the additional level of error
detection. To me this is a perfectly reasonable level of flexibility,
which the administrator doesn't necessarily want to get in the middle
of. 

	 

	Back to Jim William's points. I think Jim was primarily making
two points:

	 

	1) How to state the requirement? In David's original email, he
stated "at least 

	CRC32-class integrity" be used. And in Jim Williams email, he
stated "CRC32 is not a class of integrity, it is a mechanism for
providing integrity."  

	 

	I'd prefer that we don't resurrect the exact CRC-32C technical
requirements - seems like it is over specifying the interface (i.e. XX
sequential bit errors 100% detectable, up to YY non-sequential bit
errors 100% detected, etc, etc). What value does it add? And we aren't
the experts in any case. We know what MPA/SCTP gives us. Let's keep it
simple. Possibly something like "at least the same level of data
integrity verification as CRC32C"?

	 

	2) Why are we stating this as a requirement? I suspect there is
some truth in his argument. Options are bad, basic assumptions are good.
Look how UDP checksums evolved. In the early days, the checksum was
optional. That was changed to mandatory to implement, on by default,
because everyone wanted to know they had a data integrity check. I think
the same argument can be applied here. In the world of high-speed
networking and large data movement, checksum silent escapes are much
more probable. Thus the need for CRC32C level of integrity check verses
checksum. It's a lot tougher argument to make if telnet is the primary
application. But I don't see telnet as being the application that is
motivating the creation of a completely new transport protocol
(RDMAP/DDP). For similar reasons that UDP apps motivated UDP
implementations to turn checksums on by default (and it was an ugly
migration, if memory serves me correctly, between 1980's RFC768 and
1989's RFC1122), let's skip the ugly migration path and turn on CRC32C
or equivalent data checking by default.

	 

	 

	Jim

	 

	 

	 

	 

	
________________________________


	From: [email protected] [mailto:[email protected]] On
Behalf Of Somesh Gupta
	Sent: Thursday, August 12, 2004 12:28 PM
	To: Julian Satran; [email protected]
	Cc: [email protected]
	Subject: RE: [rddp] DRAFT San Diego minutes

	 

	Julian,

	 

	I think there is some validity to Jim's point. Maybe the
application is

	satisfied if there is end-to-end IPSec instead. And although
there is

	a point of how does the application know, it is really the
administrative

	policy that determines what level of reliability is good enough
or not.

	 

	Somesh

		-----Original Message-----
		From: [email protected]
[mailto:[email protected]]On Behalf Of Julian Satran
		Sent: Thursday, August 12, 2004 6:58 AM
		To: [email protected]
		Cc: [email protected]
		Subject: RE: [rddp] DRAFT San Diego minutes

		
		The reasoning behind this requirement was  that an I_T
pair may  want to negotiate CRC (or equivalent) as an e2e guarantee but
have no way of doing that if they use iSER. 
		
		Does it still look (or smell) as a red herring? 
		
		Julo 

[email protected] 
Sent by: [email protected] 

11/08/04 17:48 

To

<[email protected]> 

cc

 

Subject

RE: [rddp] DRAFT San Diego 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.
		
		This smells like a red herring.  CRC32 is not a class of
integrity,
		it is a mechanism for providing integrity.  Quantifying
integrity 
		should be done with metrics like mean time between
undetected
		failure or mean GB of data transferred between
undetected failure,
		not bits of CRC.  RDDP should provide the ULP with a
guaranteed 
		level of integrity, not guarantee a mechanism for
providing it.
		
		The case that iSER requires a higher level of
reliability that
		iSCSI or NFS seems like a difficult case to make (but
since I
		wasn't at the meeting, perhaps it was made effectively).
iSCSI
		and NFS do not require mandatory CRC.
		
		I suspect that the real reason is that all planned
implementations
		provide CRC for free, and options are a pain.  However
this it
		not a bad argument, so I am not troubled by the
conclusion.
		
		> --> Important Security Issue #1: IPsec - required or
optional?
		> 
		> A lengthy discussion ensued on this topic.  Important
points:
		> - For optional: IPsec can involve significant hardware
complexity.
		> - For mandatory: Some attacks can only be mitigated by
IPsec (WG has
		>                  little interest in designing its own
security mechanism), and
		>                  they will be of concern in some
deployment environments.
		
		OK, I'll be politically incorrect.  Running RDMA over
IPsec is
		sufficiently stupid that NOBODY will implement IPsec
regardless of
		how mandatory it is.  Just make it mandatory and quit
worrying.
		
		_______________________________________________
		rddp mailing list
		[email protected]
		https://www1.ietf.org/mailman/listinfo/rddp

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