RE: CRC rough consensus from Vienna

Unfortunately, I was not able to make it to Vienna,
so my comments below may echo the discussion
that already took place.

> From: [email protected] [mailto:[email protected]]
>
> The discussion that is the basis for this rough consensus
> acknowledges that there are some advantages to the split CRCs,
> principally that the header CRC can be verified without waiting
> for the data, especially if the data spans more than one packet.
> The principal downside is increased complexity of two CRCs.
> The advantages of two CRCs are not overwhelming, as for aligned
> traffic, the data and its CRC will arrive immediately, and in
> the unaligned case, an implementation that wants to use the
> header for immediate placement without waiting for a second
> packet will be able to verify the TCP checksum before placement.

If it is acceptable for an implementation to place data based
on a header that has been validated only with TCP
checksum (not yet with CRC), then I am fine with this approach.
Emphasis on "acceptable", not just "allowable".

> It is also ok in an error case to tell the ULP that "something
> went wrong, the data in the buffer you handed to RDDP for placement
> is invalid as it may have been overwritten in part" - the TCP
> connection on which this happened will generally be terminated
> in this case.

OK, but this still may be a serious error.  Theoretically,
a buffer may be completed, and returned to the ULP.  While
the ULP is using it, it is erroneously overwritten.  The
ULP uses the corrupt data.  Only later when the
CRC arrives is the ULP notified that the data was bad.

On the other hand, if there is a TCP checksum escape, the
conditional probability that an error occurred in the RDDP
header STag or offset, AND that the header is still valid
and passes protection checks, AND that the buffer
is currently being used by the ULP is low.  So the 
protection is much better than the TCP checksum alone.

For writes that appear untagged, the ULP will not see
the data until the CRC has been checked, so no problem. 

> This does not appear to rule out or unfairly disadvantage any
> important classes of implementations.  My recollection of past
> discussion is that I need to call this rough consensus over Jim
> Williams's objections, but comments from Jim and anyone else who
> takes issue with this position should be sent to the list.

I believe the above has satisfactorily addressed any issues
that I have.

> Thanks,
> --David