Dan, you phrased my thoughts exactly, much better than I could do it.
I originally thought there should be one PHY with mandatory 5 m capability and optional lower-latency modes that can be negotiated. That would meet the CSD
and our objectives.
Then there is the apparent desire to save the added cost of RS-FEC (which I'm still not sure about) for some applications. We do have a separate 3 m objective
so it is a reasonable goal. We could bifurcate the market to short and long reach that are incompatible – of course, nobody wants that.
The separate PHYs that Jeff implicitly assumed in his presentation enable having both objectives covered, while maintaining compatibility/interoperability,
and actually clarifying the picture for customers.
Brad, Rob, I think the bifurcation you are trying to avoid is already there. As Rob points out, large installations would favor optimized solutions. So there
will be parts that only have clause 74 FEC and support up to 3 meters, others that only have clause 108 FEC and support up to 5 meters, and very likely, parts that include both FECs and are interoperable with either of the above (and possibly parts that have
no FEC to make things more interesting…) If my company makes several different parts then they will surely have different part numbers and/or product names.
Now, what do we get by not calling out the differences in a standardized way? How would it help the market?
To me it seems analogous to not having different categories for sports cars and SUVs and just calling them both "automobiles". Sure, you could read the specifications
of each vendor to find out what car fits your need. If you buy the wrong car, you could call customer service to try to solve your problem, and eventually return it to the dealer. Would that be good for the market?
My bottom line: if RS-FEC is practically free, let's make it mandatory and have one PHY type. Otherwise, have two (or three) PHY types according to capability,
and let customers make an informed choice according to their need.
</Adee>
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxx]
Sent: Thursday, February 19, 2015 8:17 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
Rob
What is your estimate of RS-FEC percentage of power dissipation on these high radix switches?
If RS-FEC is 5% of switch power dissipation then defiantly I agree with you that having two district PMD instead of super-set is the right way to go but if the RS-FEC is adding something like 1-2% in 28 nm and <1% in 14/16 nm then it is
in the noise!
On Feb 18, 2015, at 4:06 PM, Rob Stone <rob.stone@xxxxxxxxxxxx> wrote:
Hi Ali / Dan
The point about “plug and play” compatibility is well made, but from a device vendor perspective, we are pretty careful to make sure our customers understand
well the capabilities of the silicon and that it is compatible with their channel requirements.
I also see the trade-offs a little differently. For large scale homogeneous deployments, I think maximum flexibility to optimize the efficiency of the design
(i.e. not adding extra FEC modes you won’t use) outweighs the need to build a single universal part which blankets all use cases. This is becoming more acute if you look at the larger high radix switches – where we are typically power and area challenged.
I think that if we designate two separate PHY types (-S and –L) and then rigidly tie these to particular FEC modes of operation it circumvents the purpose of
autonegotiation and HCD resolution, and it does fragment the market as Brad pointed out. You could achieve the same end goal, by only advertising FEC modes which are available and are compatible with the cable, or channel you are operating over.
Thanks
Rob
From: Ali
Ghiasi [mailto:aghiasi@xxxxxxxxx]
Sent: Wednesday, February 18, 2015 3:35 PM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
Dan/Brad
Here is an approach to make -S and -L CR standards interoperable by creating super-set PMD but still address potential low latency applications:
o. Host
- Baseline capability RS-FEC
- Optionally host my implement and/or support CL74 or no FEC
- Mechanism to advertise what is supported under system management
- All host must support the maximum reach and both -S and -L cable reaches
o. Cables
- CR-S any cables shorter 2-3 m (with xyz loss) if plugged into host the management may invoke CL74 or no FEC
- CR-L any cable longer >2-3 m (with loss >xyz) if plugged into host will use the default RS-FEC
With above approach we are not creating two PMDs, single common host is created but cables are labeled -S and -L depending on the cable length.
<image001.png>
On Feb 18, 2015, at 2:44 PM, Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx> wrote:
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.
<jfajahhg.png>
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