idnits 2.17.1 draft-dang-ippm-congestion-03.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 date (August 13, 2020) is 1351 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 437, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dang, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational W. Wang 5 Expires: February 14, 2021 China Telecom 6 L. LEE 7 LG U+ 8 Y. Yan 9 Tencent 10 C. Cheng 11 Huawei 12 August 13, 2020 14 A One-Path Congestion Metric for IPPM 15 draft-dang-ippm-congestion-03 17 Abstract 19 This memo defines a metric for one path congestion across Internet 20 paths. The traditional mode evaluates network congestion based on 21 the bandwidth utilization of the link. However, there is a lack of 22 E2E path congestion that is truly service oriented. So A Path 23 Congestion Metric is required. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 14, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 62 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. A singleton definition of a Type-P-Path-Congestion Metric . . 4 64 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 4 66 2.3. Metric unit . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 5 69 2.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 7 70 3. A Definition for Samples of Path Congestion . . . . . . . . . 7 71 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 73 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 8 76 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 As we know, the current network has been already being in load 86 balancing mode, however it is partially congested. To solve the 87 problem of unbalanced network load[draft-liu-ican], Congestion of 88 paths requires an assessment metric. The traditional mode evaluates 89 network congestion based on the bandwidth utilization of the link. 90 However, there is a lack of E2E path congestion that is truly service 91 oriented. 93 So this memo defines a metric for a path congestion across Internet 94 paths. Currently there is no path congestion metric specified 95 according to [RFC2330] framework, so the notions and conventions of 96 Path Congestion will be introduced to extend RFC 2330. 98 o A 'singleton*' analytic metric, called Type-P-Path-Congestion, 99 will be introduced to measure a single observation of A Path 100 Congestion. 102 o Using this singleton metric, a 'sample*' called Type-P-One-Path- 103 Congestion-Poisson-Stream is introduced to measure a sequence of 104 singleton congestions sent at times taken from a Poisson process, 105 defined in Section 11.1.1 of [RFC2330]. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119. 113 1.2. Terminology & Abbreviations 115 o Path Group 117 * There are multiple channels between two nodes in the network. 118 These channels may be equal-cost multi-path (ECMP) mode or 119 unequal-cost multiple (UCMP) mode. In a real network, they 120 might be one [draft-ietf-spring-segment-routing-policy] or 121 [RFC7348] tunnel. 123 o Path 125 * One path of the path group 127 o Path Congestion 129 * A path is congested, indicating that the traffic of the path 130 exceeds its own throughput. The result of path congestion is 131 that the buffer of the nodes along the path cache traffic or 132 the buffer along the way is insufficient to cause packet loss. 134 1.3. Motivation 136 Import Traffic to the path1 137 \ 138 \ 139 NodeA----------NodeN1----------NodeN2----------NodeB 140 bandwidth utilization 30% 30% | 70% 141 of the links | 142 | 143 NodeN3 145 Figure 1: A Path 147 As Figure 1 is shown, there is a path between nodes A through B. 148 Some traffic is imported into this path. 150 o At node A, the traffic is imported to path1. 152 o The bandwidth utilization of the links passed by path1 (Such as 153 the link from Node A to NodeN1, the link from NodeN1 to NodeN2, 154 the link from NodeN2 to NodeB) need to be checked. The bottleneck 155 links identified where bandwidth utilization (70%) of the link 156 between node N2 and NodeB exceeds the threshold (65%). The node 157 where the bottleneck link is located is facing expansion and adapt 158 some flows to another path, in order to ensure the service 159 experiences. 161 The congestion of this bottleneck link may be suspected to be caused 162 by traffic coming from NodeN1, or coming from NodeN3. There is a 163 lack of a measure of a path congestion. So A Path Congestion Metric 164 is required to directly report the degree of path congestion, and is 165 accurate. 167 2. A singleton definition of a Type-P-Path-Congestion Metric 169 2.1. Metric Name 171 Type-P-Path-Congestion use the Type-P convention as described 172 in[RFC2330] . 174 2.2. Metric Parameters 176 o Src, the IP address of a host 178 o Dst, the IP address of a host 180 o dpt, transmission period of a measurement. For example, a 181 measurement is trigged once dpt (such as 3.3 milliseconds) 183 o dt, interval from when Src initiates the measurement message to 184 when Dst receives it. 186 o T, a time 188 o SrcCountp, the number of packets at source node in one dpt period. 189 When Src sent the first bit of a Type-P packet to Dst, This 190 parameter starts counting. And The counting is terminated after 191 the end of the cycle. This data can be collected locally at the 192 entry of the traffic import the path from Src to Dst. 194 o DstCountp, the number of packets at destination node in one dpt 195 period. When Dst receive the first bit of a Type-P packet to Dst 196 and the counting is terminated after the end of the cycle. 197 Because the statistics of the counting is based on the path ,the 198 related data can be collected locally based on the PathID what may 199 be SR label list[RFC8402] or VXLAN ID[RFC7348]. 201 2.3. Metric unit 203 The value of a Type-P-Path-Congestion is either a real number or an 204 undefined (informally, infinite) number. 206 2.4. Definition 208 For a real number c, 210 o the *Type-P-Path-Congestion* from Src to Dst at T is 0, which 211 means that Src sent the first bit of a Type-P packet to Dst at 212 wire time* T and that there is no path congestion to Dst. 214 o the *Type-P-One-way-Delay* from Src to Dst at T is greater than 0, 215 which means that Src sent the first bit of a Type-P packet to Dst 216 at wire time* T and there is the path congestion to Dst. 218 In theory, this metric is larger while the path congestion is more 219 serious. 221 2.5. Methodologies 223 As with other Type-P-* metrics, the detailed methodology will depend 224 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 225 Differentiated Services (DS) Field[RFC2780]. 227 The measurement methodology described in this section assumes the 228 measurement and determination of Type-P-Path-Congestion in real-time. 230 |---dpt---|---dpt---|---dpt---| 231 I1 232 Src ------------------------------- 233 \ | \ | 234 \ | \ | 235 \ | \ | 236 \| \| 237 Dst ------------------------------- 238 I2 I3 239 dpr = (I3 - I2) = (n*dpt + PathQueueDelay) 241 Figure 2: Measurement 243 As Figure 2 is shown, for a given Type-P, the methodology would 244 proceed as follows: 246 o Start after time I1. At the Src host, select Src and Dst IP 247 addresses, and form test packets of Type-P with these addresses 248 according to a given technique (e.g., the Poisson sampling 249 technique). The test packet can be used to dye traffic packets or 250 generate a packet[RFC7799][RFC8321]. 252 o At the Dst host, arrange to receive the packet. 254 o At the Src host, place a timestamp in the prepared Type-P packet, 255 and send it towards Dst. 257 o If the packet arrives within a reasonable period of time, take a 258 time stamp I2 as soon as possible upon the receipt of the packet. 259 By subtracting the two time stamps, an estimate of 5.3. Type-P- 260 One-way-Delay-Minimum[RFC7679] can be computed. 262 o If the packet meets the selection function criterion for the first 263 packet, record this first Type-P-One-way-Delay-Minimum value. 265 * Long-term measurement 267 + At the Src host, the packets continue to be generated 268 according to the given methodology. The Src host places a 269 time stamp in the Type-P packet, and send it towards Dst. 270 If the packet arrives within a reasonable period of time, 271 the Dst host take a time stamp I3 as soon as possible upon 272 the receipt of the packet. 274 * Short-term measurement 276 + After sending the first test message, the Src host sends a 277 measurement message once dpt. Generating the Type-P packet 278 stream is as above. 280 + At the Dst host, when receiving the first measurement 281 packet, it also sends a response packet to the Dst Host once 282 dpt. The purpose of this is to improve measurement 283 accuracy. Because when the packet is sent back the measured 284 packet may not reach the Dst Host. 286 o So 288 * In long term measurement, the congestion parameters are 289 calculated as follows: 291 + c = (( I3 - I2) / dpt ) -1 293 * In long-term measurement, the congestion parameters are 294 calculated as follows: 296 + c = (SrcCountp / DstCountp)-1 298 Therefore, the overall solution needs to consider two methods of 299 long-period measurement and short-period measurement. The two data 300 from the two method can also be verified against each other if 301 necessary. 303 If a packet loss is detected on the path within a certain period, the 304 congestion assessment will be terminated. The next measurement of 305 the path can only be restarted after initialization. 307 2.6. Reporting the Metric 309 The calibration and context in which the metric is measured MUST be 310 carefully considered and SHOULD always be reported along with metric 311 results. We now present four items to consider: the Type-P of test 312 packets, the threshold of infinite delay (if any), error calibration, 313 and the path traversed by the test packets. This list is not 314 exhaustive; any additional information that could be useful in 315 interpreting applications of the metrics should also be reported (see 316 [RFC6703] for extensive discussion of reporting considerations for 317 different audiences)[RFC6703]. 319 3. A Definition for Samples of Path Congestion 321 The goal of the sample definition is to make it possible to compute 322 the statistics of sequences of Path Congestion measurements. 324 3.1. Metric Name 326 Type-P-Path-Congestion-Poisson-stream 328 3.2. Metric Parameters 330 o Src, the IP address of a host 332 o Dst, the IP address of a host 334 o dpt[i], transmission period of a measurement. For example, a 335 measurement is trigged once dpt (such as 3.3 milliseconds). 337 o dt[i], interval from when Src initiates the measurement message to 338 when Dst receives it 340 o T0, a time 342 o Tf, a time 344 o lambda, a rate in reciprocal seconds 346 o SrcCountp[i], the number of packets at source node in one dpt 347 period. When Src sent the first bit of a Type-P packet to Dst, 348 This parameter starts counting. And The counting is terminated 349 after the end of the cycle. This data can be collected locally at 350 the entry of the traffic import the path from Src to Dst. 352 o DstCountp[i], the number of packets at destination node in one dpt 353 period. When Dst receive the first bit of a Type-P packet to Dst 354 and the counting is terminated after the end of the cycle. 355 Because the statistics of the counting is based on the path ,the 356 related data can be collected locally based on the PathID what may 357 be SR label list[RFC8402] or VXLAN ID[RFC7348]. 359 3.3. Metric Units 361 A sequence of four parameters whose elements are: 363 o T, a time, and 365 o c, either a zero (signifying no congestion transmission of the 366 packet) or greater than a zero (signifying congestion). 368 3.4. Definition 370 Given T0, Tf, and lambda, we compute a pseudorandom Poisson process 371 beginning at or before T0, with average arrival rate lambda, and 372 ending at or after Tf. Those time values greater than or equal to T0 373 and less than or equal to Tf are then selected. 375 At each of the selected times in this process, we obtain one value of 376 Type-P-One-Path-Congestion. The value of the sample is the sequence 377 made up of the resulting pair . If there are no such pair, 378 the sequence is of length zero and the sample is said to be empty. 380 3.5. Methodologies 382 The methodologies follow directly from: 384 o The selection of specific times using the specified Poisson 385 arrival process, and 387 o The methodologies discussion already given for the singleton Type- 388 P-One-Path-Congestion metric. 390 * Type-P-Path-Congestion[i] = ( ( SrcCountp[i]) / ( DstCountp[i]) 391 ) -1 393 If applied in a load-sharing network, Multi-Path Concurrent 394 Measurement for IPPM is 395 recommended[draft-dang-ippm-multiple-path-measurement]. 397 If a packet loss is detected on the path within a certain period, the 398 congestion assessment will be terminated. The next measurement of 399 the path can only be restarted after initialization. 401 3.6. Reporting the Metric 403 The calibration and context for the underlying singletons MUST be 404 reported along with the stream. 406 4. Security Considerations 408 The path congestion metric has the same security properties as 409 [RFC7679], and thus they inherit the security considerations of that 410 document[RFC2330]. 412 5. IANA Considerations 414 TBD 416 6. Acknowledgements 418 TBD 420 7. Normative References 422 [draft-dang-ippm-multiple-path-measurement] 423 "Multi-Path Concurrent Measurement for IPPM", 424 . 427 [draft-ietf-spring-segment-routing-policy] 428 "Segment Routing Policy Architecture", 429 . 432 [draft-liu-ican] 433 "Instant Congestion Assessment Network (iCAN) for Traffic 434 Engineering", 435 . 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC2330] "Framework for IP Performance Metrics", 443 . 445 [RFC2780] "RFC2780", . 447 [RFC6703] "Reporting IP Network Performance Metrics: Different 448 Points of View", 449 . 451 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)", 452 . 454 [RFC7679] "A One-Way Delay Metric for IP Performance Metrics 455 (IPPM)", . 457 [RFC7799] "Active and Passive Metrics and Methods (with Hybrid Types 458 In-Between)", . 460 [RFC8321] "Alternate-Marking Method for Passive and Hybrid 461 Performance Monitoring", 462 . 464 [RFC8402] "Segment Routing Architecture", 465 . 467 Authors' Addresses 469 Joanna Dang (editor) 470 Huawei 471 Beijing 472 China 474 Email: dangjuanna@huawei.com 475 Jianglong 476 China Telecom 477 Beijing 478 China 480 Email: wangjl50@chinatelecom.cn 482 Shinyoung 483 LG U+ 484 Seoul 485 Korea 487 Email: leesy@lguplus.co.kr 489 Hongbo 490 Tencent 491 Beijing 492 China 494 Email: nikyan@tencent.com 496 Liang 497 Huawei 498 Beijing 499 China 501 Email: liang.cheng@huawei.com