Re: [Tsvwg] SCTP Checksum Change to the IESG

[Michael Tuexen <[e-mail]>]

Doug,

it was pointed out on the list the your HW can leave the packet 
untouched.
Leaving it untouched is covered by the ID.

Best regards
Michael

On Saturday, May 4, 2002, at 02:17 AM, Douglas Otis wrote:

> Jonathan,
>
> If there is a situation where hardware may fail to catch an error, then
> replicating the check in software can be used to ensure critical
> applications are less affected and are afforded end-to-end treatments.  
> The
> current recommendation, however, places the packet at risk when 
> specifically
> recommending modification of the header during a hardware checking 
> process.
> This recommendation furthers the problem by then requiring modified 
> software
> to then re-verify the packet.  The quality of the audit and the data is
> diminished with this recommendation.  High speed hardware will not 
> modify
> the packet and a status bit indicating a hardware CRC check condition is
> equivalent to any number of registers that must be compared for 
> equality it
> terms of providing a robust indicator.
>
> My experience found esoteric conditions related to the bus to qualify a
> discard of potentially affected packets.  Unfortunately, no particular 
> item
> can be mandated to ensure fewer hardware/system related errors nor will
> these recommendations extend universally to all implementations.  RFC 
> 2119
> makes it clear no implementation recommendation carries a MUST mandate 
> if
> unrelated to interchange.  There is no silver bullet, but perhaps the
> Hippocratic Oath says it best - [First do no harm.] "I will follow that
> system of regimen which, according to my ability and judgment, I 
> consider
> for the benefit of my client, and abstain from whatever is deleterious 
> and
> mischievous."  I doubt this belongs in the draft however. : )
>
>  -Doug
>
>
> On May 3, 2002 2:02 PM Jonathan Stone ([e-mail]) wrote:
>>
>> Dear all,
>>
>> Michael Tuexen and I have discussed the contentious text offline at
>> some length.  One example we addressed is a NIC with TCP checksum
>> assist in hardware.  The checksum assist in that NIC will occasionally
>> deliver incorrect TCP checksum indications for packets smaller than
>> the minimum Ethernet segment.
>>
>> I hesitate to say such bugs are commonplace, but they certainly
>> aren't' rare: both in current, shipping server-class hardware and in 
>> the
>> previous generation of bugs. The open-source community device drivers
>> show the history of first enabling TCP checksum assist, then disabling,
>> then finding workarounds or diagnostic tests which are cheaper than
>> the alternative: deciding the checksum-assist hardware is busted,
>> and ignoring it altogether.
>>
>> That is what the contentious text is saying. It is not saying
>> *anything* about how a hardware CRC assist should compute the CRC.  It
>> *is* saying that hardware assists for SCTP must provide some
>> additional ``audit-trail'' information on what the hardware really
>> did.  We can call that information ``CRC assist framing'': since it
>> leaves a record of where the CRC hw took its checksum value; the
>> length of the CRC computation; and the final result.
>>
>> That said, here's an attempt at some text which explains when, and
>> where, and why, that audit information is necessary:
>>
>> -----
>>    Errors in NICs and in outboard checksum acceleration have,
>>    historically, been commonplace. This document requires that
>>    hardware assists for the SCTP CRC provide more information than
>>    a single CRC-GOOD/CRC-NOT-GOOD bit.  Suppose that some particular
>>    NIC (or model of NIC) will occasionally give incorrect `CRC-GOOD'
>>    status for packets that are in fact damaged. In this scenario,
>>    GOOD/NOT-GOOD implementations give the SCTP software no recourse but
>>    to ignore the CRC assist entirely, and recompute the CRC of
>>    every packet in software.
>>
>>    This extra ``CRC-assist framing'' information  gives
>>    software the option to apply a cheaper audit of the CRC assist
>>    result based on the framing, before resorting to a software CRC.
>>    Such checks are commonplace in the installed base of TCP stacks
>>    using hardware- assisted TCP checksum.
>>
>>    Moreover, the CRC hardware assist, its associated NIC,
>>    and the NIC  device-driver will  in practice often
>>    be provided by a different vendor than is the SCTP stack.
>>    To ensure that the desired CRC-assist audit trail crosses the
>>    NIC-vendor/SCTP-stack-vendor boundary, this additional
>>    information is [currently] specified as a MUST.
>>
>> -----
>>
>> That isn't quite up to snuff for an I-D, but it will be soon:) and it
>> gets the idea across.  I hope Michael Tuexen will repost (or give me
>> permission to repost) an excerpt of our discussion.  I'm hoping that
>> together, those will resolve most of the contentiousness.
>>
>> An anecdote: when I gave a talk on the background data at SIGCOMM 2000
>> in Stockholm, it was a hardware person (not a software guy) who
>> commented that there was a `right' way and a `wrong' way to do
>> checksum-offload assists; and that the one-bit GOOD/NOT-GOOD result
>> was a bad way which should be discouraged.  For pretty much the
>> reasons I give here, and of which I walked through an explicit example
>> with Michael.  (To be fair, this was in a context of presenting data
>> showing that some 1 in 10,00 frame in the Internet pass their Ethernet
>> CRC, but fail the TCP checksum -- often in circumstances which point
>> squarely at bugs in NICs.)
>>
>> Even so, I'm surprised that this has been so contentious.
>>
>> --Jonathan
>>
>
>
> _______________________________________________
> tsvwg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tsvwg
>
>
[e-mail]


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg