RE: Issues concerning 10GbE speed standards
- To: weniger@xxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx
- Subject: RE: Issues concerning 10GbE speed standards
- From: ka@xxxxxxxxxxxxxxxxxxx
- Date: Mon, 28 Jun 1999 16:13:50 -0400 (EDT)
- Cc: ka@xxxxxxxxxxxxxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> 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
> 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.
Lucent/ Bell Labs
> At 01:19 PM 6/28/99 -0400, ka@xxxxxxxxxxxxxxxxxxx wrote:
> > 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.