| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hello everyone, I support not having the duplex objective which is what Peter has pointed as probably the better choice and is also consistent with option 1 in the presentation we did last week. Thanks Kamal From:
Peter Jones (petejone) <00000b5d1d72f221-dmarc-request@xxxxxxxxxxxxxxxxx> CAUTION: This email is from an external origin! George, Thanks for doing the work on this. Given what you say below, I think that your second option (“No duplex objective at all”) is probably the better choice. I think the asymmetric nature of what we are proposing means it doesn’t fit within the “simple understanding” (at least my simple understanding) of
“full duplex” (simultaneous transmit & receive at the same data rate). I don’t see anyone proposing to implement “1.1.2.1 Half duplex operation” which is defined to use CSMA/CD and doesn’t have any concept of asymmetric
data rates. I think maybe we have the question wrong, and we (802.3) associate “Half duplex” with “CSMA-CD”. As was pointed out on the call this morning, it’s likely that we will choose to use the “Annex 4A Simplified full duplex media access control”.
I don’t like negative objectives, so something like “Don’t support the half duplex mode of the MAC sublayer” is correct, but clumsy and not required.
Adding “Support Annex 4A Simplified full duplex media access control only” would be accurate, but as you say below, leads to the “what’s different”
question we don’t really want to have to discuss. Looking at the draft objectives this morning, the rate asymmetry is somewhat buried in the 62 word “Define the performance characteristics …” objective. We could add something like the following which would be very clear what we plan to do: “Support asymmetric data rates using the Annex 4A Simplified full duplex media
access control.” The data rate asymmetry is part of the draft PAR Scope but not stated explicitly. You could fit inside the draft PAR scope with a PHY that was bi-directional
10Mb/s. We could address this something like the following: Physical Layer specifications and management parameters for electrical media and operating conditions for applications in
the automotive environment supporting asymmetric data rates for operation up to 10 Gbps in one direction and up to Y Mbps in the other direction. That all being said, I think no duplex objective is fine. We don’t have to say what we are not doing, and I suspect that anyone proposing to use CSMA/CD
would face an uphill battle. I do wonder if we should explicitly call out the asymmetric data rates so that it’s crystal clear. Regards Peter _______________________________________________________________ Peter Jones Distinguished Engineer,
Cisco Networking Hardware Chair, Ethernet Alliance
Mobile: +1 408 315 8024 Email: petejone@xxxxxxxxx Web:
https://about.me/petergjones
Webex:
https://cisco.webex.com/meet/petejone Book a call:
http://bit.ly/3ZuzqBs
_______________________________________________________________ From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
All – Thank you for the good discussion on the ‘duplex objective’ at today’s ISAAC meeting. From where I sit, the risk of changing the wording on the duplex objective is that we create more questions in peoples minds than we create clarity. It seems there is clarity
in the study group that everyone involved considers an objective “support full duplex only” to relate to the MAC. Mr. Law suggested that we would be well served to use the same wording unless we meant something different than in the past. I agree that this
is a tried and true path to success. You might think a new wording is clearer, but a change in wording that is well known will generally be taken by the community that you mean something different than what was made before – not that you are refining existing
wording. Additionally, while some of the discussion was about the ‘definition’ of full duplex, inferred from descriptive text, it is interesting to note that in IEEE Std 802.3, the
term “full-duplex” is actually defined. It can be found in the definitions section of the standard (1.4.345), and it is defined relative to a network, DTE, or MAU (but not a PHY). The definition as used in 802.3 refers to simultaneous communication “between
a pair of stations” (which means not necessarily at the MDI or even the MII) “provided that the Physical Layer is capable of supporting simultaneous transmission and reception without interference.” No other reference. This would be consistent with a variety
of duplexing techniques at the PMA/PMD used in 802.3, including echo cancelling, FDD (including WDM) and using separate media (Spatial Division Duplexing).
As recently as 2021 there was a discussion confirming this in 802.3ct – that separate unidirectional WDM streams would comprise meeting the “support full-duplex only” objective,
agreeing with the above. Based on David’s comment about using common-used wording, I went off on an exercise to review the language of duplexing objectives in all the 802.3 projects since the decision
to go ‘full duplex only’ at 802.3ae (10G), a little over 20 years of history. I looked at PHY projects, new rate and new protocol projects. I found that maintenance projects (including corrigenda), power projects, and projects that did not address the physical
layer generally had no duplexing objectives, as expected. What I found in the remainder was a great deal of consistency: - 32 projects with symmetric data rate PHYs (all but 2) either used the language “Support full duplex only” (28, sometimes with a hyphen sometimes not) , or referenced
using existing PCS or other sublayers (4), - Projects with more than one duplex mode used and more than one PHY (802.3cg, for example) called out the duplex mode separately on the PHY – these were all symmetric
PHYs. - There probably should be one more “Support full duplex only” (802.3dg – I hadn’t realized I personally had forgotten this…) - One symmetric PHY project (10GBASE-CX4) did not mention duplex mode. - EEE (802.3az) called out the (MAC) duplex mode of phys referenced (full duplex), and refers to full-duplex 100BASE-TX, clearly the level of duplexing at the
DTE. - Asymmetric projects did NOT call out duplexing, except in the context of EFM’s variable rate PHYs, where it related to data rate capability: o There are 4 asymmetric projects, all EPON (802.3av, 802.3ca, 802.3bn, and 802.3cs) which separately call out objectives for different upstream and downstream
rates, and none of these have a duplexing objective. o EFM (802.3ah) did not have a mac duplex objective, for EPON o EFM (802.3ah) did not have duplex objectives for its symmetric PHYs o EFM (802.3ah) had 2 asymmetric, variable-rate PHYs, this is the only project to call out “full-duplex” related to the PHY, and it was to specify the PHY’s rate-capability
when used bidirectionally. (e.g., “PHY for single pair non-loaded voice grade copper distance >=750m and speed >=10Mbps full-duplex) Again, looking at the history, the only place where the ‘full duplex only’ seems to not be used is with the EPON asymmetric data rate projects, where, I supposed, there could
be confusion with whether the same rate was supported in both directions. There are not variations in the wording, so I would suggest not introducing something new – because it is more likely to be interpreted not as a clarification, but as meaning
something different altogether than what has been meant. Based on the above, I could support either: “Support full duplex only” – used by most projects to indicate use of the full duplex MAC, either clause 4 or annex 4a, Or No duplex objective at all, Both of these, I believe are consistent with prior practice. My support for no objective at all could be swayed if someone involved in EPON believes there was a reason other
than asymmetry that they left duplexing out… I wouldn’t support additional words, as I think they would add confusion and require additional explanation. The consistency of 802.3 on this across more than 20 years and 60 amendments is pretty stunning. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 To unsubscribe from the STDS-802-3-ISAAC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1
To unsubscribe from the STDS-802-3-ISAAC list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-ISAAC&A=1 |