Subject: RE: [rddp] One vs Two CRCs

From: "Uri Elzur" <[email-masked]>
Date: Thu, 21 Nov 2002 15:51:29 -0800

There has not been any argument as for the benefit of the additional CRC. The only argument I hear is implementation. "After listening to many NIC vendors" in the same meeting, one must reach the conclusion that many other vendors feel it is easier to implement one CRC. 

One CRC is computed the same exact way as an Ethernet CRC - do you mean to say the Ethernet CRC is harder to do then the 2 CRC scheme? 

A separate CRC forces checking the header CRC first (limit the implementation). IFT forces the implementation to find the beginning of the message (offset x into the Ethernet frame, varies from frame to frame!) and compute CRC for few header bytes
then compute Data CRC either as a split compute on the ingess or in one time on the egress. 

IPsec is fully supported by this architecture. Use of it has to do with security risks and there is no reason to mandate it when the user risk model is not mandating it.

Uri

-----Original Message-----
From: Somesh Gupta [mailto:[email-masked]]
Sent: Thursday, November 21, 2002 3:05 PM
To: Rddp
Subject: [rddp] One vs Two CRCs

After listening to the discussion after Jim William's
presentation at the IETF, I think that having two CRCs
is more flexible than having one CRC.

A single CRC restricts the implementation to one where
the check must be done in-line with the packet ingress -
which in turn implies many other design choices.

A separate header/payload CRC allows the CRC to be done
either at ingress, or at egress to the system. It does
not unduly constrain the implementations that want to
perform their checks only at the ingress. It allows both
unbuffered and buffered models. The only negative
being an extra 4-bytes.

I would suggest mandating the use of IPSec and
not having to worry about CRCs at this layer at all.

Somesh
_______________________________________________
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: Thu, 21 Nov 2002 19:03:06 -0600

On 11/21/02, Uri Elzur wrote:

>There has not been any argument as for the benefit of the
>additional CRC. The only argument I hear is
>implementation. "After listening to many NIC vendors" in
>the same meeting, one must reach the conclusion that many
>other vendors feel it is easier to implement one CRC. 
>
>One CRC is computed the same exact way as an Ethernet CRC
>- do you mean to say the Ethernet CRC is harder to do then
>the 2 CRC scheme? 
>
>A separate CRC forces checking the header CRC first (limit
>the implementation). IFT forces the implementation to find
>the beginning of the message (offset x into the Ethernet
>frame, varies from frame to frame!) and compute CRC for
>few header bytes then compute Data CRC either as a split
>compute on the ingess or in one time on the egress. 
>

There is no need for two checksum calculators, as long as it
is the same algorithm as used for the entire DDP Message.

In either case, you cannot begin the calculation until you
know where the framed PDU starts. In my estimation, this
will be done in hardware only when synchronization is
maintained and the FPDU is at the start of the TCP segment.

In any case, once you know where the framed PDU starts you
can begin the checksum calculation. The header is a fixed
size, hence the shift point is known. The CRC accumulator
would simply have to count, save the header checksum on the
side and reset to begin the payload calculation.

So this is highly feasible, even in hardware. The hard part
is finding the FPDU start. The extra CRC is simple.

Whether an additional four bytes *per header* is justified
is another question.

A partial DDP message cannot be presented to the DDP layer
until the header portion is validated. When there has not
been any resegmentation or fragmentation this will be at the
end of the TCP segment -- which is also when the entire DDP
message would complete as well.

So the extra CRC is only of value precisely when it is the
hardest to calculate CRCs. The benefit of placing the first
half of a DDP segment immediately would seem to apply only
for worst case analysis. My current preference is for more
bytes carrying actual payload.

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

---

From: "Somesh Gupta" <[email-masked]>
Date: Thu, 21 Nov 2002 22:15:43 -0800

Uri,

> From: Uri Elzur [mailto:[email-masked]]
> Sent: Thursday, November 21, 2002 3:51 PM
> To: Somesh Gupta; [email-masked]
> Subject: RE: [rddp] One vs Two CRCs
> 
> 
> additional CRC. The only argument I hear is implementation. 
> "After listening to many NIC vendors" in the same meeting, one 
> must reach the conclusion that many other vendors feel it is 
> easier to implement one CRC. 

  I don't know what the additional complexity is to do 2 over 1
  or 3 or whatever. If I was to sum 50 numbers in a row, if I
  sum the first two, and then the next 48 vs all 50, there is
  really no difference.
> 
> One CRC is computed the same exact way as an Ethernet CRC - do 
> you mean to say the Ethernet CRC is harder to do then the 2 CRC scheme? 

  Here is the difference. If I was guaranteed that everything is
  packetized, and aligned, things are really simple. However with
  TCP you cannot guarantee that payload header is aligned with
  packet header under the IETF agrees to make the appropriate
  changes (I am all for it). So regardless of the framing protocol
  (remember that in my note I said nothing about the framing protocol
  only about CRCs), the begining of the frame header has to be found.

  Once it is found, I don't see what additional complexity is added
  to a design that does the CRC check in the ingress path if there
  are two CRCs vs one vs n.

  I am merely trying to point that two CRCs support both designs
  where CRC check is done on the ingress and no buffering is done
  or where CRC check for payload is done on the egress. It
  allows more flexibility in design and is really neutral to the
  design choice.

  I really don't see where two CRCs add additional complexity to
  any design.
> 
> A separate CRC forces checking the header CRC first (limit the 
> implementation). IFT forces the implementation to find the 
> beginning of the message (offset x into the Ethernet frame, 
> varies from frame to frame!) and compute CRC for few header bytes
> IPsec is fully supported by this architecture. Use of it has to 
> do with security risks and there is no reason to mandate it when 
> the user risk model is not mandating it.
> 
> Uri
>