| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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. 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.  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.
 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.  The second is the need of instant, real-time acknowledgement that the critical message was indeed delivered to the destination. 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. 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. 2.     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. 3.     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. 4.     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. 5.     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.  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: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1 |