RE: MPA CRC normative text (was 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