Subject: RE: [rddp] Header CRC mandatory?

From: "Barron, Dwight" <[email-masked]>
Date: Fri, 2 May 2003 16:00:54 -0500

Jim, I would propose the following counter arguments:

A. I have not heard anyone proposing a 16-bit checksum for hardware centric implementations of any ilk in the last decade, which is less complex than a 32-bit CRC, even in hardware. This would include ethernet, FC, all flavors of VI of which I am aware, InfiniBand, IEEE-1394 and USB. To me, this implies that CRC is a comfortable baseline for data integrity, 16-bit checksums are not, even in the most high-volume, cost-sensitive environments like USB.

B. A chain is only as strong as its weakest link. I do not believe it appropriate to declare that ethernet's MAC CRC + TCP checksum is almost equal to an end-end CRC. The end-end integrity is that which can be guaranteed and delivered by the end-end digest method. As Caitlin pointed out, there is no shortage of low cost intermediary devices to mitigate any extra data integrity the MAC layer might provide. 

C. I agree that software implementations of RDDP are important and personally weight them as extremely important. Transmitter alignment is case in point where we have agreed to make changes to accommodate the widest latitude of RDDP software implementations. However, SCTP has set the precedence that mandatory CRCs are not prohibitive and do not short-change software implementations.

I believe that A, B, and C taken together point to established industry practice that clearly leans towards CRC over checksum for data integrity, despite the extra complexity/cost/overhead of implementation. Why shouldn't this place the burden of proof on those who oppose mandatory CRCs? That said, what would be the success criteria of number 4 below that would sway your opinion to be in favor of mandatory CRCs? I infer from your comments that CRC generation being on the same order of magnitude as the TCP stack is too much, zero CRC software overhead is impossible, what is acceptable?

Regards,
Dwight

> -----Original Message-----
> From: Williams, Jim [mailto:[email-masked]]
> Sent: Thursday, May 01, 2003 4:51 PM
> To: [email-masked]
> Subject: RE: [rddp] Header CRC mandatory?
> 
> 
> 
> I am not fully convinced either way as to whether
> CRC should be optional or mandatory.  I have seen
> some arguments for mandatory CRCs that
> I personally find less that persuasive.  This
> would include the following.
> 
>    1.  Users want the same level of protection for
>        both TCP and SCTP.
> 
>        Why?  Users want sufficient protection to
>        insure that silent data corruption does not
>        occur.  Naive expectation would be that
>        TCP provides 16 bit checksum and SCTP provides
>        32 bit CRC.  Which is required depends on 
>        deployment.  If you really want the same,
>        then SCTP should include a 16 bit checksum
>        in the RDDP mapping layer so that both
>        TCP and SCTP will have the combined protection
>        of both a 32 bit CRC and a 16 bit checksum.
> 
> 
>    2.  Performance of software implementations is
>        not important since most all implementations,
>        or at least most all implementations caring
>        about performance, will use hardware acceleration.
> 
>        This argument seems plausible, but also seems 
>        contrary to a previous consensus that
>        software implementations were important and
>        should not be short changed.
> 
> 
>    3.  Overhead to negotiate options is too onerous.
> 
>        Mechanisms need to be fully defined, but I think
>        there needs to be a round trip to negotiate use
>        of RDDP in the first place, so piggy-backing additional
>        negotiation items should have small incremental
>        cost.  If connection is born in RDDP mode by
>        use of well known port, then option negotiation
>        could be piggy-backed on TCP SYN packets.
> 
> 
> The following arguments have some merit, but I would
> like to see more data to back them up.
> 
>    4.  CRCs are not very hard to calculate in software.
>        They do not require an additional data touch.
> 
>        What is the overhead of a typical software TCP
>        stack?  For sake of argument, assume NIC offload
>        of checksum calculations.  What is the overhead
>        of a CRC computation?  How do these two numbers
>        compare (on a per byte basis).  My guess is that
>        they are the same order of magnitude which would
>        mean that CRC computation is certainly not
>        negligible.  But I could be wrong.
> 
>        As to no additional data touch, that seems possible
>        with an integrated implementation.  Not sure how
>        that could work with a layered implementation
>        of new RDDP code on top of existing TCP/IP 
>        implementation.  The latter seems like 
>        an important, if not more likely, scenario.
> 
> 
>    5.  TCP checksum provides inadequate coverage to
>        guarantee correctness.  This is certainly true
>        in some cases.  Is it true in most all cases?
>        Most common case for deployment of RDDP likely to
>        be two endpoints on the same LAN with 
>        one or two switches between.  Is TCP checksum
>        alone inadequate in this case given the link CRC?
>        My guess is that TCP checksum is adequate for
>        this case, but more data to shed light on this
>        would be helpful.
> 
>  
> _______________________________________________
> 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: Sat, 3 May 2003 12:51:44 -0500

Reviewing this thread, I am all but convinced that rddp is
not the correct forum for this discussion.

An argument can be made that the need for end-to-end CRCs
may be more an inherited superstition than a real need.
Maybe all need for it did disappear with the ISA bus.

But those issues are not specific to rddp. They apply
to reliable transports in general -- and there should
be a consistent policy on the subject. Whatever need
there is for end-to-end protection, it does not vary
based on the membership of specific Working Groups.

The last word from the transport working group on
the appropriate level of protection for a reliable
transport was that SCTP required CRC32C (RFC 3309).

I believe correct procedure would call for any deviation
from that wisdom to be based upon RDDP specific factors.
Shouldn't nny questions regarding the need for end-to-end
CRC protection, in general, be raised on tsvwg?

Similiarly, if a mandatory CRC32C is acceptable for SCTP
(where software implementations actually dominate), then
how can there be RDDP-specific reasoning that concludes
that CRC32C calculations constitute too much of a burden
on software implementations?

The only RDDP specific issue that I am aware of is that
there is a strong argument that the header protection
is *more* of a requirement for RDDP than for a conventional
transport. With a conventional transport *only* the
receiving buffer is ever at risk. With RDDP all other
buffers advertised for the Protection Domain are also
at risk. Whether or not a ULP chooses to trust its peer
is a ULP decision. The point is that for those ULPs that
do have trust, an unchecked RDDP header creates a new
risk that is not part of a non-RDMA transport.

But that, I believe, is ultimately irrelevant unless there
are valid RDDP-specific reasons for concluding that
mandatory CRC32C coverage of the entire payload is
unwarranted.

The arguments I have seen are *not* RDDP-specific.

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