| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Peter,
Thank you for your detailed response. My responses are inline. Unfortunately, I won’t be in Spokane but fortunately, my colleague will be there.
Kind regards, Mehmet
From: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx]
Mehmet,
“With the greatest respect”, I don’t agree. Responses inline.
See you in Spokane
Regards
----------------------------------------------------------- Peter Jones Cisco Systems Dist. Engineer 170 West Tasman Dr. Enterprise Networks San Jose, CA, 95134, USA. Wrk: +1 408 525 6952 Mob: +1 408 315 8024 Email: petejone at cisco.com Web: about.me/petergjones Webex: https://cisco.webex.com/join/petejone -----------------------------------------------------------
From: Mehmet Tazebay <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. [pj] Please: 1. Specify what you mean by “deadlock. Are you saying that no traffic is sent? <= Not “strictly deadlock”, but traffic may be delayed by the time where it becomes unusable, or acknowledgement is sent past the point when retransmission is possible or makes sense. 2. I believe that Piergiorgio has clearly shown that PLCA significantly improves the behavior of CSMA/CD in heavy traffic load conditions. If you do not agree, please present relevant data.<= There are traffic patterns where a burst of short packets will spread or delayed by a burst of long packets if a separate restriction is not placed. 3. For normal (non-TSN traffic, please show cases where PLCA (and/or CSMA/CD) cause “deadlock”, and what the result is.<= Don shows how accumulating short messages are pushed out by long messages. One of the methods of pushing priority messages and responses in CSMA/CD is to create a collision and then control the IPG delay in such a way that allows priority nodes use shorter backoff/IPG to gain access for high priority communication. That allows to reduce latency to ~20-40us on short messages. A similar method (SIFS/DIFS) is used in 802.11 to prioritize transmissions of acknowledgements. PLCA only allows round robin transmission allocation and may be confused by such intervention. A method that places low upper bound on priority short messages may be discussed. 4. For TSN traffic: a. AVB was not defined to run on 802.3 networks less than 100Mb/s or half-duplex. Has TSN changed that definition? <= IMHO, the full AVB may not be needed on the wired segment without bridges in between. But since there are Beacons (like “tokens” in 802.5), why not let them transmit timing information and also make timing in the nodes more accurate and have AVB clock ready for free? For example, it may allow to reduce the cost by eliminating crystals? b. Does TSN require support TSN service on an 802.3 link (or any other 802 MAC) with a mix of TSN and non TSN stations? If so, please point to references.<= In low cost nodes, having 802.1Qbv management may be economically overkill or impractical, so it is possible that a mix of nodes with and without traffic shapers may happen on a single multidrop branch in real life… c. If all stations on the segment are running TSN and using 802.1Qbv, please show cases where PLCA (and/or CSMA/CD) cause the “deadlock”. <= I doubt that a permanent deadlock will occur, but disturbance of real-time propagation of urgent short messages and their acknowledgements may happen. 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. [pj] I disagree with your conclusions here. I believe 10SPE addresses a useful set of applications. · Have you considered adding multidrop/PLCA to 100BASE-T1 to address the bandwidth issues you see? <= These issues are addressed in the switch QoS handling where all nodes are visible, and the links are point-to-point. The priority messages from multiple queues are sorted out at MAC layer. Besides, the maximum delay due to completion of uninterrupted long packet is 10 times shorter, in 100’s microsecond range.
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. [pj] I see what you are describing, but I would not describe this as a deadlock. 1. It feels very similar to 802.5 Token Ring with ETR (Early Token release – see link and link). <= Exactly. PLCA is a “poll” protocol, and in this sense similar to Token Ring. 2. The issue of priority packets being deferred when the segment is persistently 100% loaded can be addressed using techniques such as port shapers, or 802.1 Qbv time based schedulers. <= Unfortunately, it is a cooperative issue when long packets from “shaped” nodes align in 10ms train. It may be a low-probability corner case, but it may disturb control loops with acknowledgements.
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. [pj] I don’t understand the issue. 1. The segment delivers ~10Mb/s under load. <= In order to let a burst of short packets pass a train of long packets, the long packet shaper should (a) never allow max packets to be back-to-back, for example, by skipping every second transmit opportunity, and (b) nodes must be synchronized to disallow aligning of long packets. I don’t think it is practical. 2. What it doesn’t do is co-ordinate priority transmissions between all the station on the ring to ensure that all the high priority traffic in the segment is sent before the low priority traffic. <= Yes… 3. That is something Ethernet has not done before (if you disagree – please provide reference). <= Yes, but Ethernet provided CSMA/CD, and some vendors in the past were modifying IPG/backoff to resolve collision in favor of themselves to get better benchmarks. However, the PLCA now regulates the transmission to disallow such behavior.
[pj] I don’t agree that different types of traffic need to be separated on different physical wiring <= I concur here. But, we heard such idea.
[pj] Small MTUs always help insertion jitter, but I agree that they are not a good general solution. <= I concur.
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. [pj] I do not agree with your conclusion.<= The applications in multi-axis drive control in industrial and automotive cases would benefit from Ethernet as the control messaging protocol, but they cannot tolerate uncontrolled latencies with handshake of more than 2-3ms.
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. [pj] Thanks
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. [pj] Cisco is seeing significant deployments of Ethernet technologies in industrial control systems today (both star wired and rings, e.g. Cisco IE2000 with REP, IE2000 in manufacturing). What’s fundamentally different about the use case? <= These are relatively slow, macro level controls when the realtime is done within the controlled node. In other words, this is inter-equipment communication, not intra-equipment.
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. [pj] In the IEEE 802 world, this is not a MAC level problem. 802.1 defined a protocol for this in IEEE 802.2 LLC in IEEE 802.2 LLC Type 2. Type 2 is a connection-oriented operational mode. Sequence numbering ensures that the frames received are guaranteed to be in the order they have been sent, and no frames are lost. <= It is not an issue of ordering only. For instance, WiFi and LTE implements acks and automatic retransmission to guarantee that the packets are delivered. Control applications may want to know that the message indeed was delivered before it is too late. Other system may work without instant acknowledgement. It is MAC and above level, however, and the PHY may simply allow something like piggyback transmission for ACK. It is nice to reduce time of ACK below a full Ethernet frame.
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. [pj] It’s not clear to me what you think needs to be cross checked with 802.1/802. The signaling defined is within the scope of 802.3, and the other 802 MACs send significantly more information (e.g. 802.11, 802.17) <= Probably what is allowed and not allowed on the T1S network with the tools provided in 802.3cg group? 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. [pj] If it’s is a MAC function, it’s out of scope for 802.3cg. Do you intend to call a CFI/start a study group for this topic? <= It would be nice to see if there is enough critical mass to define what MAC can and cannot do on 802.3cg PHY. 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. [pj] 802.3 is defined as an unreliable datagram media, and provides no per-=packet guarantee of delivery. Please provide data showing that this noisy environment results in use not meeting our 10-10 BER objective. <= 10e-10 BER on 1.2e5 bit packet means 10e-5 PER. It is extreme, understood. In many non-real time systems it may be not an issue at all. But if a packet loss and its correction in 20-30ms could be counted as a failure and affect the FIT rate and safety. So it is better at least to allow a tool for high safety systems. 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. [pj] Data please. <= Working on it
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. [pj] Data please <= Working 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 |