RE: [Tsvwg] SCTP Checksum Change to the IESG

["THALER,PAT (A-Roseville,ex1)" <[e-mail]>]

Dear Jonathan,

Getting data to and from a NIC generally involves going through a FIFO
crossing a clock boundary and some engineers design this crossing poorly
resulting in a circuit that occasionally passes the wrong data. It is
certainly possible to design the circuit so that it performs well and does
not exhibit this behavior. I've seen plenty of hardware that does it right.

I don't think that the statistic of 1 in 10,000 internet frames having a TCP
checksum error and a good Ethernet CRC indicates anything about the
prevalence of this kind of NIC error. Frames pass through middle boxes such
as routers where they are not covered by CRC and some portion of the errors
are occurring there. I know of cases where a middle box had internal bugs
that occasionally corrupted the data.

Even if this kind of error is a concern, I don't see how it is helped by
returning a CRC calculated by the checker. 

The concern in the existing draft seems to center on the checker, but the
hardware calculating the CRC to send with the packet is equally likely to
make an error as the checker receiving the packet. Whatever text is
developed should deal with both equally.

Probability of an undetected error due to an error by the CRC checker in the
NIC is:

 Pneterr * Pnicerr * Pcrcmatch

where 
Pneterr is the probability of an error to the packet on the network
Pnicerr is the probability that the NIC makes an error in the data over
which it calculates the CRC
Pcrcmatch is the probability that the CRC calculated over data with errors
matches the received CRC. As long as the probability of an error in the NIC
CRC checker is much less than one, this is much smaller than the probability
of an undetected error due to errors on the network alone which would be:

 Pneterr * Pcrcmatch

Since undetected errors by the CRC checker will be quite rare, an audit is
highly unlikely to catch the problem.

The most significant problem caused by errors in CRC offload hardware would
be errors in CRC generation.  If the CRC generator makes an error and the
retransmissions continue to use the same CRC rather than recalculating it,
then the frame will continue to get rejected. The secondary problem is that
errors in CRC checking will occasionally cause good frames to fail the CRC
check. 

I can see retaining the received CRC because it allows software to do a
double check that a packet which the hardware says failed CRC check really
did fail. I can see making the number of bytes processed through the CRC
generator and checker available to software (which I assume is what was
meant by "buffer size" in the draft), because a synchronizer error normally
results in processing extra bytes or dropping some bytes. If so, "buffer
size" should be changed to something like "number of bytes over which the
CRC was computed not including the received CRC" and should also be applied
to the generator. Buffer size in hardware often has little or no
relationship to frame size.

I can't see any purpose served by retaining the result calculated by the CRC
checker especially since that result will vary unless CRC checker
implementations are needlessly constrained.

Regards,
Pat Thaler



-----Original Message-----
From: Jonathan Stone [mailto:[e-mail]]
Sent: Friday, May 03, 2002 2:02 PM
To: Tuexen Michael; 'Scott Bradner'; [e-mail];
'[e-mail]'; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: [Tsvwg] SCTP Checksum Change to the IESG 



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

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