Re: [802.3_B400G] [EXTERNAL]: RE: [802.3_B400G

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

Chris,

Thank you for your continued efforts to get data brought into the Task Force to help it with its task.

However, as Task Force Chair, I am going to take exception with your statement regarding the comment process as being inconsistent or transparent. We have used the same consistent approach starting with the initial task force review – comments assessed as being of interest to broad group of experts of different areas are assigned to “Common” and comments assessed as being of interest to a specific set of experts is assigned to the respective logic, electrical, optical tracks. This approach has been conssistently leveraged to address the significant number of comments that have been submitted with each task force review / WG ballot.

The planned approach to addressing comments is extremely transparent. Matt Brown, as Chief Editor, presents the detailed plan to the Task Force at the beginning of the Task Force meeting.

For example, here is the planned comment agenda for D1.0 - https://www.ieee802.org/3/dj/public/24_06/brown_3dj_01_2406.pdf [ieee802.org].

For consideration of comments submitted during the first WG recirculation ballot in Sept 2025 (D2.1) – the following planned comment agenda for D2.1 was presented at the beginning of the meeting - https://www.ieee802.org/3/dj/public/25_09/brown_3dj_02_2509.pdf [ieee802.org] (updated throughout the meeting to reflect meeting progress). You will note at the top of page 8 which is denoted as “Common Track – Optical” – is comment 399, the comment that I believe is your concern.

As you can see – consistent and transparent.

Going forward, please make sure to be present at the beginning of the meeting when the comment agenda is presented. I foresee the continued use of this approach with the remaining ballots when a significant number of comments are submitted, given the time constraints we face.

Regards,

John D’Ambrosia

Chair, IEEE P802.3dj Task Force

From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Sent: Thursday, October 9, 2025 5:58 AM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_OPTX] Transmitter testing

Hi Mark,

I fully support and commend your efforts to get data for the various specs.

With respect to the Functional Test, some data has been presented, and a great deal of data has been taken by transceiver vendors who all use functional testing in 200G/lane optics development. We are seeing a reluctance to share this data, partly for competitive reasons, and partly because presenting data in 802.3 is not viewed as the highest priority.

In the great news department, Pengyue Wen and Ed Urlichs affiliated with Meta have recently received legal approval to aggregate vendor functional test measurements and present them anonymized: vendor A, B, C, etc. Pengyue has graciously agreed to be the focal point and is on cc of this email. Please contact him directly to have your data anonymously presented to the TF.

With respect to the newly added Jitter Test, I have spoken to multiple individuals, and all indicated they will not put in the difficult and time-consuming effort just to prove it’s not needed. The shared view is that the proponents presented some data showing the proposal does not work and is not necessary. This hardly makes it "well proposed", as you commented in another email. Further, the proponents informed TF they will not be taking more data and expect others to do it for them, best characterized as chutzpah.

With respect to where comments are resolved, I pointed out that the process is not consistent, and that to have credibility it should be consistent and transparent. If the stated rule is that optical-only specs belong in a joint track if they affect electronics, then it should be applied evenly. If it is not, it means there are other considerations.

Thank you

Chris

From: Mark Nowell (mnowell) <mnowell@xxxxxxxxx>
Sent: Wednesday, October 8, 2025 7:25 AM
To: Chris Cole <chris.cole@xxxxxxxxxxxx>; STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>; STDS-802-3-B400G@xxxxxxxxxxxxxxxxx <stds-802-3-b400g@xxxxxxxxxxxxxxxxx>
Subject: Re: Transmitter testing

+ P802.3dj Task Force reflector

Chris,

I appreciate you raising your concerns to the group and am hoping that you will be part of the efforts to bring in data and/or analysis in support of, or against, some of these many tests we have adopted. I just sent an email to the Task Force reflector highlighting my overall concerns on the broader topics here that we need to reconcile the full suite of tests we have currently adopted.

I do however take issue with some of your points below regarding how the Task Force works and how we will continue to work.

At each increase in speed, we continue to see the intermingling of issues between all aspects of our work in the 3 categories of our work electrical/logic/optical as we work to resolve the technology and implementation issues. The margins we are dealing with become ever tighter meaning that this trend is not going away.

In a Task Force, we would ideally all meet together for every technical discussion as the expertise needed to resolve each topic often spans across domains. We write stronger specifications as a result. With P802.3dj we have a situation where the current volume of work dwarves our ability to do it all together and we necessarily have been splitting into tracks so we can to allow parallel work. As we triage the comments that come in, the leadership team and the editorial team do considerable work to pull together a plan to optimize how we a) get the work done and b) aim for the highest quality of work in the limited time.

This results with meeting plans, that you are familiar with, where we pull together the topics and meeting room availability to try and have a successful meeting. We know that a blend of common time for topics and specific track time is the most successful outcome with our current workloads and we have no plan to change that. We have numerous participants who put in considerable time submitting comments and in respect for that work we aim to ensure we can manage schedules in support of everyone if we can.

Thank you for your input regarding that one topic of concern you have. We will take it into consideration. But per the email I just sent to the Task Force, I’m elevating this broader issue of SMF test methodologies as one of our big-ticket items that needs to be resolved in November so that it doesn’t start risking overall project schedule. We know we have broad expertise across the Task Force which will help us resolve the issues and we will be planning accordingly to give us the highest probabilities of getting the work done and getting the most robust outcomes.

The leadership team and editorial team will once again triage the comments and the work ahead for the November meeting and map that into meeting times and track times. This is not a trivial effort and if you want to join all of the 2+ weeks of multiple times a day, daily planning meetings that occur here to achieve this let us know.

Regards,

Mark

From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Date: Tuesday, October 7, 2025 at 6:07 PM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_B400G_OPTX] Transmitter testing

Dear 802.3dj Optics Track Participants,

During the September interim, in multiple conversations, the question came up why Comment #399 was resolved in a joint electrical optical track meeting. After all this is a purely optical spec, which has no effect on any electrical link because the receiver is fully retimed.

Today, during an informal off-line SMF consensus building discussion, we learned the reason why. It was pointed out that transmitter jitter has an effect on DSP design, and DSP is electrical.

While this is absolutely true, it is not how we should determine which track specs belong in. This should be determined by what link they effect. Specs that effect only electrical or optical links should be resolved in separate electrical or optical tracks, respectively. Specs that effect both should be resolved jointly.

Further, almost every spec in the Transmitter Characteristics table has electrical circuits associated with it, like Drivers, or effects electrical circuits in the receiver, like TIA. The only two specs that I found that could be argued not to effect electrical circuits are Optical return loss tolerance and Transmitter reflectance. If we were to consistently apply the rule that if a spec has effect on an electrical circuit, even if only used for optical functions, then there is no need for an optical track, or optical comment resolution. Everything should be considered in a joint electrical/optical track. Viewing this as unreasonable is not naive, as was characterized today, but rather common sense.

Hopefully during the November Plenary optical jitter will be correctly assigned to the optical track for resolution, since its only effect is on the optical link. If not, then hopefully a better and more consistent rationale will be given than the above.

Thank you

Chris

From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Sent: Monday, September 22, 2025 1:28 PM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>
Subject: [802.3_B400G_OPTX] Transmitter testing

Dear 802.3dj Optics Track Participants,

During last week's Interim meeting, Comment #399 against D2.1 was resolved by adding a jitter test to Transmitter compliance. This was unfortunate for a number of reasons, which a group of optics experts captured in a post deadline presentation.

https://www.ieee802.org/3/dj/public/25_09/cole_3dj_02_2509.pdf [ieee802.org]

The technical discussion around the presentation was cut short, so we have requested from the Optics Track Chair that we find time to continue the discussion.

There are many reasons why adding a jitter test in the manner in which it happened is problematic, and two stand out.

This issue has been discussed in multiple Optical Track calls over the past year and it has had no support from the optical community, as exemplified by lack of optics supporters on the comment. During comment #399 resolution, multiple optics experts spoke against adding this test, and no optics experts spoke in favor.

802.3 is part of a greater ecosystem. We need to have mutual respect for each other's expertise and 802.3 forcing a test on a segment of the industry that does not want it, only undermines 802.3 credibility. Regardless of whether this test is part of the standard, those that build and deploy optics are not going to use it. As it is, optics testing is expensive, and increasing the cost without a clear benefit is not going to happen.

Jitter problems are captured by the recently added functional test. In fact, comment #399 proposal showed this by using a BER test to illustrate jitter issues. If BER test is the ultimate arbiter of jitter problems, why bother with an additional indirect test? During the brief discussion of the above presentation, concerns were raised about the ability of a functional test to catch jitter issues, for example the functional receiver having a pathological jitter tracking bandwidth. We need a forum to talk through these concerns. Although in this case the answer is the same as a doctor gives a patient with headaches who bangs his head against the wall: don't do it.

Towards the Nov. the Plenary meeting, we will be working on a presentation to remove jitter testing from transmitter compliance and asking for broad optics industry support.

Thank you

Chris

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

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

Re: [802.3_B400G] [EXTERNAL]: RE: [802.3_B400G_OPTX] Transmitter testing