Brad,
In my presentation I had noted that we are seeing support for x8 ports, and I left it open-ended asking are there other trends we need to consider.
Your presentation noted 32 lane chiplets, so I thought you were suggesting that a x16 chiplet could be essentially something that would need to be supported.
Hope you see my “fuzzy” logic now 😊
John
From: Brad Booth <bbooth@xxxxxxxx>
Sent: Monday, March 8, 2021 2:17 PM
To: jdambrosia@xxxxxxxxx; STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_B400G] Clarification on my presentation
Hi John,
I have not seen any proposals for 16x 200G PHYs, so I cannot speak to that. Correct me if I’m wrong, but I believe there are currently no adopted PHY proposals; therefore, I cannot speak the adoption of x16 as a potential PHY for 1.6T.
I hope that helps.
Thanks,
Brad
From: jdambrosia@xxxxxxxxx
Sent: Monday, March 8, 2021 11:11 AM
To: Brad Booth; STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_B400G] Clarification on my presentation
Brad,
I want to thank you for utilizing the reflector to assist in building consensus.
Just to be clear my question wasn’t as simple as described below.
I wanted to understand if you would propose a 3.2T MAC rate if your proposal described below was not accepted. This is really aimed at understanding if we need to accommodate up to x16 going forward, and not just x8 going forward.
Regards
John
From: Brad Booth <bbooth@xxxxxxxx>
Sent: Monday, March 8, 2021 2:06 PM
To: STDS-802-3-B400G@xxxxxxxxxxxxxxxxx
Subject: [802.3_B400G] Clarification on my presentation
All,
Our illustrious chair reached out to me about if I was planning to propose a 3.2T MAC because it was interpreted that I was proposing the ability to support 16 lanes of 200G. This highlighted to me that my messaging in my presentation (https://www.ieee802.org/3/B400G/public/21_03/booth_b400g_02_210301.pdf) may have been misleading. For that I apologize.
I am not proposing that we create a “new” MAC that’s flexible and enables the ability to create or justify PHY combinations. What I am proposing is a very, very simple modification to Table 4-2. Currently, there is one (very crowded) column that highlights the requirements for the MAC parameters for: 2.5G, 5G, 25G, 40G, 100G, 200G and 400G. For all those speeds, and very likely for all future speeds, those parameters will remain unchanged. The reason that the lower speeds (<1G) and 10G are not in that column is because of half duplex operation and 10G WAN mode, respectively.
In my opinion, the study group would need to have an objective to do a “service to humanity” to change the column. What I am proposing, as Mark Nowell stated, is to make it so we can (in the future) ignore the MAC. One change by the eventual B400G task force would eliminate the need for future MAC data rates to have to touch that table.
As for giving creative license to opening up Pandora’s Box for the PHYs, the process used by 802.3 does not permit it. The study group (and any future study group) would need to justify the physical layers they wish to specify. During the Q&A, someone asked me if my proposal meant a 1T MAC PHY would be possible, and I stated no because I was assuming binary speed increments. I realize now that with the change to Table 4-2, that my requested modification would not prevent it people creating a 1T PHY proposal. Of course, the proposal would require support of the SG to adopt that objective.
What I do think is critical to highlight is previous speed iterations and even this SG have focused on the MAC rate as the boundary for PHY development. That used to work in the past when 802.3 used to do 10x MAC increments. Then we went to 4x with 40G. And during the last project, we went to 2x with 200G and 400G. But, as I highlighted above, the MAC parameters have remained the same. The work the study group does in creating the objectives is really about justifying the PHYs. That’s the lion’s share of the technical work done by the Task Force.
Given that the bulk of the technical work is with the PHY and 802.3 is supporting multiple bandwidth capabilities with the PHYs, why do we want to revisit Table 4-2 every time we want to increase the MAC rate? I’m proposing we stop that insanity. 😊
Thanks,
Brad
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1