On Friday, June 5, 2015 6:40 AM, Michael Welzl wrote: > > ... > Just for clarification: this wasn't about whether the level of "protection > against > bit errors" as such is important or not: I think the level of protection is a > less > important item to cover in the first document because, given current protocols > (what this doc is about), you can't just switch it on or off - it comes with > a choice > of a whole protocol. So it's just a part of a protocol description - static > protocol > properties that come as a whole whenever you pick the protocol.
I don't think that applications care very much about the distinction between CRC32 and 16 bit checksum. The real distinction is between "some protection" and "cryptographic protection," as given for example by SSL/TLS on top of TCP. Obviously the 16 bit checksum 16 will let through more transmission errors than the 32 bit CRC, but errors can also happen "above" the checksum, during the various data manipulations performed by the transport protocols. They can also be due to overactive middleboxes that will change the data and then "fix" the checksum. Applications that are concerned enough about the integrity of the data are going to use crypto end-to-end. Which is an argument for taking a view of service definitions "from the application," rather than merely cataloging what TCP and SCTP can do today. -- Christian Huitema _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
