RE: Issues concerning 10GbE speed standards

["Chang, Edward S" <Edward.Chang@xxxxxxxxxx>]

Richard:

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.

Ed Chang 

-----Original Message-----
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


Ed,

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
correspond
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:

> Richard:
>
> 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
of
> 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
>
> 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

--

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