Subject: RE: Optional CRCs ( was [rddp] Marker Interval )

From: "Barron, Dwight" <[email-masked]>
Date: Tue, 25 Feb 2003 09:57:34 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2003 8:44 AM
> To: Barron, Dwight; [email-masked]
> Subject: RE: Optional CRCs ( was [rddp] Marker Interval )
> 
> 
> Dwight,
> 
> > > I think if we are serious about supporting unmodified TCP, then
> > > the CRC should be optional.  NFS typically runs with only TCP/UDP
> > >
> > I think there is a significant delta between "serious about 
> > supporting" and "serious about optimizing for".
> 
> An alternate viewpoint is that "serious about supporting" includes
> "not placing unreasonable implementation requirements upon". 

But unreasonable from which perspective. If we were assuming symmetric implementations at each end, with roughly equal costs for performing a function, then optionality can be evaluated from end user trade-offs, usually functionality (like CRC) vs. performance or cost to implement or whatever. Asymmetric implementations mean that one end will (willingly) bear more of a burden for the benefit of the other. I have not heard nor seen any evidence that a CRC is an unreasonable burden to implement in hardware. It is standard practice for modern IETF protocols (SCTP), other modern storage and datacenter interconnect technologies (FC, IB). Why do we want to burden over-burdened administrators with yet another option (would you like data integrity with that?). Note that I am not trying to be unsympathetic to the needs and desires of efficient software implementations, I am trying to balance the realities asymmetric implementations and the need for optionality, both from an implement!
ation/test perspective and the end user administrator. 

> NFS
> as currently used does not need CRCs (although NFS did learn the
> hard way that turning on checksums was a real good idea), and ...
> 
> > > checksum for protection.  Not a good idea to do this over the 
> > > public internet, but then critical data traveling through
> > > the public internet will (or should) use IPSec protection.
> > > 
> > And where does the IPSEC processing power come from? I would be
> > willing to bet there is a large overlap of candidate environments
> > that need to run RDDP in unmodified software stacks that will
> > need to run IPSEC in that same unmodified software stack. IPSEC
> > is great in its own right, but is certainly not a good tradeoff
> > when a CRC would suffice.
> 
> To begin with, there's quite a bit of OSV support for IPsec in
> existing stacks today.  The point here is not that IPsec is
> computationally cheap (it's not), but rather that in an environment
> where IPsec is required for security policy reasons and the IPsec
> coverage is similar to the CRC coverage, the CRC may not be needed
> as the 96-bit IPsec MAC provides a considerably stronger integrity
> check - see Section 3.6 of draft-ietf-ips-security-19.txt.  As

The pervasive OSV support was exactly my point, unmodified existing software stacks. However, I have been told, but have not personally confirmed, that there is no easy/standard way for a ULP above TCP to discover if IPSEC is actually being invoked on a given connection with these existing stacks. If this is actually the case, then exploiting overlapping IPSEC/CRC coverage would seem to be left as yet another exercise for the administrator. 

> Jim Williams wrote:
> 
> > > iSCSI is a precedent for optional CRCs.
> 
> And there are two scenarios discussed above where the CRC does not
> appear to be required.

Again, these were/are very valid architectural decisions when software implementations were heavily weighted in the decision process. Hardware equivalent architectural decisions (e.g. FC) that carry the exact same class of storage traffic always have CRCs enabled. 

> 
> 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: "Somesh Gupta" <[email-masked]>
Date: Tue, 25 Feb 2003 10:13:25 -0800

Dwight,

We went through some similar debates in iSCSI with one camp
assuming primarily hardware based initiators and targets,
and the other group assuming a number of software based
implementations (I started off assuming hardware based but
switched later).

As it turns out, the adoption is being driven by software
based initiators and it is a good thing that the optionality
allowed software based initiators to avoid the features 
that would have made this avenue futile.

Perhaps there would not be so much debate if RDMA was focused
on IPC in the data center. But with storage being a primary apps,
it is important to enable this adoption route. Negotiated
options seem like a good engineering choice.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Barron, Dwight
> Sent: Tuesday, February 25, 2003 7:58 AM
> To: [email-masked]; [email-masked]
> But unreasonable from which perspective. If we were assuming 
> symmetric implementations at each end, with roughly equal costs 
> for performing a function, then optionality can be evaluated from 
> end user trade-offs, usually functionality (like CRC) vs. 
> performance or cost to implement or whatever. Asymmetric 
> implementations mean that one end will (willingly) bear more of a 
> burden for the benefit of the other. I have not heard nor seen 
> any evidence that a CRC is an unreasonable burden to implement in 
> hardware. It is standard practice for modern IETF protocols 
> (SCTP), other modern storage and datacenter interconnect 
> technologies (FC, IB). Why do we want to burden over-burdened 
> administrators with yet another option (would you like data 
> integrity with that?). Note that I am not trying to be 
> unsympathetic to the needs and desires of efficient software 
> implementations, I am trying to balance the realities asymmetric 
> implementations and the need for optionality, both from an implement!
> The pervasive OSV support was exactly my point, unmodified 
> existing software stacks. However, I have been told, but have not 
> personally confirmed, that there is no easy/standard way for a 
> ULP above TCP to discover if IPSEC is actually being invoked on a 
> given connection with these existing stacks. If this is actually 
> the case, then exploiting overlapping IPSEC/CRC coverage would 
> seem to be left as yet another exercise for the administrator. 
> 
> 
> > Jim Williams wrote:
> > 
> Again, these were/are very valid architectural decisions when 
> software implementations were heavily weighted in the decision 
> process. Hardware equivalent architectural decisions (e.g. FC) 
> that carry the exact same class of storage traffic always have 
> CRCs enabled. 
> 
> > 
> > Thanks,
> > --David