RE: Issues concerning 10GbE speed standards
- To: rtaborek@xxxxxxxxxxxxxxxx, "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>, HSSG <stds-802-3-hssg@xxxxxxxx>
- Subject: RE: Issues concerning 10GbE speed standards
- From: "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>
- Date: Wed, 30 Jun 1999 08:45:59 -0400
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
No problem. We are so busy trying to help committee in responding many
issues at one time. It is prone to overlook some time. We all overlook
something, time to time.
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
Sent: Tuesday, June 29, 1999 4:58 PM
To: Chang, Edward S; HSSG
Subject: Re: Issues concerning 10GbE speed standards
I'm sorry, I mis-interpreted your comment. Kameran did a much better job of
interpreting it than I did and provided a response that I agree with. I was
instead focusing on meeting the Ethernet BER objective, which would
to the BER after error correction. A separate, and currently unsupported
Ethernet objective (as far as I know) is BER Monitoring. To summarize, BER
monitoring can still be performed at the receiver prior to error correction.
"Chang, Edward S" wrote:
> BER and error correction are two different issues: BER is a parameter of a
> link specification, while error correction is the application issues.
> Like anything else, there are test conditions imposed to the measurement
> a parameter to make all measurement taken at the same base-line.
> However, for applications, anyone can add as much as error corrections to
> make error free, but it is not a specification.
> Ed Chang
> Unisys Corporation.
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxxxxx]
> Sent: Tuesday, June 29, 1999 12:08 PM
> To: Chang, Edward S; HSSG
> Subject: Re: Issues concerning 10GbE speed standards
> I disagree with your assertion that "Error correction can not be used to
> the BER is improved.". This is EXACTLY what error correction does, and it
> so essentially for 'free', depending on the PHY technology employed. The
> following a a good summary of the advantages of error detection and
> I am extracting it from a primer on Reed-Solomon Error Correction Codes
> can be found on the Advanced Hardware Architectures web site:
> THE ADVANTAGES OF ERROR DETECTION AND CORRECTION (EDAC)
> EDAC has a number of advantages for the design of high reliability digital
> 1) Forward Error Correction (FEC) enables a system to achieve a high
> reliability, even with the presence of noise in the communications
> integrity is an important issue in most digital communications systems and
> mass storage systems.
> 2) In systems where improvement using any other means (such as increased
> power or components that generate less noise) is very costly or
> can offer significant error control and performance gains.
> 3) In systems with satisfactory data integrity, designers may be able to
> FEC to reduce the costs of the system without affecting the existing
> This is accomplished by degrading the performance of the most costly or
> 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
> is a
> design criteria, FEC needs to be an important element in the tradeoff
> the system
> A good example of the use of FEC codes in commoditiy systems where the BER
> not counted seperately from the corrected error rate is the PRML channel
> disk drive. This is the read/write channel which transports information
> the media and the disk's 'MAC'.
> The judicious use of FEC in a systems including certain 10 Gigabit
> such as MAS provide a level of system reliability which can not be
> through other means in the same cost effective manner. FEC may be used to
> the relax some optical component specifications in order to lower the cost
> those optical components. This exercise may be new and radical to some,
> 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
> > 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
> > well designed semiconductor memory, error correction is not required.
> > The reason I also elaborate the issue is that BER is measured without
> > corrections. Error correction can not be used to claim the BER is
> > Otherwise, we will not have the universal referencing point in
> > 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
> > > 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
> > 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
> > 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
> > 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
> > > 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
> > 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
> > you are mentioning), usually FEC codes are meant for error correction
> > 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
> > > >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
> > > >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
> > > >
> > > >Finally, I believe both LAN and WAN can benefit from FEC (and from
> > > >zero overhead scrambled codes as well but that's a seperate
> > > >In WAN it is important to increase the maximum operating link
> > > >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
> > > >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
> > > >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,
> 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
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