All,
The compelling aspect is that the interface itself can figure out what is needed to reach acceptable performance rather than the end user running some form of experiment. For a CMIS managed module, perhaps the module would realize which Media Interface IDs (PMDs) can be supported and only those would be presented as available for use; two PMDs or only one PMD supported in this case if the FEC scenarios are defined as separate PMDs. This would require a discovery mode of operation by the module.
Jeff
------------------------------------
Pronouns: he/him/his
Distinguished Engineer II
Juniper Business Use Only
From: Chris Cole <chris@xxxxxxxxxxxxxxx>
Sent: Wednesday, July 5, 2023 10:09 AM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] [E] Re: [802.3_B400G] [802.3_B400G_LOGIC] Files posted: P802.3dj Joint Logic/Optics Track June 29 ad hoc meeting
[External Email. Be cautious of content]
Adee,
In Ethernet, every rate has its own specification. There are no mystery-performance operating rates.
How will an operator know if a link can operate in FEC bypass mode if we don't specify the performance?
Unfortunately, I was not involved in RJ45 Ethernet so can't comment. However, I am having trouble seeing operators today not caring about link latency before designing their datacenter network. Which operator to your knowledge doesn't need to know this?
Chris
On Wed, Jul 5, 2023 at 9:56 AM Adee Ran (aran) <aran@xxxxxxxxx> wrote:
Chris,
Ethernet has a long history of enabling plug and play and automatic configuration. Auto negotiation has been part of Ethernet since the first time there were two data rates, 10 Mb/s and “Fast Ethernet” 100 Mb/s. It is an extremely useful feature for anyone who has ever plugged an Ethernet cable into a RJ45 jack.
I’m not questioning the claim that many operators will want to have the power to configure the endpoints to their desired speed. But that can also be achieved with the auto negotiation framework. And some operators/users may want to have the freedom to plug in a module and get the “it just works” experience. I think Nicklous has mentioned that in his response, I concur with that part.
In the case of inner FEC, we are not even talking about data rate negotiation. Whether or not the inner FEC is bypassed does not change the data rate, and for the host (PCS and upwards) it only shows up as different latency. Now, this is not the first time we have latency that depends on FEC choice; 802.3by had three FEC modes with different latencies, and the mode was negotiated between the two sides using clause 73 AN. This was 25G copper cable driven by data center applications, not end-user laptops. Even in the recent 802.3ck there is a 100G interleaved FEC mode that is negotiated using clause 73 AN. In all cases, anyone who wants to force as host to work in only one mode can do that.
The decision on FEC bypass should be independent of the question of whether or how the modules negotiate the right mode. Whatever “intelligence” the module has, it has to be overridable by management – this goes without saying.
</Adee>
From: Chris Cole <chris@xxxxxxxxxxxxxxx>
Sent: Wednesday, July 5, 2023 6:57 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G] [E] Re: [802.3_B400G] [802.3_B400G_LOGIC] Files posted: P802.3dj Joint Logic/Optics Track June 29 ad hoc meeting
That seems sensible, but does bring us back to the difficult problem of how to do the autonomous mode.
On Wed, Jul 5, 2023 at 8:37 AM Morris, Nicklous D <nicklous.morris@xxxxxxxxxxxxxxxxxxx> wrote:
Chris,
I concur. Many, if not most, operators will want to have the power to configure as opposed to autonomous negotiation. That being said a default to autonomous should be assumed as not every operator will look to define it.
On Mon, Jul 3, 2023 at 12:49 PM Chris Cole <chris@xxxxxxxxxxxxxxx> wrote:
Dear 802.3dj TF Participants,
During the Ad Hoc call, Mike Dudek presented an important proposal for PMD reuse.
There was broad recognition of the benefits of reducing latency by bypassing the inner FEC. However, there was also concern about autonomously switching modes.
It may benefit to look back at how modes are switched in communications and Ethernet. The first widespread digital communication devices were voiceband modems which initiate at low rate guaranteed to close the link, and increase the rate as progressively more powerful equalization enables faster and higher order modulation, i.e. same basic idea as proposed by Mike. The drawback is that one doesn't know until after the highest rate is established, how fast the link will be. In contrast, Ethernet has always guaranteed a fixed rate. Even though many optical modules ship as multirate, each rate is a separate PDM spec. The datacenter operator decides when configuring their network which rate to operate at based on what performance the PDM specs guarantee.
This suggests that the desired behavior for selecting whether the inner FEC is bypassed or not, is by the datacenter operator when configuring their network, not autonomously in real time after the module is plugged in. If a shorter latency is not guaranteed, then the link must be assumed to operate at a longer latency for the purposes of defining the network configuration. What the operator needs is information on capability, which means two independent PMD specs, one with inner FEC turned on, and one with inner FEC turned off, available before the network is configured. The BER rate can be one of the many real time diagnostics provided to the operating system, just like optical power and temperature. It is unlikely that the operator would want the module to configure the network.
It would be helpful if any datacenter operator on the reflector chimed in and commented whether there is a benefit for optical modules to configure a network autonomously. If yes, sharing the application scenario would further help understand the need.
Thank you
Chris
On Wed, Jun 28, 2023 at 8:04 AM Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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
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
