|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
In general, I was trying to parse your comments (which summarized some of the others’ comments).... only to find you parsing mine right back… very amusing :)
Regarding your questions:
Am I proposing aggregating 10G MACs? I am looking for a solution which might avoid development of all new silicon, so at some level I guess the answer is YES but I don’t think I have a clear or viable conception of how precisely to do so. NOTE: This is different from the CFI slides because you insisted that for clarity we only show one MAC even though we’d discussed that other alternatives were permitted. I agree that we’d have to make it different than LAG and this might be accomplished in the PHY through some kind of striping mechanism. Personally, I’m more interesting in working out the issues of the PHY and PMD.
Question: If the MAC is to be a Single Chip (per your comment about the CFI) and the PHY/PMD will at least for datacom economics need to be a single package, then what is to be scalable and how will that be beneficial?
Regarding proposing a failover objective. This only would be applicable & necessary if some form of scalable / variable aggregation of lanes is supported then this would likely come for free (if the implementation sensed which lanes were working rather than just being told that the port supports 40G vs 80G vs 100G, etc in the negotiation). It only seems appropriate to present on this topic in the future after we settled on the nature and bounds of the scalability issue.
Regarding proposing a new rate objective. Yes, I think 80G should be considered as the rate to be supported (instead of 100G); not as a minimum but as the actual rate. The actual PHY would be 8x10.3125G. Yes, it is heresy… but at one point so was suggesting that the Earth revolved around the Sun. :)
Regarding pros & cons of a scalable solution:
This may need to be broken into scalability of lane rate & scalability of number of lanes. Here are some general CONS which are admittedly inter-related…
From: John DAmbrosia
Please see comments below-
From: Roger Merel
I agree that John’s email outlines the basic options for the MAC; however, I have some questions.
If the Option (B) MAC isn’t 10G based, then obviously the development of a new MAC is required. However, even if the MAC is 10G based, would there still be any changes required necessitating a new 10G MAC design?
JD > I am not sure what you mean by this. The 802.3 MAC specification is bit serial and speed agnostic. I understand the modifications for speed to be fairly straightforward. Are you proposing aggregating 10G MACs? This is different than what we discussed in the CFI, which always showed a single MAC. The Physical Layer Aggregation we have been discussing is below the MAC. You seem to be suggesting aggregating above the MAC, which I understand to be essentially LAG. Can you provide further clarification?
Does Option (A) preclude the use of multiple 10G MACs working together? (I think not, but I’d like others’ thoughts.)
Does Option (A) preclude including features which allow for less than all of the HSSG “lanes” working? (I think not, but I’d like others’ thoughts.)
Does Option (A) require that the MAC is implemented in a single chip (whereas Option (B) does not)? (I think not, but I’d like others’ thoughts.)
JD > First see above regarding discussion of MACs. The two options listed were the options I had seen discussed on the reflector for MAC rate. It looks to me like you are suggesting adding a failover objective. Is this correct? Are you considering doing a presentation on this potential objective for the September Interim?
There definitely is a sense of justified pride by the long time members regarding the fact that (unlike Fiber Channel), each new step in Ethernet was a large step which avoided lots of small increments which still required significant product re-development / inefficient investment.
I am concerned that the soft-scaling being considered here will mean:
(1) Different System Vendors will choose different scale factors and won’t actually be able to talk to each other as efficiently as they talk to their own boxes. E.g. is Vendor A implements 40G and Vendor B implements 100G… they would talk to each other at 40G but this creates a disincentive to cross vendor boundaries since there is an expensive 100G port being under utilized at 40G.
(2) We have taken the progress for certain steps of the out of the standards process, but allowed for Vendors to make the small incremental steps (e.g. multiple factors of 2x)… a Vendor starting with a 40G implementation can go to 80G then 160G. Since 100G will undoubtedly be hard just as 1G and 10G were hard, we have created an incentive for some to take the easier step now especially if it fits better into their existing system capacity. Thus we will share the same fate as Fiber Channel in terms of cycle of investment.
Does Option (A) have to operate at exactly the traditionally 10x? Is 80G out of the question? It’s less than 1dB difference, is a 2^n factor making certain issues easier, and would allow for coinciding with SONET/SDH speeds more often in the future.
JD > As mentioned, I only included those options I had seen on the reflector. Are you suggesting that 80G should be added as a candidate for the MAC rate? Or are you suggesting that we replace the 100G rate with a minimum data rate of 80G? Please clarify.
While this conversation thread is focused on the MAC, it seems to have neglected to consider that vendors will have to make PHY/PMDs that work with these MAC options. When people have voice support for Option (B) are they also suggesting that they support a Scalable PHY/PMD?
I can understand why the MAC should be scalable and how that can save development costs / investment; however, making a Scalable PHY/PMD would seem to me to mean increased PHY/PMD development costs, lots of different “flavors” of PHYs to be developed, not volume behind any single “flavor”, and worse unit economics…likely worse than linear scaling…e.g. worse than 10x$$ for 10xBW.
Does Option (B) for the MAC preclude a single fixed PHY/PMD implementation? (I think not, but I’d like others’ thoughts.)
Is a Scalable PHY/PMD desirable? (I think not, but I’d like others’ thoughts.)
I certainly want to re-use 10G MACs, if possible, to improve the economics for 10G and reduce the new investment required for HSSG. There are likely some silicon or system vendors working on Quad 10G MACs, etc. Using a Scalable MAC approach will allow that density improvement to be utilized for HSSG as well.
However, I think it would be a huge mistake (particularly for the short distance / datacenter / enterprise applications) to believe that allowing freedom in the scaling value of N would somehow make the PHY/PMD situation better. It would not be good for PHY/PMD developers, nor for customer interoperability / multi-vendor internetworking. We certainly have a responsibility to consider economic dynamics that will be created the by features of the standard we choose to implement.
JD > My sense is that we will see strong opinions on both sides of a scaleable solution. I encourage individuals to start discussing this on the reflector as soon as possible, as well as bring presentations forward to the September that look at the pro’s / cons of both the fixed and scaleable solutions.
Thank you for a very succinct summary of the two proposals.
Without repeating any arguments, I am strongly in favor of a scalable approach - proposal B
(which should continue another tradition - a tradition of successful implementation)