|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I had several off line conversations prompted by my Dialog reflector email and have been pleasantly surprised to learn that there is almost uniform agreement about the need for 200G Ethernet and Nx50G (N=1,2,4) PMDs. This is a nice change from where we were even at July meeting.
The major questions facing us now are whether 50G and Nx50G are one project or two projects, and what PMDs to standardize in the project(s).
Steve Trowbridge nicely summarized the status and complex dependencies of the project organization choices in a private email exchange, and with his permission I am sharing his observations verbatim.
< It SEEMS LIKE 50G could be a faster project than 200G (or 2^n*50G), and it SEEMS LIKE the market need for 50G would be earlier than the market need for 2^n*50G, BUT:
· 50G is only a “fast” project (like P802.3by) if it is opportunistically reusing the 50G lane technology from P802.3bs. But all you get if you do this are SMF PMDs and a single lane LAUI chip-to-chip and chip-to-module. These don’t seem like the ideal PMDs for what many think is the initial application for single-lane 50G, which is server to ToR in the cloud scale data centers. If you add a (long) backplane 50GBASE-KR, a 50GBASE-CR copper cable, and a 50GBASE-SR PAM4 MMF (which seems like what would be desirable for a project like this), since you didn’t have a bj or bm equivalent project to do those lane technologies for you, they need to be done in the 50G project, which makes this a long, slow, difficult project.
· If you were to decide to do a “fast” 50G project with only SMF PMDs, and leave the heavy lifting for a 200G or 2^n*50G project (e.g., develop 200GBASE-KR4, 200GBASE-CR4, and 200GBASE-SR4 in this project), then for sure you would want to not couple the time scales since the 50G project would be done a lot faster. But I am not sure it is realistic to leave all of the “hard” PMDs out of the 50G project.
· If you do all the heavy lifting in the 50G project, then the 200G or 2^n*50G project becomes a simple, almost “logic only” project (and even the logic isn’t hard – it is mostly scaling down what 802.3bs has done), then there is no reason the 200G spec couldn’t be done the instant that 50G is done. So in that case, the only reason for putting 50G and 200G in different projects and on different timescales would be if the market need for 200G is substantially later than the market need for 50G. >
One of my key take away points is that we don’t know enough now to be making decisions about what should be the project structure and content. Which means that 802.3 processes which were designed to deal with just such uncertainty should be fully taken advantage of to make our decisions.
Thanks Chris for opening the discussion.
You have expressed my views better than I would have myself. J
The Industry Connections meeting last night missed an opportunity to substantially discuss the major issue in front of us: what next Ethernet rate(s) and associated PMD(s) are important to industry. We heard well prepared presentations which raised important technical and market considerations and presented two different views of what’s important. Unfortunately there was no time for questions and most of the subsequent discussion time was allocated to administrative issues. At end of the meeting, we agreed to start discussion on the 802.3 Dialog Reflector.
Mark’s presentation proposed 50G Ethernet and 40G and 50G Serial PMDs as the next important industry priority. Scott’s presentation proposed 50G and 200G Ethernet together as the next important industry priority, supported by nx50G (n=1,2,4) PMDs. There was broad agreement before and during the meeting that the workload to standardize everything is huge. Regardless of how we end up slicing the work: by Ethernet rate, by PMDs, or by functionality (logic, copper, optics, etc.), we have to prioritize.
As a contributor to Scott’s presentation my position is that what’s important to industry is the standardizing of 50G and 200G Ethernet together, and at a minimum backplane, chip-to-chip and chip-to-module interfaces (LAUI, CAUI-2, CCAUI-4) to enable designing next generation mainstream data center ASICs and switches based on 50G PAM4 technology. This is followed by copper cable, MMF, and short reach SMF to enable 50G and 100G server I/O, and 200G switch uplinks. 400G is already in standardization so that will be available as an uplink option. (As an aside, the pronunciation of CCAUI: kha-ka-wee, sounds like an espresso drink as in “I would like a double kha-ka-wee, 2% milk.”)
The need for 200G Ethernet has been repeatedly challenged as not demonstrated. That misses the point. The need for an Ethernet rate above 100G is clear. 50G servers need faster speed switch uplinks than 100G. The real question is whether that rate is 200G or 400G. Industry roadmap of 10G server I/O with 40G switch uplinks, followed by 25G server I/O with 100G switch uplinks, followed by 50G server I/O with 200G switch uplinks has many strong arguments in favor of it, as in Scott’s presentation.
What has not been demonstrated is a broad industry need for 40G Serial PMDs. In fact just the opposite is the case. Once 50G Ethernet and PMDs are standardized, 40G Ethernet will plateau and decline. That’s because 50G Serial cost will be the same as 40G Serial cost, but offer 25% more bandwidth. Few new deployments will chose 25% less free bandwidth. There will be some 40G Serial applications, but the importance of these is insignificant compared to the need for 200G Ethernet as the next high-volume low-cost datacenter switch uplink rate. This is where the need to prioritize comes into play.
Hopefully the above is enough to start a vigorous discussion on the Reflector of what next Ethernet rate(s) and PMD(s) are important to industry, including their relative priority.
I have uploaded the webpage with the material for tonight’s meeting. Please see http://www.ieee802.org/3/ad_hoc/ngrates/public/15_09/index.html.
We will being promptly at 7pm tonight in Estero A/B.