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