Subject: [rddp] CRC mandatory to use?

From: [email-masked]
Date: Fri, 6 Jun 2003 19:33:22 -0400

I've gone back over the past couple of weeks of email traffic
on this issue.  Let me first deal with a few red herrings:

- The "negotiation causes delay" assertion has resurfaced.
I hope Caitlin Bestler's explanation (Tuesday, 6/3) will
finally lay this one to rest:

  There seems to be an impression that MPA options will
  require a round-trip. This is not the case. All of the
  MPA Options discussed to data can be implemented "for
  free" within the MPA Mode frame that was mandated to
  ensure that MPA/TCP connections could not be confused
  with TCP connections.

The model the WG is heading for is more of an announcement
(of capabilities/preferences/requirements) than a negotiation
model - traffic can be sent immediately behind the initial
announcement, and if the announcements are incompatible (and
unrecoverably so), the connection closes.  The WG has been
headed for this sort of model (and not negotiation round
trips) since last fall's Atlanta meeting - would the advocates
of "MUST USE CRCs" kindly stop demolishing this strawman?

- There's been some discussion about how decisions made here
will constrain future actions of other WGs that use RDDP.
While a MUST in a specification applies to use of that
specification by reference, it does not constrain another WG
that adapts RDDP for its own use based on its best technical
judgment for that use.  The IP Storage WG did this for IPsec
for a number of reasons, and the final result was that some
"SHOULD"s and "MUST"s from the underlying IPsec RFCs became
"MAY"s and even "SHOULD NOT"s (e.g., DES usage).  Based on
this example, it would be wrong to assume that we can impose
our technical judgment on all uses of RDDP for all time.
We can explain clearly why we did what we did, and hope that
future engineers will see the wisdom of our ways, but the
notion that a MUST here will settle this issue for all time
and in all circumstances is naïve - we surely do not have a
permanent monopoly on serious interest in this area.

- I saw an assertion that RDMA is just a remote extension of
local DMA.  While that may be valid for consideration of
level of integrity protection, it's rather wrong in general
over the Internet.  The analogous assertion that RPC is just
a remote extension of local procedure call has caused a lot
of bad distributed systems design.

- There seems to be some confusion over IPsec security properties.
Encryption by itself provides no additional integrity properties.
IPsec provides both encryption and cryptographic integrity
(keyed HMAC), and the security community is now of the general
opinion that encryption should in general not be used without
some sort of cryptographic integrity check.  When IPsec integrity
is in use, the result is generally much stronger than a CRC (hint:
ESP uses 96 bits of HMAC) - when it's in use with sufficient coverage
(e.g., one is not worried about risks of corruption between end
systems and their IPsec offload engines), there's little added
value to a higher level CRC.

Overall I'm struck by the almost absolute certainty that the
advocates of "MUST use CRCs" seem to exhibit in predicting and
scoping the usage of RDDP.  Past experience with protocols of
general utility indicates that it's hard to predict all the ways
in which good new tools will get used.  An example to think about
is that RSVP was originally designed for setup of QoS-enhanced
paths for IP traffic.  I don't believe its designers anticipated
RSVP's most common use today - MPLS label-switched path setup -
but they designed enough flexibility into RSVP so that it could
be adapted for this purpose (for which it is now the predominant
mechanism).

From a process standpoint, it's clear that my initial attempt to
call consensus on (E)+(E') has failed:

(E)	CRCs are OPTIONAL to use, but (per (D) above),
	either end of the connection can force CRC
	usage in both directions.

(E')	CRC usage is an administrative configuration decision
	- it is not intended to be visible to ULPs.

OTOH, it is also clear to me from the ensuing discussion that
WG rough consensus for CRCs being mandatory to use will not be
obtained.  There have been some useful elaborations on (E') from
the discussion, which I'm not going to try to capture here.

It still appears to me that (E) and (E') are the only realistic
way to make forward progress.  This is based in part on my view
of the technical discussion - from what I can see, stronger
technical points are being made in favor of (E) and (E') by
comparison to the MUST use CRCs position.  A significant portion
of the latter seems to be: "I'd never ever disable CRCs in any
RDDP system I design", which is consistent with (E) and (E'),
unless we're going to go back to the "all options are evil"
nonsense (please don't ...).  Everyone's entitled to their own
design judgment, but let's not go overboard in constraining
the ability of others to exercise their own judgment in a
fashion that reaches different conclusions.

For further discussion ... not that anyone needs that
encouragement ...

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 6 Jun 2003 19:59:02 -0500

On 6/6/03, [email-masked] wrote:

>(E')   CRC usage is an administrative configuration
>decision - it is not intended to be visible to ULPs.

I'd like to propose some refinements on (E') in order
to clarify discussion of issues.

(E1) 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.
     
(E2) The required standard to allow a request for CRC
     suppression MAY be lowered on a per ULP basis.
     If the ULP takes no explicit action to lower the
     standard it MUST remain being the equivalent of
     an end-to-end CRC32c.
     
Even if non officially blessed a form of E1 could end
up being implemented without official blessing under
a "No Harm No Foul" line of thinking. I strongly agree
with Jim Williams' point that we are better off having
this occur in public, where the standard is clearly labeled.
Without such a rule we may encourage vendors to create
such a shortcut when interoperating with their own RNICs.
Adopting a formal rule ensures interoperability and a
even playing field.

E2 is more expansive, and covers the widest range of
suppression that has been suggested without undue risk.
The key is that it assures that there is nothing the
ULP has to check to ensure that the standard has not
been lowered. And most importantly, we have given no
ULP designers a reason to add their own protection
based upon any perception that protection is "optional".

Now, if they plan to add their own 256-bit protection,
they might decide that its plain silly to keep the
32-bit MPA check. I don't have a problem with that.
What I think we all want to avoid is a discussion
that goes something like "Should we add our own
CRC? I remember something about MPA having optional
protection, and I can't find the API to make sure
its turned on."

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: [email-masked]
Date: Sun, 8 Jun 2003 00:40:36 +0000 (UTC)

>      The process MUST be invisible to the ULP.

Of the two, I like this one better. It keeps the idea that there SHOULD be
the equivalent of CRC32C the whole way.

> protection, and I can't find the API to make sure

I agree with wanting to avoid that discussion if possible. The guidelines
on when to turn off CRCs should help avoid it. I hope. :-)

Take care,

Bill