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

All,

I haven’t heard an ASIC designer complain about the size of the KR-FEC because it is relatively small as Andre points out. The problem comes in when they want to add the RS-FEC which increases the port area by up to 5 times. I propose we have two PHY options:

1. PHY with KR-FEC – this should work for the 3m objective

2. PHY with RS-FEC and KR-FEC – this should work for the 5m objective

As Brad points out, we should be able to turn these FECs off during auto-negotiation so that you get this scenario that was brilliantly summed up by Rich Mellitz in this graphic.

The CR-N cable would be TBD meters, CR-S would be 3 meters and CR-L would be 5 meters.

Doesn’t that meet everyone’s needs?

Thanks,

Scott

From: Andre Szczepanek [mailto:aszczepanek@xxxxxxxxx]
Sent: Monday, February 23, 2015 2:45 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc

The obvious way to resolve this problem is to Mandate that if you support RS_FEC you must also support Clause 74 FEC.

You then have a clear hierarchy for AN, and reach, without the problem described by Jeff.

I understand that making this a requirement, does increase the complexity of RS-FEC PHYs, but not substantially …

Andre

From: Brad Booth [mailto:bbooth@xxxxxxxx]
Sent: 20 February 2015 18:47
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc

Right now, we're not in that same situation as in 10G. But we could be.

Imagine if we said there's a 1.5 m channel that we can close the loss budget on without FEC, and that we could have a 3 m channel with KR-FEC and a 5 m channel with RS-FEC.

When .3bp did the channel, KR-FEC was created as an enhancement. When .3bj did the channel, RS-FEC was created as a requirement. But, there are scenarios like very short reach links where RS-FEC is not required. Why is that link required to use it? What value does it provide compared to the added latency and power required to run the circuit? How many servers cannot be deployed in the datacenter because of the power used for circuitry that provides to added benefit?

Thanks,
Brad

On Thu, Feb 19, 2015 at 5:18 PM, Jeff Slavick <jeff.slavick@xxxxxxxxxxxxx> wrote:

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

310-920-3860

(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