RE: Issues concerning 10GbE speed standards

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

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