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

[George Zimmerman <george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I think the issue here is what is the difference between a separate ‘phy type’ vs. what is a ‘phy type plus an option’.  Many projects hit this same question – when does an optional function become its own PHY type It’s a bit philosophy, and a bit marketing – but ultimately it comes down to usefulness, and the sentiment of the standardizing group (which IMO is the greater ‘dot 3’ group when the objectives say something like “define a single PHY”, but in our case they specifically do not, so I believe it to be the task force).

 

I think Dan has hit the use case on the head.  If ‘compliant’ specifies a certain channel, and the two PHY types have different channels, then users (people who plug a cable into a port, not necessarily people who design the switch, or even people who purchase the switch) need a ready way to identify that their PHY type only does channel A or channel B.  Otherwise users will be dissatisfied.  The port capable of only one channel due to lack of an option may take less to implement, but unless the difference is so significant that it is a major impact on cost and power (as some have asked for information), it will become like other less-expensive-but-not-fully-functional items: “cheap” rather than “inexpensive”, “efficient” or “value”.

 

Brad made a statement yesterday that yesterday on the call that I bristled at, perhaps in misunderstanding his meaning, that ‘each decision needs to be viewed in terms of broad market potential’.  I do not agree with that literally, nor do the 802 operating rules – the whole project needs to be viewed in terms of broad market potential.  BUT, there is truth in considering this, if the decision divides the project in such a way that there is no single market large enough to be satisfied.  I would put forward that on a potential binary splitting of the market such as this, if that were true, I’d say that even together the broad market potential was shaky – a factor of two just isn’t enough given the uncertainty in predicting the future.  But, I digress…

 

The BASE-T world has hit the ‘reach-sensitive’ PHY issue many times.   If you use the same channel connector (MDI – after all, that is why it is called “media DEPENDENT interface) and PHY port labeling, the -  Eventually, as many have now pointed out, it comes down to incremental cost and power. 

 

On the issue at hand, IF there are some subset of users that are perfectly happy with engineered systems to tolerate an option which only does a subset of the channel, but cannot tolerate the incremental cost or power, then they should consider whether they justify a broad market in and of themselves – AND, the remaining part of the market needs to consider the same.  I thought there were many presentations in study group which led to the conclusion that the broad market needed reach beyond the 3 meters.

 

If a single large customer or customer group can tolerate special deployment rules, then make it an option, which is a MANDATORY CAPABILITY in a compliant port.  In that case, it only comes down to die area or other issues which impact cost – as there are many ways to save power on a disabled function.

 

In my opinion, as Gary points out, a true “optional capability” only works when the links hook up, but the end user is enabling an ancillary function – for example, a ‘low latency mode’, or ‘energy efficient ethernet’. They can look for the feature and enable it for an improved performance, but if the other side doesn’t have it, they still get a functional link on their channel.

 

Then, there are multiple PHY types, which our objectives, as written, seem to lead to - When that single customer or group can’t tolerate the die area/cost hit, then the group needs to consider multiple PHY types.  Ultimately, this is the hardest to analyze, as economic feasibility comes to play, because each piece of the market needs to bear a bunch of costs on its own.  In that case, everything will be well labeled.  Personally, I’d recommend making the MDI different too, to avoid confusion, but I’ll leave that to the implementors – enough from the philosophy department for now.

 

I would say that until someone addresses the questions of relative die area & cost – relative to impact on the overall system - of having a MANDATORY CAPABILITY (enabled as an option), I default to that camp, as it gives the “broadest applicability” and the most “numerous number of users”.

 

 

 

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: Gary Nicholl (gnicholl) [mailto:gnicholl@xxxxxxxxx]
Sent: Thursday, February 19, 2015 7:18 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc

 

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