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

I'm not sure I am seeing a real disagreement here per se.  I think 
everyone is agreeing that, a) iSCSI's CRC need (if negotiated to Yes) 
cannot be met by the iSCSI/iSER stack [or _any_ ULP stack in a similar 
position] without requiring the same from MPA, b) stay away from 
options/profiles if possible, c) MPA CRC should allow being turned off 
if there's IPSec/similar protection underneath.

If someone doesn't agree with the above, I'd of course like to know 
where the disagreement is.

Paul Culley's proposed text in his email on 8/11/2004 fixes section 1.1, 
which was originally somewhat out of sync with the strength of language 
in 5.2.  I think the proposed text syncs up the two sections and meets 
the first-order concern expressed by the iSER folks, though some finer 
wordsmithing may be possible.
-- 
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com


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