Subject: RE: [rddp] CRC - rough consensus update

From: "Barron, Dwight" <[email-masked]>
Date: Mon, 2 Jun 2003 14:36:51 -0500

> 
> I agree 90% of the software users will not care about the cost of CRC.
> It will be on for them and they won't even know it.  However, some
> users, especially in the early days, will notice the cost, and will
> not like the idea of being FORCED to pay it.  For those situations,
> being able to say `you get stronger integrity with this protocol, but
> you can turn it off if you REALLY need the performance back' is a huge
> help.  At that point, most of the 10% that notice probably won't even
> turn it off.
> 
> Forcefeeding a complete, new dogma in one lump just doesn't seem like
> the quickest road to adoption to me.
> 
> We should just stack the deck in favor of the dogma, but avoid having
> the argument.

Unfortunately, I don't believe we avoid having the argument. It will get re-argued
in every ULP working group, with the same ratio of people thinking RDDP end-to-end
data integrity needs to be better than TCP checksums to those thinking the performance
issues overwhelm adoption. Then they too will want to have an optional CRC.

The efficacy of TCP checksums vs. CRC has been well documented and quantifiable, yet
the performance impact of CRC vs. TCP checksums or even a criteria for establishing
an acceptable performance impact of CRC has been requested but none has been offered.

Regards,
Dwight

> 
> Steph
> _______________________________________________
> rddp mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rddp
> 
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 2 Jun 2003 15:11:07 -0500

On 6/2/03, Barron, Dwight wrote:

>Unfortunately, I don't believe we avoid having the
>argument. It will get re-argued in every ULP working
>group, with the same ratio of people thinking RDDP
>end-to-end data integrity needs to be better than TCP
>checksums to those thinking the performance issues
>overwhelm adoption. Then they too will want to have an
>optional CRC.

It's worse than that.

The farther up you go, the less efficient a CRC
implementation *can* be.

But as they are installed anyway you end up with
*more* CRC implementations, *none* of which are as
efficient as they could have been at the lowest layer
with end-to-end semantics.

That is why I thought we had a consensus that nothing
done in the way of making CRCs optional should ever
cause a ULP to consider adding its own.

The only reason for a ULP to add its own integrity checking
should be if they require something *more* than an
end-to-end CRC32 check.

Do we have agreement on that objective?

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Mon, 2 Jun 2003 13:46:29 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Caitlin Bestler
> Sent: Monday, June 02, 2003 1:11 PM
> To: Barron, Dwight
> Cc: Stephen Bailey; [email-masked]
> Subject: RE: [rddp] CRC - rough consensus update 
> 
> 

  I am sure that some ULPs will want to add their own integrity
  checks even if they are in fact weaker than CRC32. If you
  absolutely positively must not have data corruption under
  any circumstances, trusting a NIC that offloads integrity
  checks may not be what you want. The oft-quoted paper indicates
  that more often than not, corruption was introduced
  in the stack or in the NIC.

---

From: [email-masked]
Date: Tue, 3 Jun 2003 00:39:01 +0000 (UTC)

On Mon, 2 Jun 2003, Barron, Dwight wrote:

> Unfortunately, I don't believe we avoid having the argument. It will get
> re-argued in every ULP working group, with the same ratio of people
> thinking RDDP end-to-end data integrity needs to be better than TCP
> checksums to those thinking the performance issues overwhelm adoption.
> Then they too will want to have an optional CRC.

I thought what we were doing to do was say you either have a CRC, or you
have a link that the admin has promised is as reliable as a CRC.

> The efficacy of TCP checksums vs. CRC has been well documented and
> quantifiable, yet the performance impact of CRC vs. TCP checksums or
> even a criteria for establishing an acceptable performance impact of CRC
> has been requested but none has been offered.

I think talking about "performance impact" is the wrong way to go about
it. It's not when the "performance impact" of the CRC is ok, it's when the
link is reliable-enough w/o the CRC that you can skip it; it's not when is
it ok to turn on, it's when is it safe to turn off.

As for guidelines, they aren't easy to come up with, which is why we
haven't given them. And that's also why we're saying CRCs should be on
by default - you should show when you can relax things, not when you
should enable the CRC.

Take care,

Bill