Re: [STDS-802-3-25G] Thoughts from today's ad hoc

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

Thanks,

Ali Ghiasi

Ghiasi Quantum LLC

Office (408)352-5346

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.

Thanks,
Ali Ghiasi
Ghiasi Quantum LLC
Office (408)352-5346
aghiasi@xxxxxxxxx

<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