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

From: "Uri Elzur" <[email-masked]>
Date: Sun, 8 Jun 2003 12:51:13 -0700

A. If the proposal is that it takes one side that requires CRC to
mandate CRC for the particular flow, it allows "knob' free
implementations for the side where CRC is always on. It still requires a
mechanism for the ULP to know this kind of HW is installed. How is that
achieved?

B. If one side can force CRC, how can the other side turn it off? Or is
the idea that that side will not initiate comm with CRC on but if
required by remote peer it will be supported??? So in any case the SW
needs to have the capability to compute/check CRC.

C. As mentioned below (is it really 10%..), I'm not sure the cost of CRC
in SW justifies all of this lengthy discussion. If it this was a real
heavy weight mechanism like line speed encryption, I can see the need
for an option.

D. not sure I followed the idea of destination masks, I guess this is
just for the side with optional CRC. This clearly adds additional
complexity (un-bound) to remember all destination and their preference.
Is it the right tradeoff?

Uri
-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]] 
Sent: Tuesday, June 03, 2003 8:08 AM
To: Williams, Jim
Cc: [email-masked]
Subject: RE: [rddp] CRC - rough consensus update

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

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.

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

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 9 Jun 2003 11:20:30 -0500

On 6/8/03, Uri Elzur wrote:

>D. not sure I followed the idea of destination masks, I
>guess this is just for the side with optional CRC. This
>clearly adds additional complexity (un-bound) to remember
>all destination and their preference. Is it the right
>tradeoff?

Destination masks are to indicate the set of Destination
Addresses for which end-to-end CRC32c equivalence applies.

If you claim that you have end-to-end CRC32c equivalence
for *any* destination then either your network doesn't
connect to much or you're lying.

It's more likely that end-to-end CRC32c equivalence will
only ever apply to the local network or a remote network
connected via IPsec.

Not that I expect folks to take much notice, but those
are the very environments where use of MPA/TCP is not
justified.

Caitlin Bestler