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 <george@xxxxxxxxxxxxxxxxxxxx>
Sent: 09 February 2022 06:00
To: Lokesh Kabra <lokesh@xxxxxxxxxxxx>; 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 <Lokesh.Kabra@xxxxxxxxxxxx>
Sent: Tuesday, February 8, 2022 9:43 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>;
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 <george@xxxxxxxxxxxxxxxxxxxx>
Sent: 08 February 2022 22:57
To: 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:
stds-802-3-spep2p@xxxxxxxxxxxxxxxxx <stds-802-3-spep2p@xxxxxxxxxxxxxxxxx>
On Behalf Of Law, David
Sent: Tuesday, February 8, 2022 9:18 AM
To: IEEE P802.3de Task Force <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
00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx
Sent: 02 February 2022 12:31
To:
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