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

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

Ali,

Thanks for providing numbers. I'd like to see confirmation on the numbers, and perhaps as the overall relative size of a PHY.

If in fact, we are arguing about the 650CCA battery vs 500CCA battery, I would argue that we should have a single PHY that requires RS-FEC, CL74 FEC, and the ability to negotiate either or none based on configuration.

What I would oppose is having two PHYs that support only RS-FEC or only CL74 FEC and claim to be the same thing. If in fact, the difference is negligible, there is no benefit to having two different PHYs and it would only divide the market.

Personally, I believe this issue can be readily resolved with numbers. (as you have provided)

The market impact is subjective, but if we are truly talking about a few percent of overall die,cost,complexity, getting agreement that its not going to impact the market to have a one-size-fits-all would be easy. As the percentage grows, the problem of market impact will be more difficult to assess.
Dan Dove
Chief Consultant
Dove Networking Solutions
 530-906-3683 - Mobile
On 2/19/15 1:48 PM, Ali Ghiasi wrote:
David 

What I purpose was to create super-set host that can operate with both -s (3 m) and -L (5 m) cables, which require RS-FEC (528,514) to be the default mode.  The -s cable if plugged in to the host could evoke CL 74/no-FEC to support lower latency.  Single host type is defined but two cable designation.  The type -s cable just means any cable <=3 m and type -L means any cable>3 <=5 m.

No one disagree about the 1-ton Cummins engine, the FEC in my opinion is more like how big a battery to use on that big engine 500 CCA vs 650 CCA!  In the bs project there is a nice tabulation of various FEC gate count, http://www.ieee802.org/3/bs/public/15_01/gustlin_3bs_03_0115.pdf
So we are debating if 140K gate is too expensive to add to the big switch ASIC and instead bifurcate the market by introducing two non-interoperable PMDs!



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

On Feb 19, 2015, at 11:53 AM, Malicoat, David (HP Networking - ATG) <david.malicoat@xxxxxx> wrote:

This is a challenging problem without easy answers.  It feels like we are trying to make some tough decisions without enough data.
 
Brads comment about interoperability having no guarantee and the reason for UNH testing.  True, but this is to validate different physical implementations (ASICs & Systems) of an interoperable specification.  By having non-interoperable features in a spec, it is setting up the systems provider with additional product SKUs, and end customers with interoperability frustrations from the start.
 
My thoughts resonate with George’s comment that two devices that are labeled the same thing should support a common PHY type.
Dan/Gary made some very good points and whether the customer wants it all with the Dodge 1-ton Cummins and pay for the Dakota package, or vice-versa.  This just highlights that we have a mismatch between expectations and what is provided.  Without having a breakdown of actual market volume between 3m and 5m usage to validate Dan’s Venn diagram, I don’t see a successful end to this discussion.
 
For me we also need to have an understanding on the relative die area and cost between the 3m and 5m solutions, we will continue to not have enough data to make an informed decision.  With an understanding of relative costs, and estimate mix between 3m and 5m, we can then do our respective ROI analysis of developing separate products for both 3m and 5m markets or just a single products that will cover both.
 
Without enough data, system vendors will be selling Dodge Cummins to cover the largest addressable markets with the minimum of products.  The customer that needs/wants the Dakota will then be looking for special builds vs. mainstream volumes.
 
David
 
David Malicoat
Enterprise Group, HP Networking
Distinguished Architect, Data Center & Core Advanced Technology Group (ATG)
Office: (916) 785-3092
Lync: (916) 540-1455
 
 
 
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx] 
Sent: Thursday, February 19, 2015 10:54 AM
To: STDS-802-3-25G@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-25G] Thoughts from today's ad hoc
 
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
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.


<image001.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