| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 |