Subject: [rddp] CRC - issue E consensus call.

From: [email-masked]
Date: Fri, 23 May 2003 17:30:26 -0400

> I don't think this is an accurate characterization.  With 
> CRCs done below DDP/RDMAP, there is no concept of header and 
> data.  A single CRC covering the entire MPA payload maintains 
> layer separation and allows DDP/RDMAP to assume that the data 
> they receive from the LLP is a complete, CRC-protected 
> message regardless of whether the underlying transport is SCTP or TCP.
> 
> I thought there was some concensus building towards this position.

Possibly, but we're not there yet.  With the exception of there
being no need to support "CRC on data, no CRC on header", this
issue (B) [CRC coverage] is open.

With respect to my letters, I believe my prior statement that
there is WG rough consensus for (A) [MUST implement], (C) [usage
is bidirectional both-or-none], and (D) [either side can force CRC
usage] has held up.  I hereby augment that by stating that I
believe that there is WG rough consensus for:

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

augmented by:

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

The rationale for (E') is a desire to avoid ULP implementations
of additional integrity that is used only when the ULP detects
that it is running over RDDP over TCP without CRC.

I'd like to get this settled before circling back to (B} [CRC
coverage] and the related well-explored "one vs. two CRCs"
tarpit.  So, any disagreements with (E) or (E') need to be
posted to the list promptly.

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: Wed, 28 May 2003 16:02:44 -0500

On 5/23/03, [email-masked] wrote:

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

I would like to refine that as follows:

Administrative permission to suppress CRCs for a given
connection MAY be given if the paths over which the
connection will travel are known to provide the equivalent
of an end-to-end CRC32c protection, or meet other criteria
explicitly established for the ULP.

That is, there can never be less than the equivalent of
end-to-end CRC32c unless the ULP explicitly allows for this.
The mechanism for doing so would be out-of-scope.

I would also be comfortable with dropping the "or meet other
criteria explicitly established for the ULP." clause.

The important thing is that to be truly invisible to the
ULP, the ULP must be able to presume that its minimum
standards will be met. Further that standard is an
end-to-end CRC32c by default. An ULP MAY set a lower
standard, if it so desires. If a ULP wants a higher
standard, it provide its own supplemental solutions.

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

---

From: [email-masked]
Date: Thu, 29 May 2003 16:44:48 +0000 (UTC)

> criteria explicitly established for the ULP." clause.

What would be an example of, "other criteria explicitly established for
the ULP"?

> standard, it provide its own supplemental solutions.

Sounds fine.

I agree that if CRCs are off, that means that the admin has determined the
link is as safe as if the CRC were there (because if the admin hasn't made
that determination, CRCs should not be off). Both the ULP should trust the
admin is right and the admin should know what she or he is doing in
permitting them to not be used.

Take care,

Bill