Subject: RE: [rddp] Header CRC mandatory?

From: "Williams, Jim" <[email-masked]>
Date: Thu, 1 May 2003 17:50:45 -0400

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 1 May 2003 17:18:13 -0500

>       this case, but more data to shed light on this

Optimizing MPA for deployment within a data center, or other
environment with a minimal number of known network elements,
strikes me as fundamemtally wrong.

The first and foremost reason is that in an environment
where there are only a handful of known network elements
the transport that SHOULD be used is SCTP.

There are many market driven reasons for using TCP rather
than SCTP. But to date the only *technically* valid reason
I am aware of is to ensure interoperability with unknown
already deployed network elements that are SCTP
incompatible. In particular, the millions of home firewalls
are amost never SCTP compatible. It is unreasonable to
define a new service that requires end consumers to upgrade
their routers or switches.

Expecting a data center to upgrade the firmware on a handful
of in-house switches is quite a bit more reasonable.

If we were to design RDDP on the assumption of data center
deployment, then I believe there is stronger argumenet for
why TCP should not be a supported transport at all.

The justification for TCP is its compatability with older,
widely deployed, networking elements. Especially those that
do not have system administrators willing or able to upgrade
the firmware. And it is exactly such old, and typically
cheap, network elements that probably provide the strongest
justification for end-to-end protection.

Not to imply criticism for any specific companies or
products, but do you really expect five nines quality for
something that was in a clearance box for $39.99?

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

---

From: Caitlin Bestler <[email-masked]>
Date: Thu, 1 May 2003 17:46:26 -0500

>       of both a 32 bit CRC and a 16 bit checksum.
I doubt that the 16 bit TCP checksum adds much "value"
beyond the CRC32c.

The concern of providing different levels of protection
is that it will de facto encourage ULPs to design on
the assumption of TCP's weak protection.

Ultimately that makes the added protection from SCTP a
redundant cost, which could ultimately cited as a reason
against deploying it.

I believe that designing RDDP in a way that penalized
users of SCTP would be contrary to the intent and direction
of the Transport Area WG.

>       should not be short changed.

Agreed.

>       could be piggy-backed on TCP SYN packets.

Agreed.

A mode indicator, not necessarily a round trip, is a given
based upon points in the consensus (mode matching and
marker mode). So clearly a sender based option on what
CRCs it would be providing would be trivial.

Caitlin Bestler