Re: [802.3_10SPE] Support for Don Pannell's proposal
Don-
Can you please point to the IEEE 802.1 Standard or approved PAR that extends the scope of TSN to the areas you propose.
If you can not do that, then your proposal to do so is at this point just wishful thinking that has not yet been subjected to the IEEE process.
My personal opinion is that 10 Mb/s is the bottom of the barrel for wired networking performance and that (thanks to Moore's Law and product line maturity) it doesn't cost that much to make the step up to a more deterministic network that is more suitable for TSN. There is no free lunch. If you want a network that supports TSN then step up. If all you want to do is TSN on the cheap, there is always a UART.
Geoff
> On Sep 10, 2018, at 7:54 AMPDT, Don Pannell <donald.pannell@xxxxxxx> wrote:
>
> Christian,
> Thanks for the updates on the specific examples. I am not an 802.1CM (Fronthaul expert). This only helps make the point I was trying to make.
>
> Just because 802.1CM (Fronthaul Profile) disallows 100 Mbit links, it would be wrong to state that TSN disallows 100 Mbit links across the board. It doesn't. AVB clearly supports 100 Mbit links.
>
> Just because 802.1BA (AVB Profile) disallows 10 Mbit links, it is wrong to state that TSN disallows 10 Mbit links across the board. It doesn't. The Industrial Profile is looking in that direction. Automotive may too.
>
> Thanks,
> --Don
>
> -----Original Message-----
> From: Christian Boiger <christian.boiger@xxxxxxxxxx>
> Sent: Monday, September 10, 2018 7:42 AM
> To: Don Pannell <donald.pannell@xxxxxxx>; STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
> Subject: AW: [802.3_10SPE] Support for Don Pannell's proposal
>
> Don,
>
> while I totally agree with the point I think you are trying to make that the argument, IEEE Std 802.1BA requires 100Mbit/s full duplex links and therefore TSN is somehow not relevant for 10Mbit/s half duplex, is not valid and that TSN provides a toolbox of mechanisms, I disagree with your reasoning.
>
> Profiles are always very application specific and therefore include limitations regarding the relevant link speeds. AVB was developed for guaranteed low latency (< 2ms) streaming of high bandwidth data (>= 4000/8000 frames per second), hence 10Mbit/s was and I think still is not the right choice for this specific application space.
>
> It is not true that the TSN fronthaul profile (IEEE Std 802.1CM) is not limiting the link speed, it requires link speeds of >= 1Gbit/s and full duplex (i.e. even excludes 100Mbit/s), see 5.3.1 b). This again is a result of the specific application.
>
> While it is possibly way too early to talk about the requirements in the industrial TSN profile, a current draft of the requirements document (https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ieee802.org%2F1%2Ffiles%2Fpublic%2Fdocs2018%2F60802-industrial-requirements-0918-v06.pdf&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636721873353679747&sdata=FwguVp%2B01Q%2BzDns4lJ7%2FW0TAeccz%2FzlJ%2F2n18NaPmFc%3D&reserved=0) lists 10Mbit/s (including 10BASE-T1S and 10BASE-T1L) however, requires full duplex. As far as I understand this is derived from the defined use cases.
>
> Therefore, in my opinion, it all boils down to the question: Is the very limited QoS that PLCA can provide without supporting priorities sufficient for the desired application space? Unfortunately the automotive TSN project hasn’t started and therefore is not in a stage to give an answer to that question.
>
> Regards
> Christian
>
> -----Ursprüngliche Nachricht-----
> Von: Don Pannell <donald.pannell@xxxxxxx>
> Gesendet: Montag, 10. September 2018 11:11
> An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
> Betreff: Re: [802.3_10SPE] Support for Don Pannell's proposal
>
> All,
> I'd like to clarify what is in the AVB/TSN standards about 10 mbit & half-duplex.
>
> First, TSN is the name of the workgroup in 802.1 that creates Time Sensitive Networking standards, which are designed to work for many different use cases. These are like tools in a toolbox. Depending upon the application, some tools make sense and others not so much. Don't use a screwdriver with a nail.
>
> Second, the TSN group uses Profile standards to define what is needed to make a specific use case work. These Profiles define what TSN standards (& other 802.1 standards) are needed to support a specific use case and if there are any restrictions.
>
> The first TSN Profile created was the AVB Profile. This Profile defines a plug-and-play (non-engineered network) pro-audio/video, home audio/video, use case. In this Profile half-duplex on Ethernet is not allowed because the CSMA/CD MAC is non-deterministic. This same Profile allows half-duplex on other media, however! (Wi-Fi, MoCA for example). 10 Mbit was not allowed in this Profile due to the non-engineered, plug-and-play nature of the use case where this link speed was unlikely to be seen by the target audience. This was to help with the best user experience possible.
>
> AVB is the ONLY Profile to limit speed or duplex. The 2nd TSN Profile, Fronthaul, does not limit speed nor duplex, but defines an end-to-end delay requirement such that faster link speeds support more hops. But since this is an engineered network, it was up to the user to decide link speed, type & number of hops. Depending upon how many hops your application may need, even Gigabit links may not work. But they are still allowed (as well as 10 Mbit links) if they work in your application.
>
> The Industrial Profile is a work in process but since Industrial already uses Automotive CAN devices in their products, I suspect this Profile will not limit any link speeds either. The 10BASE-T1L is another example where 10 Mbits will likely not be limited by this Profile!
>
> The Automotive Profile is a new project just starting up and since 10SPE has Automotive interests, I don't see that Profile limiting speed or duplex either, as long as the links support TSN (the reason for my presentation).
>
> The last two Profiles are not completed projects so what will or will not be there is debatable. But the intention is clear, nobody wants to limit anything if we don't have to. What I wanted to do in this e-mail is clarify that TSN is a set of tools that need to be applied to specific use cases. To date, there is only one use case that prohibits 10 Mbit and half-duplex (and Flow Control too) so that the plug-and-play use case works. I doubt there will be others (unless we do another plug-and-play use case).
>
> --Don Pannell, NXP
>
>
> -----Original Message-----
> From: Rodney Cummings <rodney.cummings@xxxxxx>
> Sent: Friday, September 07, 2018 10:50 AM
> To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
> Subject: 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__cisco.webex.com_join_petejone%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DI5zq2u7LQfTkspWXv9D14EdNeYPe7DOGyU1IvLNLezY%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=JbuGPhufPxR%2BmnJkfT0iosC5WKHdiHZra2idcIz294A%3D&reserved=0=
> -----------------------------------------------------------
>
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__en.wikipedia.org_wiki_Token-5Fring%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3D-wuiYKG9a5X2HzRIfElJXcFrNuOQGclO_zjCj_nCoU0%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=MR1XMMR9myzTIRcUqqMOdeqLCaOZ%2FY2XMLlFOMhK3Xg%3D&reserved=0= and https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__stason.org_TULARC_networking_lans-2Dtoken-2Dring_5-2D7-2DWhat-2Dis-2Dearly-2Dtoken-2Drelease-2DToken-2DRing-2DData-2DLink-2DLaye.html%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelc
> SjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3Ds6hMazjTNqvN12iIIxs74lONrrTA4MuhLtiXd5AzJzw%26e&data=02%7C01%7Cdonald.pannell%40nxp.com%7C9d49606fbb5f4ba2925108d614ea5337%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636719394040784335&sdata=KU9E3eLQbkuSSBLeyH4eywqXHSkdZYU09GP1DMKe%2BxA%3D&reserved=0=).
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.cisco.com_c_en_us_products_switches_industrial-2Dethernet-2D2000-2Dseries-2Dswitches_index.html%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DUbR30gpJ1KOM7FmFy5L4GYKThecz6wecXUkr8H1aVrY%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=OXxk2W8X%2BaGNSgWhCFn0cRw6d1JjcTE9RAfA%2FWQjyXw%3D&reserved=0=, https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.cisco.com_c_en_us_solutions_industries_manufacturing_industrial-2D!
ne!
> two
> rking.html-23-7Estickynav-3D1%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DubNLofwzZ40rizY6LulwPhtuY5OAJfNOoO9pA73AY6k%26e&data=02%7C01%7Cdonald.pannell%40nxp.com%7C9d49606fbb5f4ba2925108d614ea5337%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636719394040784335&sdata=fokKuFahPiX5zDJF5z5jaRoFwWcr1do0ER9f8hp6jxs%3D&reserved=0=). 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__en.wikipedia.org_wiki_IEEE-5F802.2-23Operational-5Fmodes%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DGwcLDx7RVGRqsbYFwmnzOCw_HkJdV13TjSyWo0BikAI%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=NE7X706QIzAxpIQ9m7ySAhBGBgVQ3AYQ4ZGHzkgwfhA%3D&reserved=0=.
> 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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2D10SPE-26A-3D1%26d%3DDwMGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DUSA6Ij7JCG3KncjhGNDlzWkym-3wcFVUS3YunpFmTko%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=Qf6PIDOfqCyhS4NklUUPElwk%2BBNGjgBO3qEL0tZP9xc%3D&reserved=0=
> ________________________________________
> To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__listserv.ieee.org_cgi-2Dbin_wa-3FSUBED1-3DSTDS-2D802-2D3-2D10SPE-26A-3D1%26d%3DDwQGaQ%26c%3DI_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA%26r%3DWA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnboKbZ8k%26m%3DreW7usGzylY8hAp0naw7NvbN64Vh71pEOqNd09_iZSc%26s%3DUSA6Ij7JCG3KncjhGNDlzWkym-3wcFVUS3YunpFmTko%26e&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=yKg1abyTUQ1UI6eLHdedQsdSoNA0n6ukDdAb4HR6MQw%3D&reserved=0=
>
> ________________________________________________________________________
> To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ieee.org%2Fcgi-bin%2Fwa%3FSUBED1%3DSTDS-802-3-10SPE%26A%3D1&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=x%2FjgmhJht9S2wrnoCSIB0Yk5Q4Pdu%2FrmvcNIB9VF%2FlA%3D&reserved=0
>
> ________________________________________________________________________
> To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flistserv.ieee.org%2Fcgi-bin%2Fwa%3FSUBED1%3DSTDS-802-3-10SPE%26A%3D1&data=02%7C01%7Cdonald.pannell%40NXP.COM%7C2ea01fbdf14445ad959308d6172b991c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636721873353679747&sdata=x%2FjgmhJht9S2wrnoCSIB0Yk5Q4Pdu%2FrmvcNIB9VF%2FlA%3D&reserved=0
>
> ________________________________________________________________________
> 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