Subject: [rddp] CRC rough consensus from Vienna

From: [email-masked]
Date: Mon, 21 Jul 2003 15:15:58 -0400

I'm just catching up on sending what happened in Vienna
to the list.  Sorry for the delay, but a significant
piece of the explanation is at:

http://money.cnn.com/2003/07/21/news/international/ba_strike.reut/

although they left out the part about thousands of pieces
of luggage (including mine) going astray - my wife and I spent
an unexpected night at a Heathrow airport motel without our
luggage.

Nonetheless, here's what I believe is the WG rough consensus
to the last (I hope!) open CRC issue - one vs. two CRCs for
the TCP mapping of the RDDP protocols.  For anyone keeping
track, this issue is hereby tagged as CRC issue (B1).

After discussion in Vienna, I believe the WG rough consensus
is for a single CRC rather than separate header and data CRCs.

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.

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.

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.

Thanks,
--David

----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: "Williams, Jim" <[email-masked]>
Date: Mon, 21 Jul 2003 18:19:57 -0400

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

> From: [email-masked] [mailto:[email-masked]]
>

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".

> connection on which this happened will generally be terminated

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. 

> takes issue with this position should be sent to the list.

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