Having seen something odd like that in practice, I overestimated the
probability of these problems.
It was also pointed out that iSCSI also makes it's CRC optional only if
there is some other mechanism (ESP, AH or some other high-integrity
transport) providing the data integrity. Partly this is because that
checksum is the same as used by Fiber Channel, and is therefore available
'for free' in some, but not all, hardware, so there needs to be another way
to integrity protect the data.
Andrew
--On Wednesday, January 08, 2003 11:10:44 -0800 "H. Peter Anvin"
<hpa@zytor.com> wrote:
> Followup to: <20030107053146.A16578@kerberos.ncsl.nist.gov>
> By author: Olivier Galibert <galibert@pobox.com>
> In newsgroup: linux.dev.kernel
>>
>> On Tue, Jan 07, 2003 at 01:39:38PM +1300, Andrew McGregor wrote:
>> > Ethernet and TCP were both designed to be cheap to evaluate, not the
>> > absolute last word in integrity. There is a move underway to provide
>> > an optional stronger TCP digest for IPv6, and if used with that then
>> > there is no need for the iSCSI digest. Otherwise, well, play dice
>> > with the data. Loaded in your favour, but still dice.
>>
>> Ethernet's checksum is a standard crc32, with all the usual good
>> properties and, at least on FE and lower, 1500bytes max of payload.
>> So it's quite reasonable. TCP's checksum, though, is crap.
>>
>> I'm not entirely sure how crc32 would behave on jumbo frames.
>>
>
> AUTODIN-II CRC32 (the one used by Ethernet) is stable up to 11454
> bytes. The jumbo frame size was chosen as the largest multiple of the
> standard IP payload size to fit within this number.
>
> -hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/