Wireless + TSN = Part of the Picture November 2013 doc.: IEEE 802.11-13/xxxxr1 July 2019 Wireless + TSN = Part of the Picture Date: 2019-07-15 Authors: Norman Finn Philip Levis, Stanford University

Introduction We’ve seen the introduction to TSN and DetNet. July 2019 Introduction We’ve seen the introduction to TSN and DetNet. The applications require end-to-end QoS guarantees over a wired/wireless/bridged/routed/label switched network. The TSN/DetNet model must expand if it is to include 802.11 media. The 802.11 model must expand if it is to cooperate with wired TSN/DetNet media. Norman Finn

What does a real-time application require of its network? July 2019 What does a real-time application require of its network? A latency limit – packets delivered late are equivalent to lost packets. A low rate of lost packets. Clearly, any best-effort network can time-stamp every packet, and throw away the late ones. So, we will define a real-time application’s requirement as: Minimize the packet loss rate, given an absolute upper bound on end-to-end latency. And, don’t forget: Congestion management (slow down on feedback) is not an option. Norman Finn

TSN/DetNet solution to packet loss problem July 2019 TSN/DetNet solution to packet loss problem Based on 802.3 bit-error rates and hardware failure rates, congestion is, by far, the biggest cause of packet loss in an 802.3 network that is not grossly overprovisioned. We know that congestion loss can be reduced to 0. Hence the attention paid by TSN/DetNet to achieving 0% congestion loss. TSN/DetNet also provides 1+1 path redundancy with hitless failover. Given 802.3 bit-error rates and equipment failure rates, this can effectively remove packet loss from the application’s total failure rate. TSN/DetNet have no significant loss rate / latency tradeoff. Norman Finn

Kinds of real-time applications July 2019 Kinds of real-time applications Loss rate is practically zero. Application designed to tolerate 1-2 packets lost, but to fail-safe on more losses. Application can tolerate greater packet loss, perhaps by trading latency against loss rate. Application cannot use the medium 10–14 10–10 PACKET LOSS RATE  10–6 TSN/DetNet target applications 10–3 100 Norman Finn

Black-and-white becomes gray July 2019 Black-and-white becomes gray Typically, 802.11 media have much higher loss rates than 802.3 media. But, we have just now defined the problem not as “guaranteed latency” and “guaranteed zero congestion” (black-and-white), but as, “a particular loss rate within a particular bounded latency” (a gray scale). Norman Finn

WIRED WIRELESS Does this mean? Loss rate is practically zero. July 2019 Does this mean? Loss rate is practically zero. Application designed to tolerate 1-2 packets lost, but to fail-safe on more losses. Application can tolerate greater packet loss, perhaps by trading latency against loss rate. Application cannot use the medium 10–14 WIRED 10–10 PACKET LOSS RATE  10–6 10–3 WIRELESS 100 Norman Finn

I hope not! I hope it means: July 2019 I hope not! I hope it means: Loss rate is practically zero. Application designed to tolerate 1-2 packets lost, but to fail-safe on more losses. Application can tolerate greater packet loss, perhaps by trading latency against loss rate. Application cannot use the medium 10–14 WIRED 10–10 PACKET LOSS RATE  10–6 10–3 WIRELESS 100 Norman Finn

A spectrum, not a binary choice July 2019 A spectrum, not a binary choice Where there is overlap in the network’s ability to meet requirements, we want the application designer to have a choice of media. We have avoided a competition between Real-time Bridging and Real-time Routing. Both TSN and DetNet standards offer the same features for real-time. Both TSN and DetNet standards describe how the TSN/DetNet service can be obtained in a mixed bridged/routed/label switched network. Let’s not create a competition between: Real-time Wired and Real-time Wireless. Norman Finn

Some possible areas of cooperation July 2019 Some possible areas of cooperation Many applications will need both wired and wireless components. Let us recognize that the problem is end-to-end. The service must be described in end-to-end terms, and offered that way. The application design should not have to know whether it is connected via wires or radios, any more than it has to know, today, whether its IP packets are carried by routers or by bridges. Send/Ack/Resend is a direct latency/loss tradeoff that has not been useful to TSN/DetNet, but is useful for Wireless. This makes it useful to the end-to-end network, so it needs to be a part of end-to-end solution. Norman Finn

Some possible areas of cooperation July 2019 Some possible areas of cooperation In a sufficiently constrained radio environment, 802.11 can offer bit error rates sufficiently low that the current TSN/DetNet techniques are adequate to satisfy real-time needs and provide coexistence with best-effort traffic. Every hop has to shape critical flows to prevent congestion in the next hop. So, the TSN techniques for zero congestion loss need to be a part of 802.11. A great deal of work has been done outside TSN/DetNet/802.11 for “better-than-best-effort” service that requires additional information be carried end-to-end. I am hesitant to rule out the relevancy of such techniques. Norman Finn

Summary TSN/DetNet achieves binary (100% and 0%) goals. July 2019 Summary TSN/DetNet achieves binary (100% and 0%) goals. TSN/DetNet needs to consider the 99% case, also. 802.11 needs to consider the value of the 100% and 0% TSN/DetNet model. We have to work together because: Each hop affects the next hop. The applications require end-to-end QoS. Norman Finn