First of all I agree on your view.
In my humble opinion is almost the same to go for the FD optional / HD mandatory or vice versa. From recent simulation results I can say that, unless the channel changes, the increase in complexity between FD and HD in the Phy is quite limited.
That said, I'd go for FD optional as it makes things simpler from my perspective.
Just my 2 cents contribution.
On December 8, 2017 2:56:58 AM GMT+01:00, George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:
There was one more subject to discuss that I didn’t mention in my last email – our objectvies.
I’ve been thinking about how we properly construct our objectives to reflect what we want to specify, full-duplex, half-duplex, short-reach, long-reach and multidrop, and below are some thoughts for consideration. It is important to know
WHAT we want to reflect before wordsmithing.
The issues I have heard are:
- We would very much like to construct the objectives so that we have only 2 phy types in 802.3cg. There can be options within these. See more below on phy types vs. options.
- Both full-duplex and half-duplex pt-to-pt short reach PHY operation is desired. (duplex mode should be optional)
- Multidrop half-duplex mode short-reach PHY operation is desired. The mixing segment insertion loss is similar to the short-reach link segment. (personally, I’m not sure enough work
has been done on this, and have been asking the cabling proponents to do more).
Getting this within 2 phy types is where the art comes in writing the objectives. That is what Peter and I were trying to do with our draft. Not sure it’s there yet. What you suggested reads as 3 distinct PHY types.
- The long-reach 10BASE-T1L is one type. The losses of the long-reach line mean it has to use fairly efficient line coding, which also means equalization.
- The short-reach PHY, both point to point and multipoint, full-duplex and half-duplex therefore needs to be the other type. In order to make them one phy type, in my mind, they need
to have a least-common-denominator mode where you have interoperability. If they don’t interoperate, it’s hard to call them the same phy type. We’ve made the decision that multidrop is optional, and it seems clear that multidrop half-duplex is an extension
of pt-to-pt half-duplex because where there are more nodes. Therefore, with multidrop capability optional only when half-duplex is present, here are the options I see:
- Half duplex mandatory, full duplex optional
- In this situation, all phys speak half-duplex pt-to-pt and therefore have an interoperable mode. Pt-to-pt full duplex is an add-on with the extra complexity it requires in the PHY
(remember, half-duplex gets extra complexity, but it is in the MAC).
- Full duplex mandatory, half duplex optional
- In this situation, all PHYs have the capabitily for full-duplex pt-to-pt. this seems to burden the half-duplex and especially the multidrop PHYs which may never need echo cancelling
or faster signaling.
- Half duplex optional, full duplex optional
- This one doesn’t seem to work. I don’t see how a PHY only speaking half-duplex can speak to a PHY only speaking full duplex. If full-duplex-only and half-duplex only are both acceptable
options, then you have two types – whether you want to call them that or not – they don’t interoperate. This option seems to result in the full-duplex only PHY being another PHY type. You could build phys that support half, full, or both, but that would
have to be selected just like selecting transmission speed (100BASE-T or 1000BASE-T) in autonegotiation.
If this is all correct, and we have consensus on those priniciples, then we can go about wordsmithing the objectives to say what we mean. However, I think we need to agree on what we want to support first.
The other option would be to have consensus that we want to build more than 2 phy types.
In that case, full-duplex only and half-duplex only and multidrop-half-duplex-only can all be separate things; however, I think that gets way too far into a fragmented spec and will delay our work.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
Sent from my Android device with K-9 Mail. Please excuse my brevity.