Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_ISAAC] Half duplex and full duplex



Kirsten –

We are a study group, and can explore the suitability, but I think a lot of work would need to be done, and it would take a lot of time and review.  This isn’t about seeing one presentation, it’s about iterating, reviewing, thinking, and cross-checking.  My experience in 802.3cg and 802.3de with half-duplex has taught me just how nuanced and uncommon knowledge of the details of the half-duplex mac is, and I would not want to go there quickly.

 

There are a bunch of reasons for saying ‘full duplex’ only – but the ultra short answer is that 802.3 half-duplex MAC operation is not defined at greater than 1 Gb/s.  Table 4-2 doesn’t have the parameters needed for the half-duplex MAC to run at more than 1 Gb/s.

We need to craft distinct identity, and being half-duplex would resolve that – however, it comes with a lot of complications.  I’ve lived them recently and don’t recommend that route.

 

We should probably say full-duplex only at the MAC/PLS service interface to make it clear we are talking about the MAC –  the phy duplexing mechanism on the medium.

 

Because we’d need to touch clause 4, unless we want a MAC project, and IMHO a long, complicated one at that, there needs to be a big advantage to using the half-duplex MAC.  The advantage we’re looking for is PHY based. If there is a substantial technical advantage that can’t be gotten another way, presentations need to support it. If the physical layer interfaces to the full-duplex 802.3 MAC we get the benefit without half-duplex.

While supporting the half-duplex MAC resolves the political problem of making distinct identity easy, it creates its own pain, and first among these is that touching the MAC appears to break the CSD of ‘compatibility’.  It also creates the possibility and discussion of a new 802 “dot” group.

 

You mention that there are gigabit PHYs that support half-duplex MACs.  Yes, that is where the pain was seen. At 1 Gb/s, 802.3 had to touch the MAC to continue to support half-duplex, and, as a result, agreed to abandon half-duplex above 1 Gb/s.  We’d be breaking additional new ground at greater than 1 Gb/s and probably have to make the scope include the MAC, which comes with more complexity and fewer good reviewers (I suspect even fewer than the RS).  Further, even if we did it,  beyond 100 Mb/s, half-duplex really hasn’t been used, so even the mods to make gigabit work don’t have much track record.  Modern Ethernet is, with the exception of PLCA, designed to be full-duplex at the MAC/PLS service interface

And part of the reason PLCA works is because it is at a low rate on a short medium.  This avoids the root cause of the complexity -  the relation of collision delay to the bit time (and the time duration of a minimum size frame).  Minimum frame size which is 72 octets or 576 bits.  The rough delay of our transmission medium is 4.8 to 6 ns/m. Let’s say 5.5 as a round number (which agrees with many cabling specs) – that means a 10m cable has a round trip delay of 110nsec.   1 Gb/s at 100m was 1100 bit times, hence the problem (addressed by extending carrier on minimum size frames at the cost of efficiency).  10 Gb/s at 10 m would be the same.  So it might get around this up to 5 Gb/s, or with kludges like 1 Gb/s, but as far as I know, 1Gb/s half-duplex IS NOT USED, and hence is untested in the world…

 

Not that we couldn’t craft something, but it would be new and require a lot of reviewing.  PLCA was hard to get right.  We can’t just use PLCA because PLCA relies on a medium that has a short delay relative to the bit time, just like half-duplex itself. (and, IMHO, the only reason we got PLCA through as not being a MAC change is because it is compatible with CSMA/CD operation with non-PLCA nodes on the mixing segment).  Note also that PLCA stuck with the RS, and played well with the existing parameters of the half-duplex MAC. Something we can’t do, because the speed changes.

 

And don’t forget that most of the modern TSN work was done for full-duplex (with, adaptations for PLCA, but we’d need more…

I could give a bunch more reasons (which I sent personally), but there be dragons here – we need a pretty strong reason to go the direction of supporting other than full duplex only at the MAC/PLS service  interface.

 

-george

 

 

From: Kirsten Matheus <Kirsten.Matheus@xxxxxx>
Sent: Friday, August 18, 2023 1:20 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Half duplex and full duplex

 

Dear all, 

 

On page 13 of the slide shown during the ISAAC meeting on Wednesday August 16, suggestions for general objectives are listed (see https://www.ieee802.org/3/ISAAC/public/081623/PAR_CSD_OBJ_081623_01.pdf). I concur with the first five objectives listed under “general and automotive objectives”, but I would like to discuss and understand better the rationale behind the suggestion to limit the technical solutions to “support full duplex operation only”.

 

Following thoughts occur:

  • We already have full duplex (PHY and MAC) MGbps Automotive Ethernet solutions.
  • For highly asymmetric use cases, half duplex (PHY and/or MAC) may reduce complexity and the reduction of complexity is one of the concerns and motivations for the projects.
  • Half duplex PHYs would have a distinct identity (as said, full duplex PHYs already exist).
  • There is the precedent of 10BASE-T1S, with a mandatory half-duplex P2P operation (see https://www.ieee802.org/3/cg/objectives_3cg_0318.pdf).
  • Even 1000BASE-X/T have half duplex modes (Clauses 22.2.4.4.2.and 22.2.4.4.4).
  • Why/when would we need full duplex for the envisioned use, i.e. to allow the MAC to send whenever? In the second part of the project we are explicitly looking for “2) a protocol for interfacing a PHY with asymmetric peak data rate capabilities to the existing 802.3 MAC with media independent interfaces at existing 802.3 rates”. Having an objective for full duplex operation (PHY or MAC) is an unnecessary burden.

In consequence, I propose to explore the suitability of a half-duplex PHY at this point in time and to not have the constraint of supporting full duplex MAC.

I am happy to propose to immediately adopt the first five objectives in the list and to remove “support full duplex operation only” (similar to what was done for the original objectives for 10BASE-T1S, see https://www.ieee802.org/3/10SPE/objectives_10SPE_111016.pdf).

 

Kind regards,

 

Kirsten

 

 

 


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