idnits 2.17.1 draft-du-detnet-layer3-low-latency-02.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 (February 22, 2021) is 1156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Du 3 Internet-Draft P. Liu 4 Intended status: Informational China Mobile 5 Expires: August 26, 2021 February 22, 2021 7 Micro-burst Decreasing in Layer3 Network for Low-Latency Traffic 8 draft-du-detnet-layer3-low-latency-02 10 Abstract 12 This document introduces the problem of micro-bursts in layer3 13 network, and proposed a method to decrease the micro-bursts in layer3 14 network for low-latency traffic. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 26, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Gaps for Large-scale Layer 3 Deterministic Network . . . . . 3 58 3. Rethinking the Problem in IP Forwarding . . . . . . . . . . . 3 59 4. Method to Decrease Micro-bursts . . . . . . . . . . . . . . . 5 60 4.1. Working Flow of the Method . . . . . . . . . . . . . . . 5 61 4.2. Process of Edge Node . . . . . . . . . . . . . . . . . . 5 62 4.3. Process of Forwarding Node . . . . . . . . . . . . . . . 6 63 5. Analysis of the Proposed Method . . . . . . . . . . . . . . . 6 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The DetNet architecture in RFC 8655 [RFC8655] is supposed to work in 75 campus-wide networks and private WANs, including the large-scale ISP 76 network scenario, such as the 5G bearing network mentioned in RFC 77 8578 [RFC8578]. It is essential for the large-scale ISP network to 78 be able to provide the low-latency service. The low-latency 79 requirement exists in both L2 and L3 networks, and in both small and 80 large networks. 82 However, as talked in [I-D.qiang-detnet-large-scale-detnet], 83 deploying deterministic services in a large-scale network brings a 84 lot of new challenges. A novel method called LDN (Large-scale 85 Deterministic Network) is introduced in 86 [I-D.qiang-detnet-large-scale-detnet], which explores the 87 deterministic forwarding over a large-scale network. 89 This document also explores the deterministic service in the large- 90 scale layer 3 network, and proposed a method based on micro-burst 91 decreasing, which can benefit the forwarding of low-latency traffic 92 in a large-scale network. 94 2. Gaps for Large-scale Layer 3 Deterministic Network 96 According to RFC 8655 [RFC8655], DetNet operates at the IP layer and 97 delivers service over lower-layer technologies such as MPLS and IEEE 98 802.1 Time-Sensitive Networking (TSN). However, the TSN mechanisms 99 are designed for L2 network originally, and cannot be directly used 100 in the large-scale layer 3 network because of various reasons. Some 101 of them are described as below. 103 Some TSN mechanisms need synchronization of the network equipments, 104 which is easier in a small network, but hard in a large network. It 105 brings in some complex maintenance jobs across a large distance that 106 are not needed before. 108 Some TSN mechanisms need a per-flow state in the forwarding plane, 109 which is un-scalable. Aggregation methods need to be considered. 111 Some TSN mechanisms need a constant and forecastable traffic 112 characteristics, which is more complicated in a large network which 113 includes much more flows joining in or leaving randomly and the 114 traffic characteristics are more dynamic. 116 The main aspects of the problems are the simplicity and the 117 scalability. The former can ensure that the mechanism is easy to 118 deploy, and the second can ensure that the mechanism is able to bear 119 a large number of deterministic services. 121 3. Rethinking the Problem in IP Forwarding 123 As a comparison, the current IP forwarding mechanism is considered to 124 be a good example fulfilling the requirements of simplicity and 125 scalability. However, traditional IP network is based on statistical 126 multiplexing, and can only provide Best Effort service, short of SLA 127 guaranteed mechanisms. 129 When we rethink the problem in the current IP forwarding mechanism, 130 we can find that in the current IP network, a long delay in queuing, 131 or some packet losses due to burst are acceptable; however, it is 132 unacceptable in the deterministic forwarding. Therefore, they have 133 different design principles in a low layer. 135 The current forwarding mechanism in an IP router, which is based on 136 statistical multiplexing, cannot provide the deterministic service 137 because of various reasons. Even be given a high priority, a 138 deterministic packet can experience a long congestion delay or be 139 lost in a relatively light-loaded network, which is caused by micro- 140 burst in the network. 142 Micro-burst is a special case of network congestion, which typically 143 lasts a short period, at the granularity of millisecond. In a micro- 144 burst, a lot of data are received on the interface suddenly, and the 145 temporary bandwidth requirement would be tens of or hundreds of the 146 average bandwidth requirement, or even exceed the interface 147 bandwidth. 149 In most cases, the buffer on the equipment can handle the micro- 150 bursts. However, in some corner cases, micro-bursts bring in a long 151 delay (at the granularity of millisecond) or even packet loss. 153 The following paragraphs introduce the causes of the micro-burst. 155 Firstly, IP traffic has a instinct of burstiness no matter in the 156 macro or micro aspect, i.e., it does not have a constant traffic 157 model even after aggregations. 159 Secondly, IP network has a flexible topology, where the incoming 160 traffic may exceed the bandwidth of the outgoing interface. For 161 example, an interface with a large bandwidth may need to send traffic 162 to an interface with a smaller bandwidth, and multiple flows from 163 several incoming interfaces may need to occupy the same outgoing 164 interface. 166 Thirdly, the IP node has been designed to send traffic as quickly as 167 possible, and it is not aware whether the downstream node's buffer 168 can handle the traffic. For example, Figure 1 below shows the 169 problem of the current IP scheduling mechanism. Before the 170 scheduling in an IP network, the packets are well paced, but after 171 the scheduling, the packets will be gathered even the total traffic 172 rate is unchanged. When an IP outgoing interface receives multiple 173 critical flows from several incoming interfaces, the situation 174 becomes worse. However, an IP router will try to send them as soon 175 as possible, so occasionally, in some later hops, micro-bursts will 176 emerge. 178 _ _ _ _ _ _ _ _ _ _ _ 179 | | | | | | | | | | | | | | | | | | | | | | 180 --------------------------------------------------------------------- 181 Before scheduling in an IP network 183 _ _ _ _ _ _ _ _ _ _ _ 184 | || || || || || | | || || || || | 185 --------------------------------------------------------------------- 186 After scheduling in an IP network 188 Figure 1: Change of the traffic characteristics in an IP network 190 This document proposes a method to support the low latency traffic 191 bearing in an IP network, such as the 5G bearing network, by avoiding 192 micro-bursts in the network as much as possible. The principle in 193 this method is to forward critical and BE traffic separately, and do 194 not distinguish different critical flows in the intermediate nodes on 195 the forwarding plane. 197 4. Method to Decrease Micro-bursts 199 The method needs the cooperation of the edge nodes and the 200 forwarding/core nodes in an IP network. 202 4.1. Working Flow of the Method 204 Generally, the method contains two steps: 206 Step1: per flow schedule in the edge node. The purpose is to make 207 sure that each critical traffic has a constant traffic model. 209 Step2: per interface schedule in the core node. Traffic are 210 aggregated to ensure the scalability, and the pacing also makes sure 211 that they do not gather. The purpose is to make the critical traffic 212 be forwarded as the shape when outgoing the edge, not as quickly as 213 possible. We assume that the sending rate of the buffer for the 214 critical traffic is the same as the receiving rate (maybe an 215 algorithm is needed here). If all work good, the buffer will be 216 maintained with a proper depth. 218 Other requirements include an RSVP liked mechanism with a good 219 scalability, which should be used to make sure the bandwidth is not 220 exceeded on the interface. 222 4.2. Process of Edge Node 224 The edge node of the IP network can recognize each critical flows 225 just as in the TSN network, and then give them individually a good 226 shaping. In fact, in TSN mechanisms, no micro-busrt will emerge for 227 critical traffic, and each TSN mechanism is proved to be effective 228 under certain conditions. 230 This document suggests the edge node to shape the critical traffic by 231 using the CBS method in IEEE 802.1Qav, or the shaping methods in IEEE 232 802.1Qcr. Generally, the shaping methods can generate a paced 233 traffic for each critical flow. 235 The parameters of the shaper, such as the sending rate, can be 236 configured for each flow by some means. 238 4.3. Process of Forwarding Node 240 For the forwarding node, it is uneasy to recognize each critical flow 241 because of the high pressure of forwarding a large amount of packets. 242 It is suggested that no per-flow state is maintained in the 243 forwarding node. It is to say that, in the forwarding node, the 244 critical flows should be aggregated and handled together. 246 This document suggests that the forwarding node can deploy a specific 247 queue at each outgoing interface. The queue will buffer all critical 248 traffic that need to go out through that interface, and will pace 249 them by using methods mentioned in the last section. 251 The shaping method in TSN is used here instead of the original 252 forwarding method in an IP router, which can make the critical 253 traffic be forwarded orderly instead of as soon as possible. 254 Therefore, micro-bursts can be decreased in the network. 256 If all the forwarding nodes can do their jobs properly, i.e., they 257 can well pace the critical traffic, no or rare micro-bursts for the 258 critical traffic would take place. In this way, the critical traffic 259 will have a relatively low latency in the IP network with less 260 uncertainties of micro-bursts. 262 As no per-flow state is maintained in the forwarding node, the 263 sending rate of the shaper is hard to decide. In this document, the 264 sending rate is suggested to be generated referring to the incoming 265 rate of the queue. The purpose is to maintain a proper buffer depth 266 for the queue. 268 5. Analysis of the Proposed Method 270 The method proposed does not need synchronization, just as the 271 asynchronous mechanisms studied in IEEE 802.1 Qcr. Furthermore, the 272 method has a larger aggregation granularity, which can fulfill the 273 requirements of simplicity and scalability. However, it has a larger 274 uncertainty in the forwarding than the TSN mechanisms, which needs to 275 be further studied. 277 6. IANA Considerations 279 TBD. 281 7. Security Considerations 283 TBD. 285 8. Acknowledgements 287 TBD. 289 9. References 291 9.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 299 RFC 8578, DOI 10.17487/RFC8578, May 2019, 300 . 302 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 303 "Deterministic Networking Architecture", RFC 8655, 304 DOI 10.17487/RFC8655, October 2019, 305 . 307 9.2. Informative References 309 [I-D.qiang-detnet-large-scale-detnet] 310 Qiang, L., Geng, X., Liu, B., Eckert, T., Geng, L., and G. 311 Li, "Large-Scale Deterministic IP Network", draft-qiang- 312 detnet-large-scale-detnet-05 (work in progress), September 313 2019. 315 Authors' Addresses 317 Zongpeng Du 318 China Mobile 319 No.32 XuanWuMen West Street 320 Beijing 100053 321 China 323 Email: duzongpeng@foxmail.com 325 Peng Liu 326 China Mobile 327 No.32 XuanWuMen West Street 328 Beijing 100053 329 China 331 Email: liupengyjy@chinamobile.com