Internet Protocol Small Computer System Interface (iSCSI) Cyclic Redundancy Check (CRC)/Checksum Considerations
RFC 3385

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                       D. Sheinwald
Request for Comments: 3385                                     J. Satran
Category: Informational                                              IBM
                                                               P. Thaler
                                                              V. Cavanna
                                                                 Agilent
                                                          September 2002

       Internet Protocol Small Computer System Interface (iSCSI)
         Cyclic Redundancy Check (CRC)/Checksum Considerations

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   In this memo, we attempt to give some estimates for the probability
   of undetected errors to facilitate the selection of an error
   detection code for the Internet Protocol Small Computer System
   Interface (iSCSI).

   We will also attempt to compare Cyclic Redundancy Checks (CRCs) with
   other checksum forms (e.g., Fletcher, Adler, weighted checksums), as
   permitted by available data.

1. Introduction

   Cyclic Redundancy Check (CRC) codes [Peterson] are shortened cyclic
   codes used for error detection.  A number of CRC codes have been
   adopted in standards: ATM, IEC, IEEE, CCITT, IBM-SDLC, and more
   [Baicheva].  The most important expectation from this kind of code is
   a very low probability for undetected errors.  The probability of
   undetected errors in such codes has been, and still is, subject to
   extensive studies that have included both analytical models and
   simulations.  Those codes have been used extensively in
   communications and magnetic recording as they demonstrate good "burst
   error" detection capabilities, but are also good at detecting several
   independent bit errors.  Hardware implementations are very simple and
   well known; their simplicity has made them popular with hardware

Sheinwald, et. al.           Informational                      [Page 1]
RFC 3385                iSCSI CRC Considerations          September 2002

   developers for many years.  However, algorithms and software for
   effective implementations of CRC are now also widely available
   [Williams].

   The probability of undetected errors depends on the polynomial
   selected to generate the code, the error distribution (error model),
   and the data length.

2. Error Models and Goals

   We will analyze the code behavior under two conditions:

      - noisy channel - burst errors with an average length of n bits
      - low noise channel - independent single bit errors

   Burst errors are the prevalent natural phenomenon on communication
   lines and recording media.  The numbers quoted for them revolve
   around the BER (bit error rate).  However, those numbers are
   frequently nothing more than a reflection of the Burst Error Rate
   multiplied by the average burst length.  In field engineering tests,
   three numbers are usually quoted together -- BER, error-free-seconds
   and severely-error-seconds; this illustrates our point.

   Even beyond communication and recording media, the effects of errors
   will be bursty.  An example of this is a memory error that will
   affect more than a single bit and the total effect will not be very
   different from the communication error, or software errors that occur
   while manipulating packets will have a burst effect.  Software errors
   also result in burst errors.  In addition, serial internal
   interconnects will make this type of error the most common within
   machines as well.

   We also analyze the effects of single independent bit errors, since
   these may be caused by certain defects.

   On burst, we assume an average burst error duration of bd, which at a
   given transmission rate s, will result in an average burst of a =
   bd*s bits.  (E.g., an average burst duration of 3 ns at 1Gbs gives an
   average burst of 3 bits.)

   For the burst error rate, we will take 10^-10.  The numbers quoted
   for BER on wired communication channels are between 10^-10 to 10^-12
   and we consider the BER as burst-error-rate*average-burst-length.
   Nevertheless, please keep in mind that if the channel includes
   wireless links, the error rates may be substantially higher.

   For independent single bit errors, we assume a 10^-11 error rate.

Sheinwald, et. al.           Informational                      [Page 2]
RFC 3385                iSCSI CRC Considerations          September 2002

   Because the error detection mechanisms will have to transport large
   amounts of data (petabytes=10^16 bits) without errors, we will target
   very low probabilities for undetected errors for all block lengths
   (at 10Gb/s that much data can be sent in less than 2 weeks on a