idnits 2.17.00 (12 Aug 2021) /tmp/idnits5592/draft-liu-detnet-dynamic-latency-guarantee-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2019) is 1041 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.finn-detnet-bounded-latency' is defined on line 266, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-detnet-architecture' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qav' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qbu' is defined on line 287, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1Qch' is defined on line 290, but no explicit reference was found in the text == Outdated reference: draft-ietf-detnet-architecture has been published as RFC 8655 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Deterministic Networking Working Group P. Liu 3 Internet-Draft L. Geng 4 Intended status: Informational China Mobile 5 Expires: January 9, 2020 July 08, 2019 7 Dynamic Latency Guarantee 8 draft-liu-detnet-dynamic-latency-guarantee-01 10 Abstract 12 Aiming at the deterministic demand for network latency in future 13 vertical industry applications, this document analyzes the existing 14 latency control methods for data transmission, points out the 15 possible shortcomings, and proposes some directions for optimizing 16 the latency control method. . 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 9, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Technologies of Latency Control . . . . . . . . . . . . . . . 2 60 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for 61 Time-Sensitive Streams . . . . . . . . . . . . . . . . . 3 62 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic . . . . 3 63 2.3. IEEE 802.1Qbu Frame Preemption . . . . . . . . . . . . . 3 64 3. Problems and Requirments . . . . . . . . . . . . . . . . . . 3 65 3.1. Problems in Bounded Latency . . . . . . . . . . . . . . . 4 66 3.2. Requirments of Deterministic latency . . . . . . . . . . 4 67 4. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 New types of services such as AR/VR, V2X, industrial motion control, 79 etc. have stringent requirements for latency and stability. In order 80 to meet those requirements, some network technologies such as time- 81 sensitive network, deterministic network, etc., have proposed 82 corresponding technical means to provide network bearers with 83 deterministic latency and packet loss rate to guarantee the service 84 experience. TSN includes a set of standards developed by the IEEE 85 802.1 Working Group's. Deterministic network (DETNET) is based on 86 the mechanism of TSN and committed to applying the method to the IP 87 layer to provide more reliable and stable network transmission. This 88 document will present some problems when applying TSN in DETNET, and 89 try to propose reference methods to solve the corresponding problems. 91 2. Technologies of Latency Control 93 Based on time synchronization, TSN has a range of bounded latency 94 technologies. 96 2.1. IEEE 802.1Qav Forwarding and Queuing Enhancements for Time- 97 Sensitive Streams 99 IEEE 802.1Qav inherited from the AVB, including priority mapping 100 algorithms and Credit-based Traffic Shaping algorithms. The priority 101 mapping algorithms is to mapping the priority to 'traffic class', 102 which represents whether the stream is time sensitive or not. 103 Credit-based Traffic Shaping algorithms provide the method to 104 allocate bandwidth of different streams. 106 2.2. IEEE 802.1Qbv Enhancements for Scheduled Traffic 108 In IEEE 802.1Qbv, the gate control list is created according to the 109 actual stream and timescale. It contains the transmission sequence 110 of all streams, and controls whether the data stream of each priority 111 is sent at the current time or not. All streams will be transmitted 112 strictly according to the current list. More Than This, IEEE 113 802.1Qbv also defines the guard band mechanism and spares part of the 114 time to guarantee the transmission of high priority data frames at 115 the beginning of the next time slice. 117 2.3. IEEE 802.1Qbu Frame Preemption 119 In the preemption mechanism, high-priority frames can interrupt the 120 transmission of low-priority data frames unless low-priority data 121 frames can no longer be fragmented. This standard fully guarantees 122 the transmission delay of the highest priority data frame, and also 123 reduces the guard band in IEEE 802.1Qbv to 127 bytes. The frame 124 preemption mechanism changes the transmission rules of the ethernet 125 frame and is used in conjunction with the IEEE 802.3Qbr . 127 In addition to these, there are also other standards to guarantee the 128 sequence of receiving data streams, which are fine-grained traffic 129 scheduling technology and the key technologies of TSN in bounded 130 latency. 132 3. Problems and Requirments 134 DETNET refers to the bounded latency mechanism of TSN, so it needs to 135 pay attention to some problems in the bounded latency mechanism. 136 There are several standards refers to bounded latency. Users can 137 decide whether to use a specific standard or not, which depends on 138 the requirments of network and business. Some TSN testbeds have been 139 established these years whose basic concept is realizing 802.1Qbv to 140 ensure the deterministic transmission of time sensitive stream. 141 Though it realized ignoring the interfere of background stream, the 142 testbed was too simple. In fact, networking is complicated. There 143 will be more than two kind of streams being transmitted. So it is 144 not that easily to apply those mechanisms on real networks. 146 3.1. Problems in Bounded Latency 148 Because of the complicated of real networks, there may be some 149 situations that the preemptable data frame transmission delay is too 150 large or cannot be transmitted. Thoes might occur when both 151 Enhancements for Scheduled Traffic and Frame Preemption are enabled. 153 Except for the highest priority, the others may be preempted by the 154 time slice to wait for transmission. In the actual scenario, the 155 preemptable data frame is not necessarily a completely non-time 156 sensitive frame, so it also need to guarantee the transmission of 157 some preemptable frame. However, Under the current mechanism, there 158 may be multiple preemption to cause a very large transmission delay 159 or no transmission of preemptable frame, depending on the size of the 160 express frame and the period of the timescale. In an actual 161 scenario, a data frame with a Secondary high priority may also be a 162 time-sensitive. If it cannot be transmitted or the transmission 163 delay is large, the service cannot be operated. 165 3.2. Requirments of Deterministic latency 167 Deterministic network includes deterministic latency and 168 deterministic packet loss. We need to think how to apply the bounded 169 latency mechanism effectively. Before using the bounded latency 170 mechanism, network manager needs to know enough about the network and 171 applications. For example, which kind of stream is time sensitive? 172 How about the frame's transceiver frequency of thoes stream? How 173 much bandwidth does it need? ... When you have a clear understanding 174 of the real-time state of the network, you can configure a delay- 175 limited algorithm for the network. 177 However, the transmission state of the network is not invariable. 178 Some transfer table might make corresponding adjustments according to 179 the current network situation. So the parameters that have been 180 configured before should also be changed. More than this, the 181 bounded latency mechanism also need a feedback system to receive 182 current network status and adjust/reconfigure the network. 184 4. Solutions 186 The implementation of the mechanism to guarantee latency requires 187 sophisticated calculation, including timescale and gate control tist 188 . When the stream in the network becomes diverse, it will consume a 189 lot of computing resources to schedule each stream. Therefore, a 190 single transmission rule may not be able to meet the problem of 191 multiple streams' transmission. Worst of all, the gate control list 192 is not properly calculated, the network may not transmit or failure. 194 Dynamic latency guarantee is a way of thinking based on the latency 195 guarantee of the whole network. that is, to dynamically adjust the 196 priority through the current network condition and the transmission 197 of data stream, and a feedback system is needed to optimize the 198 system. One of the reasons for this situation is that the prediction 199 or mastery of the transmission of frames in the network is not 200 accurate, so a feedback system is needed to tell the network to 201 centrally configure the system. So it could help to optimize the 202 gate control list to avoid the frequent occurring of this problems. 203 The most basic case is that once there are multiple preemption 204 occured, the switch need to report it to the Centralized 205 Configuration System. It represent that there might be some 206 unjustified configurations need to be reconfiguration. For example, 207 distribute more bandwidth to the corresponding traffic class. 209 It should be noted that all devices in the network share the same 210 gate control list. However, due to the difference in time of the 211 transmission path, it is necessary to keep all devices in the network 212 "asynchronous" to execute the gate control list. For example, when 213 the data frame is received by the device A, it is queued to be 214 transmited first in the currently divided time slice. When the frame 215 is received by the device B, the time t1 has elapsed. So the gate 216 control list of device B needs to perform the time difference of t1 217 with the A device, which can ensure that this frame arrives at every 218 device with a first-transmiting in current time slice. 220 -------------------------------------- 221 | Optimize Configuration | 222 V | 223 +-------------+------------+ | 224 | Centralized |------------------------ 225 | Configuration | 226 | System |------------------------ 227 +-------------+------------+ | 228 | Feedback Data| 229 | of Preemption| 230 ----------------------|------------------------ | 231 | | | | 232 V V V | 233 +---------+ +----------+ +---------+ | 234 | Switch A|-----------| Switch B |-------------| Switch C|-------- 235 +---------+ t1 +----------+ t2 +---------+ 236 Gate Control Gate Control Gate Control 237 List List List 239 Feedback System 241 5. Conclusion 243 This draft described the existing mechanism of bounded latency and 244 point out some problems when using them. It also proposed some 245 reference methods to solve them. In the process of network 246 evolution, there might also be more problems need to be noticed and 247 disscuss. For example, it also needs to consider whether the bounded 248 latency mechanism of layer 2 can guarantee the deterministic 249 processing of whole stack. There may be that deterministic 250 forwarding mechanism is used in Layer 2, but due to the TCP/IP or 251 other protocol in higher layer, data packets can not be processed in 252 deterministic order in the queue, which leads to the uncertainty of 253 latency. 255 6. Security Considerations 257 TBD. 259 7. IANA Considerations 261 TBD. 263 8. References 264 8.1. Normative References 266 [I-D.finn-detnet-bounded-latency] 267 Finn, N., Boudec, J., Mohammadpour, E., Zhang, J., Varga, 268 B., and J. Farkas, "DetNet Bounded Latency", draft-finn- 269 detnet-bounded-latency-04 (work in progress), June 2019. 271 [I-D.ietf-detnet-architecture] 272 Finn, N., Thubert, P., Varga, B., and J. Farkas, 273 "Deterministic Networking Architecture", draft-ietf- 274 detnet-architecture-13 (work in progress), May 2019. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, 278 DOI 10.17487/RFC2119, March 1997, 279 . 281 8.2. Informative References 283 [IEEE802.1Qav] 284 IEEE, "Forwarding and Queuing Enhancements for Time- 285 Sensitive Streams (IEEE 802.1Qav)", 2009. 287 [IEEE802.1Qbu] 288 IEEE, "Frame Preemption", 2015. 290 [IEEE802.1Qch] 291 IEEE, "Cyclic Queuing and Forwarding", 2015. 293 [IIEEE802.1Qbv] 294 IEEE, "Enhancements for Scheduled Traffic", 2016. 296 Authors' Addresses 298 Peng Liu 299 China Mobile 300 Beijing 100053 301 China 303 Email: liupengyjy@chinamobile.com 305 Liang Geng 306 China Mobile 307 Beijing 100053 308 China 310 Email: gengliang@chinamobile.com