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

From: "Williams, Jim" <[email-masked]>
Date: Tue, 3 Jun 2003 10:43:28 -0400

> 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

The complexity and performance burden of the option
should be somewhere between negligible and zero if
done right.  Implementations are free to
always use CRC and always require remote end
to use CRC if the implementers wish.  The knob only
exists if implementers feel there is demand for it.
The administrator only needs to know about the knob
if he wants to use it.

The pragmatic issue is that a customer may come to us
and say, "We haven't seen a TCP checksum error in years,
but we are wasting 10% of our compute resources on CRCs.
Can you turn off the CRCs for us?"

We will of course say yes, regardless of whether the 
standard allows it or not.  But I would rather have
a mechanism to do this defined within the standard
than have to invent an ad hoc non-standard mechanism.
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 3 Jun 2003 10:08:28 -0500

On 6/3/03, Williams, Jim wrote:

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

Good points. What makes the proposal acceptable to me
is precisely that it can largely be ignored, and that
it does not even require any setup delay to negotiate
because the active side can simply send the first FULPDU
with a CRC before finding out whether the other side will
consent to suppressing CRCs.

But it would be best to view them as "knobs". If they exist,
and a stack have no ability to suppress CRCs at all is
clearly acceptable, they need to be destination dependent.
For example: try to suppress CRCs with destinations that
conform to this list of IP masks.

>than have to invent an ad hoc non-standard mechanism.

All valid arguments on why standards SHOULD be as
accomodating as possible.

One small disagreement: any customer who is wasting 10% of
their compute resources on CRCs is using the wrong algorithm
or has an amazingly underpowered processor.

But the degree of waste is only relevant if the cost of the
option is signifigant. As proposed, the cost of this option
is that some bits in the MPA Mode frame are allocated, and
that it has to be documented properly.

A "All CRCs All The Time" implementation does not even have
to *examine* those bits, it merely has to set its bits to
indicate that it will insist on CRCs. That's a compile-time
constant initializing a byte within a packet. A packet that
would have been sent anyway, and a byte that was part of the
packet anyway. You can't get options must cheaper than that.

Even for a *slight* advantage for *some* implementations,
that is a very low cost. I see no reason not to allow it.

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