Hi Jeff,
At the moment, there is not enough data to define the reach that might be achievable without FEC.
When a customer chooses the two PHYs (one with RS-FEC and one with CL74 FEC) and tries to have them interoperate, they should presumably already be aware that there is no reach defined by the IEEE in the case of no FEC (as of now).
If the group defines a reach for the no-FEC case, then the point you make is valid. But then at that point, the customer would already know what reach can be achieved without FEC.
Best regards,
Principal Electrical Engineer, Signal Integrity
Dell | Networking Business Unit
office +1 408 965 5876, internal 405 5876
5450 Great America Parkway, Santa Clara, CA 95054
From: Jeff Slavick [mailto:jeff.slavick@xxxxxxxxxxxxx]
Sent: Thursday, February 19, 2015 5:19 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
Hi Brad,
"Because it would permit me to buy a PHY with only RS-FEC supported and a PHY with only Clause 74 FEC supported, put them on a 1 meter link and have them negotiate to not use FEC (highest common denominator). "
So you bought a PHY that says it supports up to 3m and a second that supports up to 5m, but if you plug in a 2m cable the link can't stay up (assuming maximum cable length without FEC is 1m). But they're sold as the same Ethernet PHY type with different reach supports and you're using a cable length that both PHYs state they support? Is that acceptable?
At the 10G serial rate I thought that we closed the maximum link budgets without the Cl74 FEC and thus it's an enhanced feature that allowed you boost the performance of the link for a cost (to overcome out of spec channel, more interference or improved BER). I don't think we're in that same situation at 25G.
-Jeff
---------- Forwarded message ----------
From: Brad Booth <bbooth@xxxxxxxx>
Date: Thu, Feb 19, 2015 at 3:42 PM
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
George,
Exactly.
I think part of the reason for the difference of opinion is whether or not you see FEC as being an enhanced operating mode of the PHY.
Personally, I'd rather see it as an operating mode. Why? Because it would permit me to buy a PHY with only RS-FEC supported and a PHY with only Clause 74 FEC supported, put them on a 1 meter link and have them negotiate to not use FEC (highest common denominator). With the CR-L and CR-S variants being pushed today, I believe it would result in a non-compatible mode; there would be no highest common denominator.
While the task force does have two reach objectives, I believe the market would be much happier to see one PMD with multiple modes of operation rather than multiple, inoperable PMDs.
Thanks,
Brad
On Thu, Feb 19, 2015 at 10:54 AM, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Brad – two devices labeled the same thing should support a common autoneg PHY type. That is why we label them so users know them from each other. If not, then they are not the same PHY type and should be labeled differently. For example, a port labeled “1000BASE-T” is a different thing from a port labeled “1000/10GBASE-T”. The 1000/10GBASE-T port indicates a second PHY type in addition to the enhanced capability (10GBASE-T), and the two will interoperate at the 1000BASE-T PHY type. BUT, if someone were to make a PHY that was just 10GBASE-T, the 1000BASE-T and a ‘just 10GBASE-T’ wouldn’t interoperate. (I know you know this, but some people don’t, it’s amazing how many people think the standard requires lower speed support on BASE-T PHYs, because the market demands that lowest common denominator be supported)
In contrast, an OPTION, might be like optional EEE capability, where both PHYs are labeled the same and interoperate and pass data without the function enabled. You still get data passing without it.
The concept of OPTION becomes problematic to apply when you go to a shorter media type – even when the option is for the extended reach capability – because the media isn’t part of the port where the labeling sits – hence, you might have 2 PHY types, or one type and a mandatory capability.
The question you are asking is not about autoneg – it is about whether we have 2 PHY types.
George Zimmerman
Principal, CME Consulting
Experts in Advanced PHYsical Communications Technology
george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(PLEASE NOTE NEW EMAIL ADDRESS. THE OTHER WILL STILL WORK, BUT PLEASE USE THIS FOR CME BUSINESS)
From: Brad Booth [mailto:bbooth@xxxxxxxx]
Sent: Thursday, February 19, 2015 10:39 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
That is the crux of the issue.
One aspect that does seem to concern folks is that if two devices are labeled CR that they may not interoperate even though the port names are the same. That is why autoneg is used. It determines if there is a possible mode of operation. If there is a mode of operation that is compatible for both devices, that is the mode they come up in and the standard better be written in a manner that permits them to interoperate.
As for interoperability in the market, there is no guarantee for that. If there was a guarantee, there would be no need for qualification labs, test equipment or UNH-IOL.
Thanks,
Brad
On Thu, Feb 19, 2015 at 7:18 AM, Gary Nicholl (gnicholl) <gnicholl@xxxxxxxxx> wrote:
Dan,
Thanks for your email. I think you hit the nail on the head. The issue is really with the definition of ‘option’ or ‘optional’ . There is obviously a very big difference between “option to include in the implementation” and “option to use in a given application”.
This is something that has always confused me when people use the word ‘option’ in standards. If people mean “option to include in the implementation" then I don’t see how that can ever result in an interoperable standard, and your example below clearly spells that out .. and no amount of auto-neg will help the situation. However if option means “option to use in a given application, but required in all implementations” then this does provide an interoperable standard, with the benefit of the being able to use something like auto-neg to turn the feature off if not required in a given application/configuration.
Gary
From: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Organization: Dove Networking Solutions
Reply-To: Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx>
Date: Wednesday, February 18, 2015 at 5:44 PM
To: "STDS-802-3-25G@xxxxxxxxxxxxxxxxx" <STDS-802-3-25G@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
Hi Brad,
I think the counter argument goes like this...
If you have only a single instance in the market called "25GBASE-CR", and it allows someone to build a product that supports only 3m cables (does not advertise 5m capability), a customer will purchase a bunch of switches, 5m cables, 3m cables, and servers, all from different suppliers, plug them all together..double checking to make sure they are all "25GBASE-CR", then discover that some combinations of products don't talk to each other.
They scratch their heads, look for details on what the common modes of failure are, then come to a conclusion that only supplier X switches, and supplier Z NICs, and 5m cables are problematic. supplier Y's stuff is working with all cables. They go to supplier X and supplier Z, explain their problem, and those suppliers say "We are compliant to the standard, but don't support 5m cables".
What!?!?
"Oh ya, the RS-FEC required to support 5m cables was optional, and because it added X% to the die, our chip supplier left it out of the design to save cost and power...but we are still compliant!"
Clearly that doesn't work out well.
I see the challenge as this;
If there is no significant cost/power/die/etc impact of supporting 5m over 3m, then we should have a single "25GBASE-CR" standard and mandate support for all cable lengths. Deciding not to support RS-FEC would be an option for applications with shorter cables to reduce latency, but only an option to use, not an option to include in the implementation.
If there IS a significant cost/power/die/etc impact of supporting 5m over 3m, we have to consider whether that additional cost/power/die/etc will burden markets that want optimum cost/power/die/etc and don't need 5m. If yes, then we should have two specs (CR-L and CR-S) to allow market optimization. If not, then we force the market to accept one-size-fits-all.
To be frank, I have no preference in where we end up, but do wish to see the key questions answered with sufficient data to make the right decision.
Dan Dove
Chief Consultant
Dove Networking Solutions
530-906-3683 - Mobile
On 2/18/15 2:05 PM, Brad Booth wrote:
I want to say thanks to Jeff for listing some of the options the task force can consider for auto-negotiation. All the options presented by Jeff and Eric could be specified in the draft standard.
I'd like to provide some clarification on my opposition to using -L and -S options. The primary concern I have is reflected in statements some people have made in justifying the -L and -S options. In my humble opinion, the -L and -S options push the draft standard towards being an implementation specification and permitting folks to market their devices as either -L or -S compliant. This could create a potential bifurcation of the market; hence my request for those supporting a -L and -S option to provide information on the broad market potential.
As an example of auto-negotiation not used in as an implementation specification, let's look at 1G. There is a load of information that is exchanged during auto-negotiation. In 1000BASE-X, AN exchanges pause and duplex information. In 1000BASE-T, even more information is exchanged like master-slave, etc. What is important to understand in the operation of these devices, a management entity assists with the establishment of the link. If a 1000BASE-SX local device only indicates half duplex and its 1000BASE-SX link partner only indicates full duplex, then AN will signal to the management entity that the link cannot be established. The half duplex device is not labeled a 1000BASE-SX-H device and the other is not labeled a 1000BASE-SX-F device; those labels would be an implementation option. The management entity could decide that either these devices can never talk, or that auto-negotiation needs to be restarted with a different exchange of capabilities.
That's what worries me about using -L and -S in AN and tying it to the port type or maximum cable assembly length. That's an implementation. And honestly, -L and -S starts to sound like marketing terms and not technically justified terms. Permitting AN to exchange capabilities and preferred modes of operation (no -L or -S option) really does provide the greatest flexibility for implementations in the market.
Thanks,
Brad