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

Re: [802.3_DIALOG] 802.3cn Interim Teleconference ER8, ER4, ER1 Specifications Proposal Presentation preview



Dear Colleagues,

 

During last Tuesday’s 802.3cn Interim Teleconference, the proposal in cole_3cn_01a_190924 to change Draft 3.0 Specification to improve optical margins and device yields was rejected.

 

To my knowledge, this is the first 802.3 project where the entire presented data set shows one of the Standards technically not feasible. The 802.3cn data was presented in Study Group during 2018 in support of the baseline proposal, and in Task Force during 2019 in further support of the adopted baseline. In the enclosed graphs, this data set shows that the baseline ER8 receiver spec. has no margin and yield. Separately, it shows that the baseline ER8 transmitter spec has low margin and yield. The posted Editor justification, for rejecting the proposed spec improvements, is that the entire presented data set is invalid and that undefined device optimization will result in cost-effective meeting of the baseline specs.

 

Off-line during the Teleconference, it was pointed out that a specification change proposal similar (within 0.3dB) to cole_3cn_01a_190924, was made in chang_3cn_02_0519, and also rejected. I also received clarification about 2019 measurements and the enclosed 2018+19 graph is updated accordingly. What gets deployed in the field will likely be closer to these two change proposals than to the Standard because physics gets the final vote in engineering.

 

Hopefully, this will be the last 802.3 project where wishful thinking replaces data. Below is a list of steps we may consider for future projects to help accomplish this.

 

  • Avoid separate projects that standardize the same technology. In this case, 100G LR1 and 400G LR4 were in 802.3cu, and 50G ER1, 200G ER4 and 400G ER8 were in 802.3cn. Since all are SMF IMDD PMDs, they should have been in one project.
  • Hold all meetings jointly, if there is a compelling reason for separate projects. For example, all 802.3ct and 802.3cw meetings should be joint because both are standardizing SMF Coherent PMDs.
  • Avoid standardizing technology with narrower interest in in the same project that is standardizing technology with broader interest. In this case, ER PMDs were overshadowed by Coherent PMDs.
  • Avoid comment resolution on ad hoc calls. Getting projects completed quickly is commendable, but at some point rushing to finish a Standard becomes a detriment.


Thank you

 

Chris

 

From: Chris Cole
Sent: Monday, September 23, 2019 11:54 PM
To: STDS-802-3-B10K@xxxxxxxxxxxxxxxxx
Cc: STDS-802-3-100G-OPTX@xxxxxxxxxxxxxxxxx
Subject: RE: 802.3cn Interim Teleconference ER8, ER4, ER1 Specifications Proposal Presentation preview

 

Dear Colleagues,

 

I have received several comments that presented data tables make it difficult to understand the analysis, and suggestions were made to use graphs. As the saying goes, a picture is worth a thousand words. Therefore I plotted the 400GBASE-ER8 RX Sens OMA (max) data and analysis from Tables 4, 5 and 6 (see previous email below), in the enclosed Data 2018 graph. (Please hold off looking at the Data 2018-19 graph until later in this email.) I ran out of time to do the same for TX OMA (max).

 

The 802.3cn Editor responses to the proposed Public Comment changes to increase Optical Margin and Yield of the Draft D3.0 Specifications have now been published on-line:

http://www.ieee802.org/3/cn/comments/P802d3cn_D3p0_public_comments_prop_Cl.pdf

All comments are suggested Reject and all use similar justification.

 

Let’s look in detail at the Editor’s justification for rejecting one of the comments which proposed changing the critical RX Sens OMA (max) specification to improve the 400GBASE-ER8 receiver yield from 2% to 100%.

 

The data used in cole_3cn_01_190924.pdf on optical power levels comes from presentations to the IEEE 802.3 Beyond 10km Optical PHYs Study Group prior to the adoption of the optical budget in the baseline for 400GBASE-ER8 in November 2018 (which is the same budget as in the latest P802.3cn draft) with vote Y:63, N:0, A:7. The devices reported in these presentations could not have been optimized for the 400GBASE-ER8 application that had yet to be defined. It is therefore not valid to try to assess manufacturing yield from these reported results.

 

The source for the data used in the analysis supporting the change, is all the data presented throughout 2018 in Beyond 10km Study Group, and then referenced in support of the Nov. 2018 400GBASE-ER8 baseline specification proposal  chang_3cn_01b_1118.pdf. The RX Sens OMA (max) spec in that proposal, -16.1dBm, chang_3cn_01b_1118, is exactly the same value as it is today in the published Draft 3.0. The Editor response dismisses all of this data. This may be wise, since the data shows that the specification can not be met at a reasonable cost (2% yield).

 

Since all 2018 data has now been invalidated, let’s look at what devices “optimized for the 400GBASE-ER8 application” look like. The only additional data presented in 802.3cn was chang_3cn_01a_0319, in Mar. 2019. Analysis of the data shows that the average of two devices RX Sens OMA (max) is worse by 0.5dB than the average of the 2018 data. The result of combining the 2019 data with the 2018 data is shown in the enclosed Data 2018-19 graph. The Optical Margin is degraded by 0.2dB and the yield is reduced by 10x, from 2% to 0.2%.

 

In a previously sent email, the major Network Operators (China Mobile, Chine Telecom, Deutsche Telekom, Verizon, ATT and NTT) clearly stated that cost of Optical PMDs is critical. It is not a good reflection on our process that their requirements are ignored.  

 

Another change proposed in the submitted Public Comments was to use “R1” instead of “R” for single lane PMDs, specifically 50GBASE-ER1 (not 50GBASE-ER).  The Editor suggests Reject, and justifies this by correctly pointing out that IEEE 802.3 has not previously used “R1” for single lane optical PMDs. But that is exactly the reason all the major Cloud Data Center Operators (Alibaba, Amazon, Apple, Facebook, Google, Microsoft, and Tencent) requested of 802.3 that nomenclature be changed from past practice of generic “R” to explicit “R1”; cole_3cu_01a_0719. This pattern of disregarding End User requirements is troubling.

 

Chris


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

Attachment: All Data 2018.jpg
Description: All Data 2018.jpg

Attachment: All Data 2018+19.jpg
Description: All Data 2018+19.jpg