Subject: [rddp] CRC Rough Consensus recap

From: [email-masked]
Date: Wed, 9 Jul 2003 19:58:39 -0400

I thought I sent this out to the list a week or so ago,
but some helpful mailer seems to have found it entirely
too tasty ...

I believe the following items represent the rough consensus
of the RDDP WG on CRC requirements for the TCP mapping
of the RDDP protocols:

(A) CRC support MUST be implemented.

(B) CRC usage is all-or-nothing on header and data.
	There is no requirement for CRC on header but
	not on data or CRC on data but not on header.

NB: This does not imply that there is a single CRC
	vs. split header and data CRCs, as there are some
	additional issues bearing on this.

(C) CRC usage is bidirectional.  Either CRCs are used
	in both directions on a connection, or in neither.
	There is no requirement for CRC usage in one
	direction and not the other.

(D) CRC omission requires consent of both ends of the
	connection.  If either end of the connection
	specifies that CRCs are to be used, then they
	MUST be used [in both directions (C)].  This entails
	some sort of mechanism to enforce CRC usage when
	the two ends of the connection start out with
	different preferences (or break the connection
	if the different preference have created a
	situation from which it is impossible to continue).

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

This represents an affirmation of the consensus calls on
(B), (E) and (E'), as I have seen no objections to them
since they were posted.

As noted earlier, there has been considerable elaboration
on (E') - the right place to capture that elaboration and
tell ULP implementers what they should expect and assume is
the applicability statement (draft-ietf-rddp-applicability-00.txt).
Please keep this in mind in reviewing that draft for discussion
in Vienna.

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: "Mallikarjun C." <[email-masked]>
Date: Fri, 11 Jul 2003 16:30:34 -0700

David,

Can you please provide a couple of clarifications on two
concerns I have?  Apologies in advance for the somewhat 
late request, and also if there is some other relevant discussion 
that I haven't followed (I admit I didn't closely follow them all) 
here.

Based on some early discussion, I had assumed that the 
ULP designers can safely assume a CRC-level data integrity 
from an RDMAP/DDP/MPA/TCP stack.  In reading the A-E' 
calls (that is, if I understand them as intended), I am seeing two
aspects that somewhat concern me because these doesn't seem 
to assure ULPs in making that safe assumption.

a) The "not visible to ULPs" wording in E'.  I understand 
    the administrative configuration part and the discussion that
    went into it.  Can you please confirm that despite this wording,
    ULP designers will be on a sure footing in assuming a CRC-level 
    integrity?

b) Even while stating that the CRC implementation is a MUST,
    this set of consensus calls is clearly allowing the implementations
    to drop the connection ("break the connection if the different
    preference have created a situation from which it is impossible
    to continue") if the other side forces the usage of MPA-CRC .
    IOW, as I read this, there's no such thing as a "default" or guaranteed
    CRC-supported operation anymore (as I had originally understood
    the early discussion).  Can you please confirm that this text again
    doesn't preclude the ULP designers in making that safe assumption?
    [ i.e. the side that didn't want MPA CRC chose so only because 
      it knew that there's a comparable level of assured data integrity 
      for the data path ]

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668
Roseville CA 95747
[email-masked]

>To: [email-masked]
>Subject: [rddp] CRC Rough Consensus recap
>From: [email-masked]
>Date: Wed, 9 Jul 2003 19:58:39 -0400
>List-help: <mailto:[email-masked]?subject=help>
>List-id: IETF Remote Direct Data Placement (rddp) WG <rddp.ietf.org>
>List-post: <mailto:[email-masked]>
>List-subscribe:
<https://www1.ietf.org/mailman/listinfo/rddp>,<mailto:[email-masked]?subject=subscribe>
>List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/rddp>,<mailto:[email-masked]?subject=unsubscribe>
>Sender: [email-masked]
>
>--------------------------------------------------------------------------------
>

--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

---

From: [email-masked]
Date: Mon, 14 Jul 2003 03:20:17 -0400

Mallikarjun,

> concerns I have?

Sure, [... snip ...]

>     ULP designers will be on a sure footing in assuming a CRC-level 

(E') was not the end of the discussion, as there has been subsequent
elaboration.  In any case, I believe the answer is yes and (as
indicated in my original message) this should be stated and explained
clearly in the applicability draft -- the place to tell ULP
designers what to expect/assume about RDDP.

>     to continue") if the other side forces the usage of MPA-CRC .

If an implementation always does this, the implementation violates
(D)'s requirement that both ends of the connection consent to CRC
omission (in essence the implementation is saying "I will only
talk to you if you agree to omit CRCs", which is not permitted by
(D) ).  **If** the mechanism that realizes (D)'s requirements on
CRC usage has cases in which the connection must be dropped due
to incompatible CRC usage preferences, then a requirement is
needed to cause some subsequent connection attempt to succeed - a
likely way to accomplish this would be to force both sides to
express a preference for CRCs on retry when a connection is
dropped due to incompatible CRC usage preference (but note
the "**If**" above).  I think forcing CRC usage when there's
doubt is safer than trying to figure out when to believe
the other end's view of connection quality.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun C. [mailto:[email-masked]] 
> Sent: Friday, July 11, 2003 7:31 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: CRC Rough Consensus recap
> 
> 
> David,
>