Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
So by your argument any tx that supports a single speed is the same? NoWe are discussing a standards process with rules that we need to address- while analogies are helpful you need to determine if they are applicableSent from my iPhoneOn Aug 16, 2023, at 1:13 PM, Chris Cole <chris.cole@xxxxxxxxxxxx> wrote:John
If I drive the same car at two different speeds, that doesn't make it two cars.
Chris
From: John D'Ambrosia <jdambrosia@xxxxxxxxx>
Sent: Wednesday, August 16, 2023 10:09 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_B400G] [802.3_B400G_LOGIC] P802.3dj Joint Logic/Optics Track ad hoc agenda 8/15/23AllI will be discussing this topic further with Mr. Law shortly.
Despite assertions it is the same device - the current tx proposal is not the same device running at lower rates as there were other changes to the tx / tx proposed.
Your patience is appreciated
Regards
John
Sent from my iPhone
On Aug 16, 2023, at 12:49 PM, Chris Cole <chris.cole@xxxxxxxxxxxx> wrote:
Hi Ali,
If inner FEC is specified for plug and play DR and FR, the specifications for the no inner FEC mode falls out of it. It's the same implementation operating at the lower rate. This leads to reduced performance, for example lower power budget. Whether that's useful is a separate question.
Given the confidence by TF participants in no inner FEC feasibility, we should revisit writing a spec. for only this case. This is especially true for DR.
One option is to specify DR only with end-to-end FEC, and FR and LR are with inner FEC, again subject to demonstrating feasibility.
Chris
From: Ali Ghiasi <aghiasi@xxxxxxxxx>
Sent: Wednesday, August 16, 2023 9:03 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G@xxxxxxxxxxxxxxxxx>
Subject Re: [802.3_B400G] [802.3_B400G_LOGIC] P802.3dj Joint Logic/Optics Track ad hoc agenda 8/15/23Hello Chris,
One of the key reason for success of IEEE 802.3 standards as said is the Five Criteria (CSD) and technical feasibility, on the DJ website under Technical Feasibility we have:
At a minimum, address the following items to demonstrate technical feasibility:a) Demonstrated system feasibility.
b) Proven similar technology via testing, modeling, simulation, etc.
c) Confidence in reliability.
I am sure at some point in time 200 Gb/s/lane optics will evolve sufficiently where one with confidence and reliable operate such link with just KP4 FEC.If for some reason the future TX technology (2nd Gen Sipho/TFLN ??) are ready for deployment in 12-18 months then there is no reason to define PMDs with inner FEC!
We should not hack defining future optics PMDs based on 1st Gen 200G TX optics!
Thanks,
Ali Ghiasi
Ghiasi Quantum LLC
On Aug 15, 2023, at 1:52 PM, Chris Cole <chris@xxxxxxxxxxxxxxx> wrote:
During today's Ad Hoc call, John D'Ambrosia's and David Law's presentation [ieee802.org]very nicely illuminated the disconnect we have in the Task Force on standardizing FEC bypass.
One perspective is that we create new objectives for the same reach, with independent specs. at a lower rate and only end to end FEC. Part of the motivation is that a better TX modulator removes the need for inner FEC. If we adopt this approach, we will have two solutions to the same problem: 1) "bad" TX with inner FEC to make up for the badness, 2) "great" TX without the need for inner FEC. Unfortunately, we have 802.3 Five Criteria to contend with. Distinct Identity clearly states there will be one solution to one problem. If DI doesn't apply here, then we might as well discard it, and going forward only have 802.3 Four Criteria.
FEC bypass should be a lower performance operating mode for the same HW. This is the basis on which I supported moving forward with it. We have to add a full set of specifications for this mode. This is why the general approach we take for ER is good precedent. The Plug-and-play spec column is at the higher rate with inner FEC. The Engineered spec column is at the lower rate with inner FEC bypassed. An end user can then look at the spec, and for example conclude that for their shorter reach ML clusters, the FEC bypassed mode works just fine. However, the specifications lead to one component type. The industry does not need component type proliferation driven by IEEE. That leads to market fragmentation.
Alternatively, if we really believe that "good" TX technology is available, let's not bother having an inner FEC. Let's forget writing a spec for "bad' TX and write one spec. for end-to-end FEC only.
Either way, we do not need new objectives. We have single 500m and 2km objectives, each with two modes (Plug-and-play and Engineered) with different levels of performance and operating parameters like rate, or just one Plug-and-play mode without inner FEC.
Chris
On Mon, Aug 14, 2023 at 6:15 AM Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Hi Everyone,
All files for tomorrow’s joint optics/logic ad hoc meeting are posted here [ieee802.org].
Call in details are available here [ieee802.org].
The technical presentations in the agenda are:
- " FEC Bypass: Procedural Considerations " presented by John D’Ambrosia, Futurewei, US Subsidiary of Huawei
- " Performance Evaluation of Inner FEC Synchronization Methods " presented by Xiang He, Huawei
- " Specifying BER in PMD clauses " presented by Adee Ran, Cisco
- " DGDmax specification for 10km Ethernet" presented by Maxim Kuschnerov, Huawei
We may be holding a straw poll after the first presentation to gather directional feedback for Task Force leadership.
I want to remind all teleconference meeting participants to review the following documents prior to participation in an IEEE 802.3 meeting teleconference:
- IEEE SA patent policy
- IEEE SA Copyright Policy
- IEEE SA Participation Policy
All of these policies may be found at http://ieee802.org/3/policies.html [ieee802.org]Thanks,Mark NIEEE P802.3dj optics track leaderAndMark GIEEE P802.3dj architecture and logic track leader
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 [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
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
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
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
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