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

From: "Talpey, Thomas" <[email-masked]>
Date: Wed, 28 May 2003 17:24:27 -0400

At 02:35 PM 5/28/2003, John Hufferd wrote:
>So, lets propose that based on the perceived fact 
>that SW overhead is NOT an issue, we just say that the requirement from the 
>iWARP layers is to provide to the ULP protection at least as strong as that 
>provided by CRC32c.   
...
>If the above is reasonable, then since we have stated that if either side 
>wants it, the CRC must be sent.  And if a side can not tell if it has IPSec 
>Encryption but the other side can and says that it does not want the CRC, 
>then don't generate the CRC.  However, if the other side does not explicitly 
>say it does not want the CRC, then it should be provided. 

If overhead is not an issue, then what difference does it make whether the
CRC is included or not? In other words, why bother to negotiate leaving it out?
Just calculate it and let the receiver decide whether to pay attention.
Everyone wins.

This has been my point, at least.

Tom.

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

---

From: Michael Krause <[email-masked]>
Date: Wed, 28 May 2003 15:11:47 -0700

>Just calculate it and let the receiver decide whether to pay attention.

Making this a receiver issue to check or not seems like a step in the right 
direction.  KISS is preferred over negotiation (round-trip latency, 
complexity, etc.).

Mike

---

From: [email-masked]
Date: Thu, 29 May 2003 17:00:23 +0000 (UTC)

> Just calculate it and let the receiver decide whether to pay attention.

Because overhead is an issue. It will always be an issue. I think everyone
here agrees that a CRC32C is well worth its overhead price on top of plain
TCP, so that by choosing it we aren't shooting ourselves in the foot. But
if we have done something else, say IPsec, that gives us better than
CRC32C protection, why not let the CRC32C be skipped for the
implementations that can notice the improvement?

While calculating the CRC may be easy for a recent CPU, if you are
handling thousands or tens of thousands of connections, you want to skip
any calculation/step you can.

Take care,

Bill

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 29 May 2003 12:17:38 -0500

On 5/29/03, [email-masked] wrote:

>While calculating the CRC may be easy for a recent CPU, if
>you are handling thousands or tens of thousands of
>connections, you want to skip any calculation/step you can.

Actually the number of connections is almost irrelevant. The
question is how many packets can be received during a given
short time window. It doesn't take that many connections for
that number to approach the NIC's peak rate.

So either the CPU has to have the capacity to deal with
performing the CRC32c calcualtion at wire speeds, or it
has to have sufficient system buffering to allow a slower
CPU to catch up with a lower sustained rate.

External memory access is more likely to be the limiting
factor than a calculation that can be performed entirely
in system registers and/or cache. So the scenario where
these savings would seem to apply is one where the host
*can* keep up with the wire speed, but would prefer to
reallocate that processing power to other tasks when
possible.

The most relevant that comes to mind is terminating IPSEC
within the same processor. Having consumed general CPU
power to terminate IPSEC, the "available processing power"
pool is already low. So calculating the CRC32 again would
indeed be wasteful.

However, I do not think this is a very likely deployment.
The "wire speed" out of a software IPSEC stack that uses
the general purpose processor for decryption is unlikely to
be anything near "wire speed".

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

---

From: [email-masked]
Date: Thu, 29 May 2003 18:14:32 +0000 (UTC)

> that number to approach the NIC's peak rate.

Very true.

> reallocate that processing power to other tasks when

Exactly.

> be anything near "wire speed".

Even if it's not CPU power, just saving bus access could be a win. ;-)

I know of support chips coming out that will do CRC checking for the CPU,
but they will still need to have the packet(s) traverse the system bus.

Take care,

Bill

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 29 May 2003 11:50:06 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Thursday, May 29, 2003 11:15 AM
> To: Caitlin Bestler
> Cc: [email-masked]
> Subject: RE: [rddp] CRC - rough consensus update
> 
> 

  IPSec will be one of the next things to be offloaded in the NIC.