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

 

Trying to get resolution on this topic. 

 

Here's what we currently have (ignoring the informative text):

 

Section 1.2 Protocol Overview

   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.

 

Section 5.2 CRC Calculation

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.

 

   The process MUST be invisible to the ULP.

 

 

My comments on the above:

 

-          Section 1.2. Stating normatively what the ULP SHOULD NOT do
doesn't seem appropriate. This should be lower-case text, not upper case

-          Section 5.2: Possibly remove all of the above text and
replace it with the following. Note I've also removed the MUST be
invisible to the ULP text. It seems strange to me to mandate that the
ULP can't see it - why shouldn't this be left to the implementation?

 

o        An MPA implementation MUST implement CRC support. The MPA
implementation MUST request CRCs be enabled during the MPA Startup Phase
unless there is a CRC32C equivalent level of end-to-end data integrity
verification (such as IPsec). 

 

 

Jim

 

 

 

________________________________

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

 

 

On Aug 13, 2004, at 3:42 AM, Jim Pinkerton wrote: 

	 

	  

	 

	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... 

	 

 

The key point that was somehow missed is this: 

 

ULP designers MUST NOT be concerned that they might be receiving less
than CRC-32C 

protection on an end-to-end basis. 

 

I thought that this was clear. 

 

There seems to be some concern that the ULP should even protect itself
against the 

possibility of the system administrators setting the network
configuration up incorrectly. 

Frankly, in an IP network that is impossible. 

 

Should the ULP also explicitly require the system administrator to set
up routing tables 

correctly? And DNS? What about "the system administator MUST allow all
required 

traffic to be passed by intermediate firewalls." 

 

The intent is that the LLP MUST provide a level of end-to-end error
protection that 

is at least as good as CRC-32c. 

 

Jim is absolutely correct that this requirement SHOULD be stated as a
performance 

goals, with a note that CRC-32c and IPsec are known to be safe. I
believe a 

cross-over Ethernet cable would also qualify. 

 

Another obvious destination that could suppress CRCs would be 127.0.0.1.


 

In any event, this would hardly be the first time that a requirement was
stated 

in terms of an acceptable solution. Building codes routinely require a
certain 

type of wood be used for floors, and occassionally state 'must support X
pounds 

per square foot" 

 

If it really bothers anyone that much, they should simply submit the
more formal 

statement of the requirement. Just be sure to explicitly state that
CRC-32C and 

IPsec both qualify.

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