Re: Issues concerning 10GbE speed standards

[Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>]

Ed,

I disagree with your assertion that "Error correction can not be used to claim
the BER is improved.". This is EXACTLY what error correction does, and it does
so essentially for 'free', depending on the PHY technology employed. The
following a a good summary of the advantages of error detection and correction.
I am extracting it from a primer on Reed-Solomon Error Correction Codes which
can be found on the Advanced Hardware Architectures web site:
http://www.aha.com/pubs.htm#fec

THE ADVANTAGES OF ERROR DETECTION AND CORRECTION (EDAC)

EDAC has a number of advantages for the design of high reliability digital
systems:

1) Forward Error Correction (FEC) enables a system to achieve a high degree of
data
reliability, even with the presence of noise in the communications channel. Data

integrity is an important issue in most digital communications systems and in
all
mass storage systems.

2) In systems where improvement using any other means (such as increased
transmit
power or components that generate less noise) is very costly or impractical, FEC

can offer significant error control and performance gains.

3) In systems with satisfactory data integrity, designers may be able to
implement
FEC to reduce the costs of the system without affecting the existing
performance.
This is accomplished by degrading the performance of the most costly or
sensitive
element in the system, and then regaining the lost performance with the
application of FEC.

In general, for digital communication and storage systems where data integrity
is a
design criteria, FEC needs to be an important element in the tradeoff study for
the system
design.

A good example of the use of FEC codes in commoditiy systems where the BER is
not counted seperately from the corrected error rate is the PRML channel of a
disk drive. This is the read/write channel which transports information between
the media and the disk's 'MAC'.

The judicious use of FEC in a systems including certain 10 Gigabit Ethernet PHYs
such as MAS provide a level of system reliability which can not be achieved
through other means in the same cost effective manner. FEC may be used to lower
the relax some optical component specifications in order to lower the cost of
those optical components. This exercise may be new and radical to some, but it
is clearly not a new and radical technique in the digital communications
industry (e.g. mobile phones, disk drives, satellite links, etc.)

--

"Chang, Edward S" wrote:

> Kamran:
>
> Thanks for very elaborated explanation related to FEC with which I am not
> quite familiar.
>
> >From you description, quote: " FEC codes are meant for error correction
> only"; therefore, FEC is one of the error correction scheme.
>
> Usually, the bit error rate is defined without error corrections.  The
> purpose of BER is to measure the reliability of the over-all link, which
> should not subtract the errors corrected by the error-correction-codes.
>
> However, users can chose to correct the errors -- one error, or multiple
> errors-- based on the reliability measure, BER, supplied by vendors and
> requirement of the application to implement error corrections.  Error
> correction is not free, which will use valuable resources.  For very
> unreliable tapes or disks, error correction is a requirement, however for a
> well designed semiconductor memory, error correction is not required.
>
> The reason I also elaborate the issue is that BER is measured without error
> corrections.  Error correction can not be used to claim the BER is improved.
> Otherwise, we will not have the universal referencing point in discussing
> the reliability of a link based on BER.
>
> ED Chang
> Unisys Corporation
> Edward.Chang@xxxxxxxxxx
>
> -----Original Message-----
> From: ka@xxxxxxxxxxxxxxxxxxx [mailto:ka@xxxxxxxxxxxxxxxxxxx]
> Sent: Monday, June 28, 1999 4:14 PM
> To: weniger@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Cc: ka@xxxxxxxxxxxxxxxxxxx
> Subject: RE: Issues concerning 10GbE speed standards
>
> Fred,
>
> > Kamran,
> >
> > You have touched on some very key points here. If I may pursue them:
> >
> > 1. Why is latency of less concern in a WAN than in a LAN?  I would have
> > thought just the opposite (consider noticeable delay in voice
> communication
> > via satellite, for example).
>
> I agree, I just meant delay in the PHY becomes small compared to
> propagation time in optical fiber for longer distances, so you don't
> have to worry about it.
> In both cases the lower the latency, the better. BTW there are low-latency
> FEC codes. To quantify latency due to FEC, I was trying to compare it to
> propagation time in the fiber itself. That you can no avoid.
>
> >
> > 2. Multiple FEC schemes are referred to. How do they differ?  Are they
> > interoperable among multiple vendors?  How much power do they consume?
> >
>
> My understanding is that FEC schemes used in WAN have been proprietary
> so far. The drawback is: 1) they are not interoperable 2) there is
> no real competition that drives the price low.
> I believe WAN experts are trying to fix this by adopting a unique FEC
> scheme. I have seen some contributions in ITU that are based on 1, 2 or 3
> error correcting BCH codes. I don't think the FEC code there is set yet.
> Reed-Solomon codes can provide more performance, at the expense of more
> overhead and more sophisticated decoder than BCH codes.
> About power consumption of exisiting solutions, if I find exact numbers
> I will include them in my FEC presentation in Montreal.
>
> I would like to add a point I forgot to mention in my previous mail. In
> many FEC schemes, the encoder is much simpler than the decoder (computing
> parity bits using XOR gates). FEC decoding is up to the implementer.
> Eventhough the 10G Ethernet group may allocate bits for FEC, using
> those bits for error correction is optional and is up to implementers.
>
> > 3. Same question for scrambling.  Is it always interoperable among
> vendors?
> >  How much power does it consume?
>
> Maybe someone else can answer this question. I think scrambling is
> independant from FEC and vice versa (please see below).
>
> >
> > 4. You state that one benefit of FEC is lower cost optics.  Why does FEC
> > permit lower cost optics?
>
> Error correction improves BER. For instance in the RS(255,239) 8 byte
> errors or 16 erasure bytes can be corrected. The corresponding RS
> decoder gives a BER of better than 1e-14 for an input BER of 1e-4 !
> (from the top of my head). An equivalent way of expressing the improvement
> in performance, is to set BER (that's what is usually specified in
> PHY standards) and measure SNR. For the same BER, you can relax
> Signal-to-Noise ratio at the receiver. In the optical domain that
> translates in relaxing the power budget of the laser by X dB.
> (In the above example 5dB optical gain at BER=1e-12).
> Another trade-off could be running over longer distances (or
> said differently to tolerate more dispersion in the fiber at the
> receiver).
>
> > Will the same benefit be realized with less
> > system power penalty by using 8B/10B?  My suspicion is, yes - it will!
>
> There may be some confusion here. I think FEC and 8B/10B are orthogonal
> issues. 8B/10B is designed to limit run-length (that's probably the benefit
> you are mentioning), usually FEC codes are meant for error correction only.
> They are not mutually exclusive. An FEC scheme can be used in conjuction
> with both 8B/10B codes, or scrambled codes. There are pros and cons for
> 8B/10B and scrambled codes, but in my opinion that's a seperate issue.
>
> Regards,
>
> Kamran Azadet
> Lucent/ Bell Labs
>
> >
> > Regards,
> >
> > At 01:19 PM 6/28/99 -0400, ka@xxxxxxxxxxxxxxxxxxx wrote:
> > >Fred,
> > >
> > >     FEC is definitly worth being considered by the HSSG group both
> > >for LAN and WAN. There are FEC schemes that require lot less than
> > >25% overhead. Actually some FEC schemes used in optical communication
> > >use as low as 0.05% overhead (BCH codes), few bits out of thousands of
> > >bytes. A popular code is the Reed-Solomon code RS(255,239). Its
> > >redundancy is 255-239=16 Bytes for 239 Bytes of information, that
> > >is 7% overhead. It has a very good performance (5dB optical gain).
> > >
> > >There are many FEC schemes that are suitable for optical communications
> > >and provide a high gain for a modest overhead (maybe zero overhead if
> > >parity bits are transmitted in a reserved header or in the IPG of
> > >Ethernet packets). The drawback of using FEC is an increase in logic
> > >circuit cost (which is less and less of a problem with increase of
> > >logic density in CMOS technology), and increase in PHY latency. For
> > >WAN applications the increase in latency is insignificant, however
> > >for LAN depending on which code is being cosidered, latency could
> > >be significant compared to propagation time in the fiber and require
> > >an increase of buffer size in a switch. This can rule out certain codes.
> > >
> > >Finally, I believe both LAN and WAN can benefit from FEC (and from
> > >zero overhead scrambled codes as well but that's a seperate discussion).
> > >In WAN it is important to increase the maximum operating link distance to
> > >minimize overall system cost, and this can be achieved by FEC. The
> > >benefits of FEC can potentially be greater in LAN, because of DMD.
> > >Optical gain depends very much on the optical response of the receiver
> > >and on the channel. Usually the worse the channel, the greater the
> > >benefits from FEC.
> > >
> > >Implementing an FEC technique in 10G Ethernet can greatly help supporting
> > >existing installed base of fiber + increase operating distance on new
> > >low-cost multi-mode fibers.
> > >
> > >In my humble opinion, the extra cost of X gates is well worth-while
> > >if this allows a considerable decrease in overall system cost, and
> > >relaxing requirements of the optics including the fiber itself.
> > >
> > >Regards,
> > >
> > >Kamran
> > >

--

Best Regards,
Rich

-------------------------------------------------------------
Richard Taborek Sr.    Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect         Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc.           Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way              http://www.transcendata.com
Palo Alto, CA 94303-4305    Alt email: rtaborek@xxxxxxxxxxxxx