Re: [802.3_SPEP2P] [802.3de] Half-duplex issues in MACMerge

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

Hi David,

Thanks for the detailed explanation. Yes, after the “fair chances” provided during initial collision, for the subsequent collisions/transfers, the bandwidth allocation becomes a bit “un-fair” due to the capture effect. My thinking is that the other node still gets some chance (if not fair chance) to get the line if we allow collisions. But if we don’t allow collisions and do carrier-extension bust, the other side gets “zero” chance and its transfers gets delayed by the time taken by the burst. On the other hand multiple collisions make the bandwidth utilization a bit inefficient.

It is a difficult choice ☹

Lokesh

From: Law, David <dlaw@xxxxxxx>
Sent: 14 February 2022 16:06
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPEP2P] [802.3de] Half-duplex issues in MACMerge

Hi Lokesh,

I want to address the issue of 'fair share' mentioned in the email below, in the context of Ethernet CSMA/CD. The Ethernet CSMA/CD backoff mechanism has a feature called the 'capture effect', which results in temporary unfairness. When two or more stations attempt to transmit a packet at the same time causing a collision, the station that is able to transmit successfully immediately afterwards has an advantage should it have subsequent packets to transmit.

After a collision, a MAC will send jam and then backoff a number of slotTime (512 bits) before attempting to retransmit. The number of slotTimes is determined by the 'truncated binary exponential backoff' (see IEEE Std 802.3-2018 subclause 4.2.3.2.5). This selects a number of slotTimes randomly from the range 0 to maxBackOff where maxBackOff = 2^min(attempts, 10) and where 'attempts' counts the number of collisions that have occurred in attempting to send the packet. After a successful transmission by a MAC, the 'attempts' variable for that MAC is set back to zero. It, however, remains unchanged for the other MACs.

I've provided a trace of the capture effect below. In this example, node 0 has 6,000 bytes to send which has been queued up as 4 preemptable 1500-byte frames, node 1 has a single 128-byte express frame to send. As both the node 0 pMAC and the node 1 eMAC attempt to transmit at the same time, they collide.

As this is the 1st collision for both MACs, their attempts variables are set to 1 and their maxBackOff vales are set to 2 (2^min(1, 10)). They therefore randomly choose to delay retransmission either 0 or 1 slotTimes (0 to 2^1). They both randomly choose the same value and collide again. As a result, their attempts variables are set to 2 and their maxBackOff vales are set to 4 (2^min(2, 10)). They therefore randomly choose to delay retransmission 0, 1, 2 or 3 slotTimes (0 to 2^2).

At this point the pMAC chooses a lower value than the eMAC and is able to transmit successfully. This results in the 'attempts' variable in the pMAC being set back to zero. As the eMAC wasn't able to transmit, the 'attempts' variable in the eMAC remains at 2. At the end of the pMAC transmission, after an IPG, the pMAC will try to transmit its next frame and the eMAC will try again to transmit its frame. This results in another collision.

This collision will set the 'attempts' variable to 1 in the pMAC, but to 3 in the eMAC. The pMAC will therefore randomly choose to delay retransmission either 0 or 1 slotTimes, but the eMAC will randomly choose to delay retransmission either 0, 1, 2, 3, 4, 5, 6, 7 or 8 slotTimes (0 <= r < 2^3). This puts the eMAC at a significant disadvantage.

Of the 16 combinations of values the pMAC and eMAC can then choose, there is only one (6.25% chance) that will result in the eMAC being able to transmit (pMAC chooses 1, eMAC chooses 0), and only two (12.5% chance) that will result in a collision (pMAC chooses 0, eMAC chooses 0; pMAC choses 1, eMAC chooses 1). All other combinations (87.5% chance) result in the pMAC being able to transmit successfully again.

As a result, as happened in the trace below, it is highly likely that the pMAC will be able to transmit again successfully. This then results in the above repeating, with the probability of the eMAC being able to transmit successfully, or colliding, halving each time. In some cases, where one of the MACs have a long burst of frames to transmit, it can even result in the other MAC reaching the attemptLimit (16, see IEEE Std 802.3-2018 Table 4-2), and discarding a frame. This is the temporary unfairness I mentioned above and is an inherent feature of the truncated binary exponential backoff used by the IEEE 802.3 CSMA/CD half-duplex MAC.

My point with all the above is I think we need to be careful to understand the difference some of the proposed additions to 'improve fairness' will have in contrast to the overall fairness that can be achieved on a half-duplex link. In the trace below an express frame is delayed by 5 ms by a burst of 4 preemptable frames, that's a delay in the region of 100 slotTimes. On a full duplex link, I believe an express frame in this situation would be delayed approximately 1 slotTime.

I'm also not sure that I agree that MACs will be 'given a fair chance to arbitrate for the link based on collision' as suggested below. If, for example, the burst of '1 packet length (express) + 1 fragment' was transmitted after an initial collision between two MACs on a point-to-point link, I believe that based on the capture effect I describe above, the MAC that sent that '1 packet length (express) + 1 fragment' will be given an unfair advantage to arbitrate for the link based on a subsequent collision and will likely be able to transmit again even if the other MAC has a packet to send.

In summary, the capture effect gives a MAC that has successfully transmitted after a collision an unfair advantage to transmit again if there is a subsequent collision. I, therefore, believe that allowing a collision as described below will often have the opposite effect to that intended, increasing unfairness, and is unlikely to enable the MAC on the other side to transmit. In addition, I believe that enabling additional collisions risks taking the MAC on the other side nearer to the point where it reaches the attemptLimit and discards the frame it is attempting to transmit.

Best regards,

David

-----

From: Lokesh Kabra <00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx>

Sent: 09 February 2022 08:23

To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: Re: [802.3_SPEP2P] [802.3de] Half-duplex issues in MACMerge

Hi George,

Yes, for either option, the state diagram/variables will have significant changes. I was considering that the changes in state diagram is lesser, if collision is allowed before express frame by splitting the RESUME_WAIT state into 2 states as explained in slide 11 & 12. This will avoid adding any additional variables or state changes for burst limit, etc.

Another reason for my proposal the concept of fair share : When the burst on the link is extended due to express packets pre-empting multiple times, the delay/latency of the express packet waiting in queue on the other end gets extended consequently. This means that we are allowing a lower delay express packet transmission on 1 side at the cost of additional delay on express packet on the other side. Instead, both eMACs are given a fair chance to arbitrate for the link based on collision & at the same time limit the burst size to “1 packet length (express) + 1 fragment”.

Lokesh

From: George Zimmerman <mailto:george@xxxxxxxxxxxxxxxxxxxx>

Sent: 09 February 2022 06:00

To: Lokesh Kabra <mailto:lokesh@xxxxxxxxxxxx>; mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: RE: [802.3de] Half-duplex issues in MACMerge

Lokesh – thank you for exposing a further difference which would complicate a solution. To me, it looks like the natural place to implement a carrier extension would be to transmit the extension during the RESUME_WAIT state on Figure 99-5 (when in half-duplex), which is the state that you enter after E_TX_COMPLETE. However, it is also the state you first enter if a preemptable frame is preempted by eTx (from P_TX_COMPLETE on condition !pTxCplt). It appears to me that RESUME_WAIT is both where the IPG after an express frame is generated AND where the IPG before the express frame is generated. Therefore, any solution that would cause one case to extend carrier and the other case not to, requires more extensive surgery to the state diagram.

That said, I’m not sure that I agree that I would want the behavior you describe, which unveils a further complication. As we had envisioned, an express packet could only pre-empt a frame being transmitted from its side of the link – as such, it shouldn’t have to compete with an express frame from the link partner for access to the media, since the same station already has claimed the media via its emac. I do agree that some method of limiting the burst is necessary though, and that further complicates the changes to the state diagram.

From: Lokesh Kabra <mailto:Lokesh.Kabra@xxxxxxxxxxxx>

Sent: Tuesday, February 8, 2022 9:43 AM

To: George Zimmerman <mailto:george@xxxxxxxxxxxxxxxxxxxx>; mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: RE: [802.3de] Half-duplex issues in MACMerge

David,

Thanks for your feedback. Yes, I agree that a normal collision on eMAC will result in “late” collision on the pMAC due to the existing specification text “the PLS_SIGNAL.indication from the RS is forwarded to both the eMAC and the pMAC”. I realised this while preparing slide 10 and hence just added it there with a suggested fix and forgot to list it back into Slide 6. I will add it to slide 6 as you suggested.

George,

In my slides, I did not suggest to evoke carrier extension before an express frame transmission. Instead, I suggest having carrier extension only in the “IPG” between express packet and continuation fragment. This allows fair opportunities to eMACs on both sides to start transmission and converge using collision. Plus the additional benefit is that the burst due to carrier extension is limited to “1 express packet + continuation fragment”.

Lokesh

From: George Zimmerman <mailto:george@xxxxxxxxxxxxxxxxxxxx>

Sent: 08 February 2022 22:57

To: mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: Re: [802.3_SPEP2P] [802.3de] Half-duplex issues in MACMerge

David –

Reading the below, it seems to me that a collision that occurs near the start of an express packet would be interpreted as a late collision by the pMAC (as you say, more than 512 bits have passed), but is not necessarily a late collision for the eMAC, since it would be within the first 512 bit times of the eMAC. Further, I think that for 10BASE-T1S networks (which have no repeaters and short propagation delay) the modification to clause 99 to extend carrier for half duplex systems eliminates this collision possibility.

Or am I missing something?

-george

From: mailto:stds-802-3-spep2p@xxxxxxxxxxxxxxxxx <mailto:stds-802-3-spep2p@xxxxxxxxxxxxxxxxx> On Behalf Of Law, David

Sent: Tuesday, February 8, 2022 9:18 AM

To: IEEE P802.3de Task Force <mailto:stds-802-3-spep2p@xxxxxxxx>

Subject: RE: [802.3de] Half-duplex issues in MACMerge

Hi Lokesh,

Thank you very much for this excellent contribution.

I'd like to start with a minor comment on slide 6 'Collision Scenarios in MACMERGE 1' and slide 10 'Summary of Collision Issues'. Since, based on subclause 99.4.5 and 99.4.6 of the current IEEE P802.3de draft, the PLS_SIGNAL.indication from the RS is forwarded to both the eMAC and the pMAC, I believe that a late collision can occur either when the pMAC is transmitting a continuation fragment, or when the eMAC is transmitting an express packet that has pre-empted a pMAC packet.

I believe that any collision that occurs after the transmission of more than 512 bits by a MAC is classified as a late collision. See WatchForCollision procedure in subclause 4.2.8 where lateCollisionError is set true if (currentTransmitBit > (slotTime - headerSize). The headerSize is subtracted from slotTime as currentTransmitBit only starts counting after the header is sent, see BitTransmitter process 4.2.8.

I also believe that Figure 99-5 'Transmit Processing state diagram' will always ensure that the pMAC has transmitted a minimum of 512 bits before it can be pre-empted by the eMAC. The transition from the PREEMPTABLE_TX state to the TX_MCRC state is conditioned on preempt being true. The varible preempt is defined as true when pAllow * (eTx + hold) * preemptableFragSize * MIN_REMAIN, and preemptableFragSize is defined as true when fragSize >= (minFrag x (1 + addFragSize) – 4) where fragSize is a count of the number of octets of mData transmitted in the current preemptable mPacket, and where minFrag is 64 bytes.

As a result, should a pre-emptiable packet be preempted by an express packet, since the express packet will not be sent until after a minimum of 64-byte fragment of the pre-emptiable packet has been sent, a collision that occurs at any point within the express packet that will be forwarded to both the eMAC and pMAC will be considered a late collision by the pMAC. I've captured an example of this in the trace below from my Verilog model of the system you illustrate on slide 3 of your contribution.

The fix is already listed on slide 6 of your contribution, the PLS_SIGNAL.indication from the RS should only be forwarded to the transmitting MAC. So, as I said, a minor point, but for completeness I suggest that slide 6 and slide 10 list that a late collision can occur when the eMAC is transmitting an express packet that has pre-empted a pMAC packet, based on the current draft forwarding collision events to both MACs.

Best regards,

David

-----

From: Lokesh Kabra mailto:00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx

Sent: 02 February 2022 12:31

To: mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: [802.3_SPEP2P] FW: [802.3de] Half-duplex issues in MACMerge

Hello all,

As discussed in the meeting yesterday, we had offline discussions on the half-duplex issues and possible fixes to support it in MACMERGE.

The details of the problem scenarios/issues and possible solutions for the identified problem is captured in attached presentation.

I would like the larger group to review this and join the discussion in case we have missed out any more hidden issues or suggest better solutions for fixing the issues.

Once we have some consensus on the solution, exact changes to the next draft can be submitted in review of D2.1.

Thanks,

Lokesh

From: George Zimmerman <mailto:george@xxxxxxxxxxxxxxxxxxxx>

Sent: 01 February 2022 21:44

To: mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx

Subject: [802.3_SPEP2P] [802.3de] website update

The 802.3de website has been updated with our two presentations for today.

As of this moment, I don’t have a volunteer to be recording secretary. If you would like to volunteer, please let me know. However, in the lack of a volunteer, I will ask the group’s consent and am willing to also serve as recording secretary.

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

mailto:george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

________________________________________

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

________________________________________

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

________________________________________

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

________________________________________

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

________________________________________

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

________________________________________

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