Subject: RE: [rddp] Optimized Processing not necessarily Hardware Optimize d

From: "Williams, Jim" <[email-masked]>
Date: Fri, 11 Apr 2003 14:38:15 -0400

Caitlin Bestler wrote:
> As many have already argued, the need for payload validity
> checking increases with network speed. 

I have seen this stated, but missed the justification
for this.  Are you implicitly assuming that 
higher network speeds mean lower MTBFs?
(In this context a TCP checksum escape is a failure.)
It seems possible that this might be the case, but
not inevitable.  TCP checksum escapes are almost
always NIC or switch bugs, or bit errors on links
not protected by link CRCs.  The latter should
if anything become less common at higher speeds.
The former might or might not become more
common, but I would certainly hope to see less
of that.  Is there any empirical or theoretical
data supporting the assertion that the need
for validity checking increases with network
speed.

> First, the term "optional" CRC coverage is misleading.
> CRC coverage for the DDP header is mandatory.

Why is it more important to protect
the header than the data?  Bad header means putting
the right data in the wrong buffer.  Bad data means
putting the wrong data in the right buffer.  It seems
that both result in the exact same result in that
the application gets a buffer that has the wrong thing
in it.  

Usually silent propagation of bad data is about the
worst thing that can happen, but I am at a loss to 
understand why undetected bad headers are any WORSE
that undetected bad payloads.

> RDDP cannot
> responsibly place data directly into user buffers based
> soley upon TCP validation.

But it can place data whose correctness relies solely on 
TCP validation?  Why is there any difference?

> That would require the application to confine the Protection
> Domain to only those buffers that could be corrupted. With
> only TCP protection, all buffers exposed through the
> Protection Domain would be subject to being falsely
> overwritten by any flawed TCP segment that escaped
> detection.
> 
> Working around this would require additional Protection
> Domains, and hence additional connections. Clearly this is
> unacceptable.

Maybe I am being slow here, but I am not sure I follow.
Assume for sake of argument that there are errors that
escape TCP but no errors that escape CRC.

Without header CRC, all buffers exposed are subject to
corruption.  With header CRC, but no payload CRC, only
those buffers actually written by the remote end are
subject to corruption.

Why is the former worse than the latter, and why are 
we exposing buffers that are not written?  (These
are not rhetorical questions, there may be good answers.)

Anyway, I regarded the primary motivation for not
using CRCs to be that for many networks the TCP
checksum is sufficiently reliable given the characteristics
of the network and its reliability.  In this case,
TCP checksum escapes are totally unacceptable regardless
of whether they are header or payload.  But if they
don't happen, the CRC adds no value.

> This is additional complexity, and requires a mode-setup
> message exchange at the start of a connection (although
> one-way messages in each direction are adequate, so at least
> no additional round trip is mandated).

Weighing the complexity of supporting an
option versus the overhead of computing the CRC
in software when it is not needed seems like the
critical tradeoff to me.  The mode-setup may
be a non-issue if it required anyway for other
reasons.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Fri, 11 Apr 2003 14:45:43 -0500

>TCP validation?  Why is there any difference?

With a non-RDMA interface the only risk is the wrong data in
the correct buffer. Further, the correct buffer is
determined on a per-read basis.

When a read completes, the worst that can happen is that the
data in the buffer is bad. The application can do a quick
reasonableness check, and then proceed. Does it look like
MPEG-4 data? If so, play it. The worst that will happen
is noise. [And depending on the taste of the consumer,
that's the best that can happen too, ;)]

Without header checking *any* address that is open to *any*
STag valid within the Protection Domain is targettable by an
incorrect (and unchecked) DDP header. To be safe,
applications would have to very actively invalidate STags
after every received message.

Without at least CRC-32c protection on the header, a serious
argument could be made that RDMA over TCP posed an
unacceptable risk to system integrity and security.

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