Re: [802.3_10SPE] Support for Don Pannell's proposal
Hi Peter,
I'd like to respond to one of your points that bugs me just a tiny bit (with greatest respect of course):
> 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?
> 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.
I assume we can agree that the CSMA technique used in today's 10Mb/s 802.3 PHY does not provide sufficient determinism for automotive/industrial applications. That is pretty much the reason why it wasn't supported by 802.1BA (AVB). I assume that is also one of the reasons why 802.3cg is using PLCA, which improves determinism quite a bit.
Is PLCA alone sufficient in order for 802.3cg to be commercially competitive in automotive/industrial as compared to other media?
I tend to say "no", but I acknowledge that reasonable people can certainly disagree on that question.
I also tend to think that Don Pannell's proposal brings us closer to a "yes", but again, reasonable people can disagree.
If such a proposal were integrated into 802.3cg, would 802.1 be willing to coordinate with 802.3 on integration into various TSN standards? Although I cannot speak for 802.1 of course, I think the answer is obviously yes. 802.1 is not trying to force anything on 802.3, or vice versa. We're all part of the same happy family, so when an opportunity arises for us to work together toward a common goal, we tend to do it.
Rodney
From: Peter Jones (petejone) <00000b5d1d72f221-dmarc-request@xxxxxxxx>
Sent: Monday, September 3, 2018 9:32 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Support for Don Pannell's proposal
Mehmet,
“With the greatest respect”, I don’t agree. Responses inline.
See you in Spokane
Regards
Peter
-----------------------------------------------------------
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://urldefense.proofpoint.com/v2/url?u=https-3A__cisco.webex.com_join_petejone&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=I5zq2u7LQfTkspWXv9D14EdNeYPe7DOGyU1IvLNLezY&e=
-----------------------------------------------------------
From: Mehmet Tazebay <mailto:000007de4eafb912-dmarc-request@xxxxxxxx>
Sent: Friday, August 31, 2018 2:29 PM
To: mailto: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.
[pj] Please:
1. Specify what you mean by “deadlock. Are you saying that no traffic is sent?
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.
3. For normal (non-TSN traffic, please show cases where PLCA (and/or CSMA/CD) cause “deadlock”, and what the result is.
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?
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.
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”.
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?
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 https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Token-5Fring&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=-wuiYKG9a5X2HzRIfElJXcFrNuOQGclO_zjCj_nCoU0&e= and https://urldefense.proofpoint.com/v2/url?u=https-3A__stason.org_TULARC_networking_lans-2Dtoken-2Dring_5-2D7-2DWhat-2Dis-2Dearly-2Dtoken-2Drelease-2DToken-2DRing-2DData-2DLink-2DLaye.html&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=s6hMazjTNqvN12iIIxs74lONrrTA4MuhLtiXd5AzJzw&e=).
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.
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.
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.
3. That is something Ethernet has not done before (if you disagree – please provide reference).
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.
[pj] I don’t agree that different types of traffic need to be separated on different physical wiring
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.
[pj] Small MTUs always help insertion jitter, but I agree that they are not a good general solution.
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.
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. https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_products_switches_industrial-2Dethernet-2D2000-2Dseries-2Dswitches_index.html&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=UbR30gpJ1KOM7FmFy5L4GYKThecz6wecXUkr8H1aVrY&e=, https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_en_us_solutions_industries_manufacturing_industrial-2Dnetworking.html-23-7Estickynav-3D1&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=ubNLofwzZ40rizY6LulwPhtuY5OAJfNOoO9pA73AY6k&e=). What’s fundamentally different about the use case?
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 https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_IEEE-5F802.2-23Operational-5Fmodes&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=GwcLDx7RVGRqsbYFwmnzOCw_HkJdV13TjSyWo0BikAI&e=.
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.
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)
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?
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.
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.
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
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://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2D10SPE-26A-3D1&d=DwMGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=USA6Ij7JCG3KncjhGNDlzWkym-3wcFVUS3YunpFmTko&e=
________________________________________
To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2D10SPE-26A-3D1&d=DwQGaQ&c=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k&m=reW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc&s=USA6Ij7JCG3KncjhGNDlzWkym-3wcFVUS3YunpFmTko&e=
________________________________________________________________________
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