Remove MAC Merge MAC type as an allowable connection for half duplex or, better yet, remove half duplex altogether.

Half duplex is an obsolete technology in a world of switches and point-to-point links.  Since switches can transmit and receive at the same time and the pont to point link can support simultaneous packets in each direction there is no need for a half duplex mode.  This was demonstrated in the development of 1000BASE-T (802.3ab) which included half duplex. The market provided no half duplex only DTEs or network infrastructure equipment that required it.

The fundamental justification for the MAC Merge project was to serve a high priority frame which was sufficiently urgent that it needed to start transmission on the media in less than [packet time max - (packet time min + IPG] approx 11,500* bit times on the media.

The allowance of a half duplex link below merging MACs destroys the prospect of meeting this requirement.  IF you wish to transmit a high priority packet AND you have a carrier detect indication AND that carrier detect is the result of far end transmit THEN the fact that you have an adjacent interruptible MAC does you no good.  You have to wait for the incoming frame to be fully received (plus IPG) before you can start to transmit your urgent packet.  BUT WAIT, THERE'S MORE: You only have a 50/50 chance of getting the link for your urgent transmission because the far end may have a follow-on packet to the one you just received and you have to contend with that one for the right to transmit.  If your contention produces a collision then you have to add the collision resolution time to the waiting time for your urgent packet to get started but that's only true if your end is the winner in the back off.  But actually, it's worse than that.  The far end has an advantage because of the capture effect, a well-known fault in the original CSMA/CD algorithm.  We had a project once upon a time to fix that (P802.3w BLAM) but we cancelled it (i.e. it failed to have sufficient support to send it to Sponsor Ballot) because no one in the industry was interested in the effort it would take to design and qualify a new half duplex MAC because half duplex was on the way out in the market.

The above is a macro view of the situation.  When you get into the actual mechanism, it can get worse. If the only indication that the eMAC has about link activity is Carrier_Sense from the link receiver then you have no way to differentiate between xmit from the pMAC and receive from the far end.  If you follow this path you have no way to logically tell the difference between whether you are about to preempt the pMAC (legal) or the far end transmission (illegal, causes a late collision if exerted when legal at the near end, i.e. after the collision window closes).  Since the eMAC circuitry is adjacent to the pMAC circuitry some chewing gum and bailing wire could be added to separate the two conditions.  Personally, I believe that this extra circuitry would need to be in the MAC Merge sublayer to avoid a layer violation.

I have not included operating in a late collision scenario as those are considered to be error conditions in 802.3 CSMA/CD. Normal operation with late collisions should be considered as out of scope for the project.

*I believe this is larger than the actual number in the spec.  The difference is of no consequence in the discussion.

There are other inexpensive solutions to solve MAC Merge performance requirements problem: (a) use a full duplex link (no changes needed to MAC Merge), (b) use 2 pair cable and run the pMAC and the eMAC on separate circuits (better performance, lower equipment cost, easier trouble shooting).

REQUESTED CHANGE: Remove half duplex from the objectives. Remove all vestiges of half duplex from the draft spec.


________________________________________________________________________
To unsubscribe from the STDS-802-3-BALLOT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-BALLOT&A=1