Subject: RE: [rddp] Option or mandatory CRC in MPA

From: "Williams, Jim" <[email-masked]>
Date: Tue, 8 Apr 2003 20:17:17 -0400

The argument for making the CRC optional
in the RDDP over TCP mapping is the following.

  A.  A large percentage of usage will be on
      highly reliable private networks where
      the TCP checksum is more that sufficient
      the achieve the desired level or reliability.

  B.  Optimizing the performance of software 
      implementations is important, and computing
      an unneeded CRC is too high a price to pay
      for avoiding the need to negotiate an option.

The input from NFS is important because it takes
into account years of field experience.  If they
determine that for most all usage, even on private
networks, the TCP checksum is NOT adequate, then
I would regard that as a refutation of point A.
If they determine that for a large enough percentage
of implementations the TCP checksum IS adequate,
then I would regard that as support of point A.

Regarding point B, if one envisions that all 
implementations of interest are hardware customized
for RDDP, then the point does not carry much weight.
However, I would argue that this may be too narrow
a view for the IETF to take.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: David Robinson <[email-masked]>
Date: Wed, 09 Apr 2003 10:40:10 -0500

> then I would regard that as support of point A.

The argument can be made both ways from an NFS perspective.
In the last almost 20 years, there have been very few
complaints that have been attributed to checksum failure.
By far the dominant cause of corruption is simply
buggy software, generally the areas of caching and locking.

This can then be argued that it is not a concern
for NFS, further bolstered by the fact that for the
first 5+ years most deployments were relying only
on the link level CRC. But to counter that, given the
numbers for the failure rates determined by the research
in the area of TCP checksums and the fact that for the
first 10+ years the link speed was only 10Mbps, and only
the last couple years solidly at 100Mbps, statistically the
frequency of errors that would have gotten past the
checksum would be extremely small. At a bit rate of 10G
it could be argued that what has not been a factor in
the past will now be something we have to deal with.

 From a philosophical perspective NFS (and RPC) has always
been for strict layering.  If the underlying transport's
checksum is inadequate, just use a different transport. There
has also been great strides to make the choice of transport
automatically negotiated and transparent to both the user
and administrator. Most customers didn't even notice that they
were quietly switched from UDP to TCP over the last 5 years.
This would argue from an NFS purest perspective those that
are concerned about integrity will force use of SCTP or
other transport that has a stronger checksum. From a vendor
perspective I would likely try to negotiate SCTP first.

The other mitigating factor for NFS is its layered security
architecture which can provide added integrity checking. As
others have said, using a security integrity mechanism to
cover up a transport deficency is a 24ct gold plated solution
to a brass problem. But it is available today.  There is also
an effort to cleanly accomidate a lower layer connection
based security (IPSEC) using the existing RPCSEC_GSS framework
(CCM). This would allow hardware accelerated integity checking
through the security layers.

Overall, in my personal opinion, I would not use NFSv4 as an
argument for making CRC's in RDDP mandatory. NFS today already
has mechanisms that can mitigate any underlying transport
checksum problems. But this is not to say that NFS would not
use such a facility if available, of all the options available
it would probably be the most efficient.

At the core of this entire argument is the simple question
of is RDDP a transport to the ULP providing defined semantics
or is it just layer on top of an existing transport exposing
its semantics? Begging the question, if you don't like TCP
checksums why not just use a "real" transport? (He ducks....) :-)

	-David