Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_B400G_LOGIC] Follow-up questions regarding lu_3df_logic_220425

Yan and Yuchun,

Thank you for your presentation FEC architecture and performance investigation for 800GbE and 1.6TbE in yesterday’s ad hoc call. I had some comments and questions but due to connectivity issues the Q&A had to be cut off. Since it may be relevant for many participants, I’m using the reflector.

My understanding from the presentation is that end-to-end FEC is your preferable scheme. But on slide 3 (as of the original slide deck) it is suggested that the “provisional” application (third row) uses a segmented FEC scheme, where the RS(544, 514) protects just the 100G/lane AUIs, and the “FEC” block (apparently something other than RS(544,514)) protects just the optical link. Only in the “mainstream” applications it is really end-to-end, and it’s supposedly the same FEC for all PMDs.

As noted by Brian Welch in the subsequent presentation End to segmented FEC, with a segmented FEC scheme in which all segments use the same FEC, if the total BER is low enough, FEC termination in modules can be bypassed, making it an end-to-end FEC. I’m not getting into details of when and how this can be done. If the PMD-to-PMD FEC happens to be RS(544, 514) then this option “comes for free”, but if it results in choosing a higher overhead FEC, the additional bandwidth will be a burden on the electrical segment, and it needs to be analyzed with much more detail.

So my questions are:

  • Should we really shoot for an end-to-end FEC which will be the same FEC for all 200G/lane PMDs, as suggested by the top row of slide 3?
  • Would a segmented FEC architecture in which all FECs are RS(544, 514), such that FEC decoding/re-encoding can be selectively bypassed in a module, match what you advocate in your presentation?
    • (If this FEC is insufficient for some PMD types, these PMDs can terminate it and use another FEC – without burdening the electrical signaling or other PMDs)

 

On another topic:

  • Slide 12 states that “the MTTFPA for RS(544, 514) is already marginal with random input error distribution assumption”, pointing to anslow_3ct_01_0519.
  • That contribution quotes (on slide 5) a statement from clause 91: “The probability that the decoder fails to indicate a codeword with t+1 errors as uncorrected is not expected to exceed 10^–6”. However, in 119.2.5.3 it is stated that “The probability that the decoder fails to indicate a codeword with t+1 errors as uncorrected is not expected to exceed 10^–16”.
  • My understanding is that this much lower probability is due to the fact that clause 119 specifically has t=15, while clause 91 has either t=7 or t=15, and the number 10^-6 is suitable for t=7. See also comment #74 against D1.2 of 802.3bs (P802d3bs_D1p2_comments_final_Cl) and its response, which points to cideciyan_01_0112.
  • If indeed the probability of undetected uncorrectable error is that low, then MTTFPA is not marginal with RS(544, 514) as used in 200G/400G Ethernet, and keeping this FEC would not create an issue in 800G/1.6T. Apparently there are contradicting messages here, and it would be good to get to the bottom of this concern.

 

Best regards,

</Adee>

 

 

To unsubscribe from the STDS-802-3-B400G-LOGIC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-LOGIC&A=1