idnits 2.17.1 draft-dang-ippm-congestion-00.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 (March 4, 2019) is 1879 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 405, 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 March 4, 2019 5 Expires: September 5, 2019 7 A One-Path Congestion Metric for IPPM 8 draft-dang-ippm-congestion-00 10 Abstract 12 This memo defines a metric for one path congestion across Internet 13 paths. The traditional mode evaluates network congestion based on 14 the bandwidth utilization of the link. However, there is a lack of 15 E2E path congestion that is truly service oriented. So A Path 16 Congestion Metric is required. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 5, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 1.2. Terminology & Abbreviations . . . . . . . . . . . . . . . 3 55 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. A singleton definition of a Type-P-Path-Congestion Metric . . 4 57 2.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Metric unit . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 7 63 3. A Definition for Samples of Path Congestion . . . . . . . . . 7 64 3.1. Metric Name . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Definition . . . . . . . . . . . . . . . . . . . . . . . 8 68 3.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 8 69 3.6. Reporting the Metric . . . . . . . . . . . . . . . . . . 9 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 73 7. Normative References . . . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 This memo defines a metric for a path congestion across Internet 79 paths. 81 Currently there is no path congestion metric specified according to 82 [RFC2330] framework, so the notions and conventions of Path 83 Congestion will be introduced to extend RFC 2330. 85 o A 'singleton*' analytic metric, called Type-P-Path-Congestion, 86 will be introduced to measure a single observation of A Path 87 Congestion. 89 o Using this singleton metric, a 'sample*' called Type-P-One-Path- 90 Congestion-Poisson-Stream is introduced to measure a sequence of 91 singleton congestions sent at times taken from a Poisson process, 92 defined in Section 11.1.1 of [RFC2330]. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119. 100 1.2. Terminology & Abbreviations 102 o A Path Group 104 * There are multiple channels between two nodes in the network. 105 These channels may be equal-cost multi-path (ECMP) mode or 106 unequal-cost multiple (UCMP) mode. In a real network, they 107 might be one [draft-ietf-spring-segment-routing-policy] or 108 [RFC7348] tunnel. 110 o A Path 112 * One path of the path group 114 o A Path Congestion 116 * A path is congested, indicating that the traffic of the path 117 exceeds its own throughput. The result of path congestion is 118 that the buffer of the nodes along the path cache traffic or 119 the buffer along the way is insufficient to cause packet loss. 121 1.3. Motivation 123 Import Traffic to the path1 124 \ 125 \ 126 NodeA----------NodeN1----------NodeN2----------NodeB 127 bandwidth utilization 30% 30% | 70% 128 of the links | 129 | 130 NodeN3 132 Figure 1: A Path 134 As Figure 1 is shown, there is a path between nodes A through B. 135 Some traffic is imported into this path. 137 o At node A, the traffic is imported to path1. 139 o The bandwidth utilization of the links passed by path1 (Such as 140 the link from Node A to NodeN1, the link from NodeN1 to NodeN2, 141 the link from NodeN2 to NodeB) need to be checked. The bottleneck 142 links identified where bandwidth utilization (70%) of the link 143 between node N2 and NodeB exceeds the threshold (65%). The node 144 where the bottleneck link is located is facing expansion and adapt 145 some flows to another path, in order to ensure the service 146 experiences. 148 The congestion of this bottleneck link may be suspected to be caused 149 by traffic coming from NodeN1, or coming from NodeN3. There is a 150 lack of a measure of a path congestion. So A Path Congestion Metric 151 is required to directly report the degree of path congestion, and is 152 accurate. 154 2. A singleton definition of a Type-P-Path-Congestion Metric 156 2.1. Metric Name 158 Type-P-Path-Congestion use the Type-P convention as described 159 in[RFC2330] . 161 2.2. Metric Parameters 163 o Src, the IP address of a host 165 o Dst, the IP address of a host 167 o dpt, transmission period of a measurement. For example, a 168 measurement is trigged once dpt (such as 3.3 milliseconds) 170 o dt, interval from when Src initiates the measurement message to 171 when Dst receives it. 173 o T, a time 175 o SrcCountp, the number of packets at source node in one dpt period. 176 When Src sent the first bit of a Type-P packet to Dst, This 177 parameter starts counting. And The counting is terminated after 178 the end of the cycle. This data can be collected locally at the 179 entry of the traffic import the path from Src to Dst. 181 o DstCountp, the number of packets at destination node in one dpt 182 period. When Dst receive the first bit of a Type-P packet to Dst 183 and the counting is terminated after the end of the cycle. 184 Because the statistics of the counting is based on the path ,the 185 related data can be collected locally based on the PathID what may 186 be SR label list[RFC8402] or VXLAN ID[RFC7348]. 188 2.3. Metric unit 190 The value of a Type-P-Path-Congestion is either a real number or an 191 undefined (informally, infinite) number. 193 2.4. Definition 195 For a real number c, 197 o the *Type-P-Path-Congestion* from Src to Dst at T is 0, which 198 means that Src sent the first bit of a Type-P packet to Dst at 199 wire time* T and that there is no path congestion to Dst. 201 o the *Type-P-One-way-Delay* from Src to Dst at T is greater than 0, 202 which means that Src sent the first bit of a Type-P packet to Dst 203 at wire time* T and there is the path congestion to Dst. 205 In theory, this metric is larger while the path congestion is more 206 serious. 208 2.5. Methodologies 210 As with other Type-P-* metrics, the detailed methodology will depend 211 on the Type-P (e.g., protocol number, UDP/TCP port number, size, 212 Differentiated Services (DS) Field[RFC2780]. 214 The measurement methodology described in this section assumes the 215 measurement and determination of Type-P-Path-Congestion in real-time. 217 |---dpt---|---dpt---|---dpt---| 218 I1 219 Src ------------------------------- 220 \ | \ | 221 \ | \ | 222 \ | \ | 223 \| \| 224 Dst ------------------------------- 225 I2 I3 226 dpr = (I3 - I2) = (n*dpt + PathQueueDelay) 228 Figure 2: Measurement 230 As Figure 2 is shown, for a given Type-P, the methodology would 231 proceed as follows: 233 o Start after time I1. At the Src host, select Src and Dst IP 234 addresses, and form test packets of Type-P with these addresses 235 according to a given technique (e.g., the Poisson sampling 236 technique). The test packet can be used to dye traffic packets or 237 generate a packet[RFC7799][RFC8321]. 239 o At the Dst host, arrange to receive the packet. 241 o At the Src host, place a timestamp in the prepared Type-P packet, 242 and send it towards Dst. 244 o If the packet arrives within a reasonable period of time, take a 245 time stamp I2 as soon as possible upon the receipt of the packet. 246 By subtracting the two time stamps, an estimate of 5.3. Type-P- 247 One-way-Delay-Minimum[RFC7679] can be computed. 249 o If the packet meets the selection function criterion for the first 250 packet, record this first Type-P-One-way-Delay-Minimum value. 252 * Long-term measurement 254 + At the Src host, the packets continue to be generated 255 according to the given methodology. The Src host places a 256 time stamp in the Type-P packet, and send it towards Dst. 257 If the packet arrives within a reasonable period of time, 258 take a time stamp I3 as soon as possible upon the receipt of 259 the packet. 261 * Short-term measurement 263 + After sending the first test message, the Src host sends a 264 measurement message once dpt. Generating the Type-P packet 265 stream is as above. 267 + At the Dst host, when receiving the first measurement 268 packet, it also sends a response packet to the Dst Host once 269 dpt. The purpose of this is to improve measurement 270 accuracy. Because when the packet is sent back the measured 271 packet may not reach the Dst Host. 273 o So 275 * In long term measurement, the congestion parameters are 276 calculated as follows: 278 + c = (( I3 - I2) / tp ) -1 280 * In long-term measurement, the congestion parameters are 281 calculated as follows: 283 + c = (SrcCountp / DstCountp)-1 285 Therefore, the overall solution needs to consider two methods of 286 long-period measurement and short-period measurement. The two data 287 from the two method can also be verified against each other if 288 necessary. 290 2.6. Reporting the Metric 292 The calibration and context in which the metric is measured MUST be 293 carefully considered and SHOULD always be reported along with metric 294 results. We now present four items to consider: the Type-P of test 295 packets, the threshold of infinite delay (if any), error calibration, 296 and the path traversed by the test packets. This list is not 297 exhaustive; any additional information that could be useful in 298 interpreting applications of the metrics should also be reported (see 299 [RFC6703] for extensive discussion of reporting considerations for 300 different audiences)[RFC6703]. 302 3. A Definition for Samples of Path Congestion 304 The goal of the sample definition is to make it possible to compute 305 the statistics of sequences of Path Congestion measurements. 307 3.1. Metric Name 309 Type-P-Path-Congestion-Poisson-stream 311 3.2. Metric Parameters 313 o Src, the IP address of a host 315 o Dst, the IP address of a host 317 o dpt[i], transmission period of a measurement. For example, a 318 measurement is trigged once dpt (such as 3.3 milliseconds). 320 o dt[i], interval from when Src initiates the measurement message to 321 when Dst receives it 323 o T0, a time 325 o Tf, a time 327 o lambda, a rate in reciprocal seconds 329 o SrcCountp[i], the number of packets at source node in one dpt 330 period. When Src sent the first bit of a Type-P packet to Dst, 331 This parameter starts counting. And The counting is terminated 332 after the end of the cycle. This data can be collected locally at 333 the entry of the traffic import the path from Src to Dst. 335 o DstCountp[i], the number of packets at destination node in one dpt 336 period. When Dst receive the first bit of a Type-P packet to Dst 337 and the counting is terminated after the end of the cycle. 338 Because the statistics of the counting is based on the path ,the 339 related data can be collected locally based on the PathID what may 340 be SR label list[RFC8402] or VXLAN ID[RFC7348]. 342 3.3. Metric Units 344 A sequence of four parameters whose elements are: 346 o T, a time, and 348 o c, either a zero (signifying no congestion transmission of the 349 packet) or greater than a zero (signifying congestion). 351 3.4. Definition 353 Given T0, Tf, and lambda, we compute a pseudorandom Poisson process 354 beginning at or before T0, with average arrival rate lambda, and 355 ending at or after Tf. Those time values greater than or equal to T0 356 and less than or equal to Tf are then selected. 358 At each of the selected times in this process, we obtain one value of 359 Type-P-One-Path-Congestion. The value of the sample is the sequence 360 made up of the resulting pair . If there are no such pair, 361 the sequence is of length zero and the sample is said to be empty. 363 3.5. Methodologies 365 The methodologies follow directly from: 367 o The selection of specific times using the specified Poisson 368 arrival process, and 370 o The methodologies discussion already given for the singleton Type- 371 P-One-Path-Congestion metric. 373 * Type-P-Path-Congestion[i] = ( ( SrcCountp[i]) / ( DstCountp[i]) 374 ) -1 376 3.6. Reporting the Metric 378 The calibration and context for the underlying singletons MUST be 379 reported along with the stream. 381 4. Security Considerations 383 The path congestion metric has the same security properties as 384 [RFC7679], and thus they inherit the security considerations of that 385 document. 387 5. IANA Considerations 389 TBD 391 6. Acknowledgements 393 TBD 395 7. Normative References 397 [draft-dang-ippm-multi-paths-concurrent-measurement] 398 "Multi-paths Concurrent Measurement". 400 [draft-ietf-spring-segment-routing-policy] 401 "Segment Routing Policy Architecture", 402 . 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, 407 DOI 10.17487/RFC2119, March 1997, 408 . 410 [RFC2330] "Framework for IP Performance Metrics", 411 . 413 [RFC2780] "RFC2780", . 415 [RFC6703] "Reporting IP Network Performance Metrics: Different 416 Points of View", 417 . 419 [RFC7348] "Virtual eXtensible Local Area Network (VXLAN)", 420 . 422 [RFC7679] "A One-Way Delay Metric for IP Performance Metrics 423 (IPPM)", . 425 [RFC7799] "Active and Passive Metrics and Methods (with Hybrid Types 426 In-Between)", . 428 [RFC8321] "Alternate-Marking Method for Passive and Hybrid 429 Performance Monitoring", 430 . 432 [RFC8402] "Segment Routing Architecture", 433 . 435 Author's Address 437 Joanna Dang (editor) 438 Huawei 439 Beijing 440 China 442 Email: dangjuanna@huawei.com