| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 Gergely From: Mehmet Tazebay [mailto:000007de4eafb912-dmarc-request@xxxxxxxx]
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
http://www.ieee802.org/3/cg/public/Sept2017/Beruto_3cg_01a_0917.pdf) 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.
I am not familiar with such arguments being discussed. Would you point me to such presentations/emails please?
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
http://www.ieee802.org/3/cg/public/Sept2017/huszak_3cg_01a_0917.pdf), 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:
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
http://www.ieee802.org/3/cg/public/July2018/PLCA%20overview.pdf and
http://www.ieee802.org/3/cg/public/July2018/PLCA%20FAQ.pdf), so deviation is – per definition – should not apply here
Would this not be outside of the scope of cg?
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.
The emission of T1S has been studied quite a bit in the context of the preamble (one of your presentations is at
http://www.ieee802.org/3/cg/public/Jan2018/tazebay_3cg_01b_0118.pdf) 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
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:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1 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 |