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

Re: [802.3_10SPE] Support for Don Pannell's proposal

Hello Mehmet,


I hope this email finds you well and that you permit me to comment on your detailed email. Note please that I am writing these as an individual (affiliated with Kone) after some discussion with some of the groups experts.


I would also like acknowledge that Don’s presentation was suppletory and his work on this and related topics drew attention already in Geneva in the beginning of the year, my understanding however is that not having TSN was an intentional choice of the project, as the use cases behind cg were satisfied by the calculable performance of PLCA without TSN, while the low complexity of a T1S PHY and the speedy, but non preclusive (with respect to future extendibility) progress of the project were some of the strongest driving factors (happy to share more on this if desired).


When it comes to your statements with regards to PLCA beyond what Don is trying to propose, in several cases I found it difficult to concur (more detailed comments below in brown), therefore allow me please to kindly ask you to present on each of the points you find relevant as soon as possible. My understanding is that there could be a way to “feed the goat while preserving the cabbage” and tailor PLCA in a way that:

- either higher layer protocols could be implemented on top of T1S multidrop (e.g. data-rate fairness instead of packet fairness)

- or future extension of PLCA would be possible in a backward compatible manner (e.g. desired level of TSN)


The T1S multidrop PHY must navigate between the typical tradeoffs (complexity, baud rate, number of stations, MTU, resilience etc.) and to me it seems we are converging to a notable local maximum in a timely manner, navigating away from which – in any degree of freedom – would reduce the economic desirability.


Yours sincerely





From: Mehmet Tazebay [mailto:000007de4eafb912-dmarc-request@xxxxxxxx]
Sent: Friday, August 31, 2018 11:29 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] Support for Don Pannell's proposal


Dear IEEE 802.3cg team members,


Hereby we would like to support the initiative suggested by Don Pannell to modify the behavior of PLCA.


We agree that there several cases where PLCA as defined now will create deadlocks in the traffic when the payloads are approaching the full bandwidth utilization of 10BASE-T1S shared segments.

Could you please elaborate on what exact situation do you mean?

In my understanding deadlock is a situation where (due to circular resource needs) system (or part of it) is brought to a halt in a manner that never self-resolves, independently from whether stimuli is maintained or not after the onset. In this sense, I believe PLCA never ends up in a deadlock (= if the demand for bandwidth goes below availability queues start to get drained and the segment settles).

In case you meant the situation when any number of nodes (even one) are (is) trying to force more than 10Mbits per second through the segment for a maintained period causes messages to get increasingly delayed, then I would say that is nothing specific to PLCA, neither can it be resolved by any degree of TSN (some packets will suffer).

If these considerations are ignored, the 10BASE-T1S network will not able to reach the advertised bandwidth and will not be a successful contender for connectivity applications where the high data rate, near-isochronous traffic and low latency in response to randomly appearing events are needed. But these applications are in fact driving the development of a low-cost yet versatile network technology in IEEE 802.3cg 10BASE-T1S group.


The Don’s contribution attempts to resolve the situation where long and short packets coexist on the network, and especially when the short packets to long packet creation ratio exceeds 1. The current PLCA limits the transmit opportunity to only 1 packet per node per PLCA beacon period. If, during beacon interval, a node transmits max Ethernet packet (1500 bytes), which is ~1.25ms, and during this time other nodes collect several short packets (64 bytes, 56us), the PLCA will not allow such traffic to be delivered at the pace of packet production which is a deadlock.

Thus, in the presence of nodes allowed to create large packets at the rate close to the available bandwidth, the behavior of the control system relying on short messages will be disrupted.  Besides, the latency of delivery of short messages becomes totally uncontrolled, and this may cause disruption and instability of operation of control systems with feedback.

As stated above: so is any network that is being fed data at a rate beyond its capacity (per class or overall).


While there may be the argument that the network may be engineered as “over-provisioned”, i.e., under normal load delivering ~1-3Mbit/s only while the PHY data rate is 10x greater, the appeal of the new standard that wastes a lot of bandwidth for avoiding described situation is questionable.

To my understanding the opposite can be said about PLCA: namely that it saturates very well

More precisely simulations (see and – since San Diego – also an FPGA implementation of a mixing segment showed that PLCA can operate stably near its capacity with mixed traffic. I believe neither TDMA, nor regular CSMA/CD perform this versatile.

Moreover, such a PHY can provide appropriate – direct and indirect – indications to the higher layers to detect and adapt to excessive bandwidth demand.

There is an argument that different types of traffic may be separated on different physical wiring, but this defeats the purpose of Ethernet as a universal transport reducing the wiring.

I am not familiar with such arguments being discussed. Would you point me to such presentations/emails please?

The other argument may call for restriction of the packet size allowed on such network to smallest possible (64 byte) MTU, but this results in substantial waste of available bandwidth and breaks the Ethernet paradigm of flexible, on-demand packet payload size. If the packets from 10BASE-T1S segment are bridged to other, higher speed network segments, the small MTU size may result in the waste in these segments too.

Setting limits on MTU is an option: one can decide not to do it, if indeed a mixing segment is expected to serve relay purposes. If needed, a switch with a T1S port in multidrop mode can chose not to limit MTU (and do the appropriate scheduling/buffering instead).


Don’s proposal addresses this problem by introducing priority-based differentiation of beacon cycles, which allows the higher priority traffic to get access to the media before the lower priority traffic blocks its delivery, and at the first glance resolves the deadlock. It forces the nodes to hold low priority transmissions to the time when all high priority message queues drain. There are some deficiencies in the proposal on implementation of such arbitration which are explained below, but certainly the attention to this deadlock situations must be emphasized if the team wants to develop a widely deployed, future proof technology.


Besides traffic deadlocks, we would like to attract attention to two other features which are musts in the control and especially closed loop applications, and which are implemented in today’s technologies like CAN or Fieldbus.


First, The delivery mechanism should have the means to enforce upper bound on delivery latency of an asynchronously created control message to the value below the loop filter time in the controller algorithm. The typical latency for mechanical systems is expected at 2-5ms, and for electromechanical systems in power control circuits of electric cars may be 1-2ms and below. The latency for active noise cancellation system when network carries audio samples should be below 0.2ms to be usable. The current PLCA mechanism in the worst case may exhibit the delays of 10ms even with implementation of Don’s proposal, and even more without priority control.

Here I can speak only for myself: the requirements you are setting are not even close to ours (see, and in fact, PLCA’s performance (with and without MTU limits) satisfy our targets.

Are you saying that you would (and could) guarantee a modified T1S multidrop PHY with 10 nodes at 10Mbps to meet 0.2 channel access maximum times without limiting MTU, while maintaining reasonable complexity?

Either way, if you would like to go against a new set of requirements, that idea would need a good presentation + 75% of the floor on-board.


The second is the need of instant, real-time acknowledgement that the critical message was indeed delivered to the destination.

I do not think Don’s work was about real-time acknowledgements. Which PHY would acknowledge in a mixing segment? Are we talking about 802.3 here?

The noisy automotive applications may exhibit the loss of messages due to impulse noise & RF ingress and unreliable message delivery may present a safety problem. The obvious method to fix it is the retransmission, but the receiver must deliver acknowledgement immediately after the message. While communication technologies like CAN have this instant acknowledgement capability, the 10BASE-T1S does not have any tool for it.

Discussing CAN too much should not be the target here, but now that you brought it up, let me please state that our automotive experts pointed out that in fact CAN is among the weaker solutions in this respect. If this point is found to be relevant and/or debated, I can bring more data on this myself as well.

And with current PLCA implementation, the acknowledgement message may be delayed by 10ms or even much more if the effects identified by Don are not addressed, thus making the network technology unusable for such applications.


While we are very supportive of Don’s initiative in general and value its enhancements, we also believe that there are few items requiring further work: 

  1. The current PCLA proposal and its enhancements are defining a parallel short messaging channel for MAC level communication. It is a deviation from the standard Ethernet and may require involvement and cross-check at IEEE 802.1 level.

I have the opposite understanding:

- PLCA adds new features to 802.3 using the previously accepted model of being an RS

- PLCA works through standard MII signaling and can interface any (even decades-old) MACs (see and, so deviation is – per definition – should not apply here

  1. We believe that Don’s proposal should be enhanced to allow more than one priority message from the node per transmit opportunity, based on something like priority aging. It is MAC layer function, however.

Would this not be outside of the scope of cg?

  1. The structure of advertisement beacons is not fully defined and checked against all intended use cases. Besides, there is no error protection on the data and advertisement beacons. Unreliable delivery to some or all nodes may be unacceptable in noisy environment as it will break the protocol.

Correct. More work is needed here. Don’s presentation was the trigger to get these efforts started, given there is sufficient interest in the group.

  1. The frequent periodic transmission of un-coded beacon pattern on idle network will make emission spectrum highly non-uniform. A method addressing the issues but not requiring frequent beacon transmission is desirable.

The emission of T1S has been studied quite a bit in the context of the preamble (one of your presentations is at and no warning of “highly non-uniform” PSD was mentioned, after the change of the preamble and the introduction of the multiplicative scrambler. Have you done work on this since then? If yes, please present

  1. Reliable reception of single byte data bursts back to back and originating from the nodes operating on independent timing and phase of the clock may be challenging in noisy environments which increases the chances of misbehavior of the proposed protocol. It may be improved if global clock synchronization on the 10BASE-T1S multi-drop segment is implemented.

Are you referring to implementation-details here, or amendment to the text? When this topic of appropriate correlators has been discussed in the past, no indication of extreme difficulty came up. If you have tangible info here, would you please present on it?


We think that the discussion of the highlighted issues may require a separate session in the IEEE 802.3cg schedule.


Best regards

Mehmet V. Tazebay, Ph.D.

To unsubscribe from the STDS-802-3-10SPE list, click the following link:

To unsubscribe from the STDS-802-3-10SPE list, click the following link: