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

From: "Uri Elzur" <[email-masked]>
Date: Mon, 2 Jun 2003 23:17:50 -0700

No one suggests to turn off Ethernet CRC even if you can show the local
short link from a host to the next switch is error free. Why? It is in
the hardware and it is free, so why bother. It was probably as difficult
20 years ago running @10Mb/S. 

If we make it mandatory it will be implemented in products supporting
the outcome of this group's work. After some time, the impact for those
who do it in SW, will go away as more will use HW acceleration or simply
have faster CPU. On the other hand, we need be careful not to impose a
too strong of an impact for the transition period. That's why a
performance argument is interesting. 

If the _option_ to turn it off is there, it will forever add a
negotiation which slows down the initialization and adds complexity to
implementations. It will be yet another knob the administrator has to
deal with and no one showed there is a HUGE performance hit 

Uri

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

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

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

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
_______________________________________________
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: [email-masked]
Date: Tue, 3 Jun 2003 17:29:57 +0000 (UTC)

> 20 years ago running @10Mb/S.

So? I don't see how the fact that no one can nor would turn off the
Ethernet CRC matters here.

> performance argument is interesting.

Note: everyone is talking about CRCs being MUST implement, so they will be
implemented.

I disagree that the "impact" of a software CRC will ever go away. Yes,
CPUs will get faster & faster. But as they get faster & faster, people
will want them to do more; expectations will scale with ability. So
whatever impact the CRC has will still be there.

Also, we shouldn't talk about turning off the CRCs because of a transition
impact. We should talk about doing it because it's safe.

RDMA is a lot more sensitive to errors than tcp or sctp, mainly since we
use in-stream data to decide where to write the packet contents. And some
ULPs are more sensitive than others; ones with multiple buffers have to
worry about data going into the wrong buffer. ;-)

That's why we think disabling CRCs should be a per-port (ULP) kinda thing.
An admin can know, "Oh, this server only has one open buffer at a time,
turning off CRCs will be ok given our current network. That server has
multiple buffers open, better keep on CRCs," and set policy accordingly.

> deal with and no one showed there is a HUGE performance hit

Now I'm confused. You talk about not using CRCs above, yet you don't want
an option in-band to turn them off? How else would you turn them off? Just
arbitrarily flipping them off? That's scary...

We want a way in-band for either side to say, "We MUST use markers", so we
need a form of negotiation. We have it down to a statement-of-desire
negotiation. It's very simple, and closes in one round-trip.

Each side says, "I want this," in the first PDU, and then everyone knows
what's happening. We also have it down to where this won't slow down
initial data, either (to the extent data can flow before the client has
heard from the server). Since we will need an initial PDU anyway, using
one flag in it for CRCs-can-turn-off isn't a loss at all.

So I don't see what we loose from your discussion above by permitting CRCs
to be negotiated to off?

Take care,

Bill