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

From: Stephen Bailey <[email-masked]>
Date: Sun, 01 Jun 2003 10:49:09 -0400

> There will indeed be software stacks that are cleanly
> layered on top of existing TCP stacks.  But they will
> mostly be used for remote clients at low speeds.

I think cleanly layered software implementations will be 90% of the
initial RDDP connection endpoints.

I disagree that it's acceptable that they be `low speed'.  Pure
software TCP implemention run at high speeds today with a cleanly
layered implementation.

Hardware offload hardware will eventually take over the world.  We
piddled for a long time with PIO disk controllers (`nobody can use
more than x bytes/s of disk data, and the CPU can handle it easily'),
and eventually offload won.  This is no different.

The question is when.  A hard line position that makes RDDP
incrementally less attractive than the `incumbent' (straight TCP),
will slow RDDP's adoption.  Significantly?  For mandated use of CRC, I
think so.

I am claiming that optional-to-use CRC is technically defensible (not
technically superior), and will substantially ease adoption of the
technology.

There are vastly more communication users out there that understand
straight TCP than that understand RDDP.  If you require CRC, you will
have to explain to them:
  1) why their CPU overhead is noticably worse than
     straight TCP (`because you're getting much better
     data integrity, and the implementation isn't really
     optimized, mumble, mumble....'),
  2) why TCP's data integrity, on which they have relied all these
     years is actually dangerously inadequate.

Even in the very small community that understood the value of protocol
offload, it was slow (took years) to accept the advantage of generic
offload (RDMA) over application specific offload (SCSIs, ServerNets,
etc..).  RDDP is a `sell' to a much larger (and less informed)
community.

I agree 90% of the software users will not care about the cost of CRC.
It will be on for them and they won't even know it.  However, some
users, especially in the early days, will notice the cost, and will
not like the idea of being FORCED to pay it.  For those situations,
being able to say `you get stronger integrity with this protocol, but
you can turn it off if you REALLY need the performance back' is a huge
help.  At that point, most of the 10% that notice probably won't even
turn it off.

Forcefeeding a complete, new dogma in one lump just doesn't seem like
the quickest road to adoption to me.

We should just stack the deck in favor of the dogma, but avoid having
the argument.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 2 Jun 2003 10:59:00 -0500

On 6/1/03, Stephen Bailey wrote:

> The question is when.  A hard line position that makes
> RDDP incrementally less attractive than the `incumbent'
> (straight TCP), will slow RDDP's adoption.  Significantly?
> For mandated use of CRC, I think so.
>
> I am claiming that optional-to-use CRC is technically
> defensible (not technically superior), and will
> substantially ease adoption of the technology.

I think it is very important that consumers not be given
the impression that CRC protection is just something that
was thrown in to MPA as some sort of back door attempt to
improve TCP.

Without CRC protection, RDDP over MPA/TCP is *NOT* in any
merely plain TCP on steroids. Without the CRC, there are
distinct additional vunerabilities. There are indeed
specialized circumstances where the CRC is redundant,
but that is a determination that should be made with
extreme care. It is not something that should be selected
on the justification that "TCP has been good enough so far".

The specific extra dangers are:

-- RDDP will enable running far closer to wire capacity,
   even if implemented purely in software. More payload
   means more risk of payload with undetected errors.
   
-- RDDP and RDMAP interprets portions of payload themselves.
   Those headers are just as vunerable to undetected TCP
   errors as the ULP is. But it is far harder for the
   ULP to protect itself from these errors. Very precise
   methods of enabling and disabling STags must be followed.
   These are safety patterns that someone who thinks of this
   as "TCP on steroids" are likely to deploy correctly.
   
I sense a strong concensus for allowing CRC suppression when
the network truly provides the equivalent of end-to-end
CRC32c protection. The strongest scenario for this is when
most of the path is over IPSEC.

But I would be very opposed to any description of CRC
suppression which would in any way suggest that this option
should be turned on based on the justification that "TCP
checksums seem to work OK for our existing applications."

MPA/TCP without CRC can be dangerous. It should not be used
without careful evaluation.

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