idnits 2.17.00 (12 Aug 2021) /tmp/idnits42226/draft-morton-ippm-composition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 911. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There are 8 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Unrecognized Status in 'Category: Individual', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'T' is mentioned on line 379, but not defined == Missing Reference: 'Tf' is mentioned on line 379, but not defined == Unused Reference: 'RFC791' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC3148' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'Pax98' is defined on line 820, but no explicit reference was found in the text == Unused Reference: 'RFC3393' is defined on line 824, but no explicit reference was found in the text == Unused Reference: 'I-D.stephan-ippm-multimetrics' is defined on line 832, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Downref: Normative reference to an Informational RFC: RFC 3148 ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) == Outdated reference: A later version (-02) exists of draft-stephan-ippm-multimetrics-01 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A.Morton,Editor 3 Internet Draft AT&T Labs 4 Document: E.Stephan 5 FranceTelecom 6 Category: Individual 8 Spatial Composition of Metrics 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of BCP 78. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This memo utilizes IPPM metrics that are applicable to both complete 43 paths and sub-paths, and defines relationships to compose a complete 44 path metric from the sub-path metrics with some accuracy w.r.t. the 45 actual metrics. This is called Spatial Composition in RFC 2330. The 46 current version of the memo gives some background and proposes 47 wording for a Scope and Application section to define this new work. 48 The description of several example metrics and statistics follow. 50 Contents 52 Status of this Memo................................................1 53 Copyright Notice...................................................1 54 Abstract...........................................................1 55 Authors/Contributors...............................................3 56 1. Conventions used in this document...............................3 57 2. Introduction....................................................3 58 2.1 Motivation....................................................4 59 3. Proposed Scope and Application..................................5 60 3.1 Scope of Work.................................................5 61 3.2 Application...................................................6 62 3.3 Terminology...................................................6 63 4. One-way Delay Composition Metrics and Statistics................7 64 4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream......7 65 4.1.1 Metric Parameters:...........................................7 66 4.1.2 Definition:..................................................7 67 4.1.3 Discussion and other details.................................7 68 4.1.4 Mean Statistic...............................................7 69 4.1.5 Composition Relationship: Sum of Mean Delays.................8 70 4.1.6 Statement of Conjecture......................................8 71 4.1.7 Justification for the composite relationship.................8 72 4.1.8 Sources of Error.............................................8 73 4.1.9 Specific cases where the conjecture might fail...............9 74 4.1.10 Application of Measurement Methodology......................9 75 5. Loss Metrics/Statistics.........................................9 76 5.1 Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream.......9 77 5.1.1 Metric Parameters:..........................................10 78 5.1.2 Metric Units:...............................................10 79 5.1.3 Discussion and other details................................10 80 5.1.4 Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 10 81 5.1.5 Composition Relationship: Combination of Empirical 82 Probabilities.....................................................11 83 5.1.6 Statement of Conjecture.....................................11 84 5.1.7 Justification for the composite relationship................11 85 5.1.8 Sources of Error............................................11 86 5.1.9 Specific cases where the conjecture might fail..............12 87 5.1.10 Application of Measurement Methodology.....................12 88 6. Delay Variation Metrics/Statistics.............................12 89 7. Other Metrics/Statistics: One-way combined Metric..............12 90 7.1 Metric Name...................................................13 91 7.1.1 Metric Parameters:..........................................13 92 7.1.2 Definition:.................................................13 93 7.1.3 Discussion and other details................................13 94 7.1.4 Type-P-One-way-Combo-subpathes-stream.......................13 95 7.1.5 Type-P-One-way-composition..................................14 96 7.1.6 Type-P-One-way-composition-stream...........................14 97 7.1.7 Statement of Conjecture.....................................15 98 7.1.8 Justification for the composite relationship................15 99 7.1.9 Sources of Error............................................15 100 7.1.10 Specific cases where the conjecture might fail.............15 101 7.1.11 Application of Measurement Methodology.....................15 102 8. Security Considerations........................................15 103 8.1 Denial of Service Attacks.....................................15 104 8.2 User data confidentiality.....................................16 105 8.3 Interference with the metric..................................16 106 9. IANA Considerations............................................16 107 10. Normative References..........................................16 108 11. Informative References........................................17 109 12. Open issues...................................................18 110 13. Acknowledgments...............................................18 111 14. Author's Addresses............................................18 112 Full Copyright Statement..........................................18 113 Intellectual Property.............................................19 114 Acknowledgement...................................................19 116 Authors/Contributors 118 Thus far, the following people have contributed useful ideas, 119 suggestions, or the text of sections that have been incorporated 120 into this memo: 122 - Phil Chimento 123 - Reza Fardid 124 - Roman Krzanowski 125 - Maurizio Molina 126 - Al Morton 127 - Emile Stephan 128 - Lei Liang 130 1. Conventions used in this document 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 Although RFC 2119 was written with protocols in mind, the key words 136 are used in this document for similar reasons. They are used to 137 ensure the results of measurements from two different 138 implementations are comparable, and to note instances when an 139 implementation could perturb the network. 141 In this memo, the characters "<=" should be read as "less than or 142 equal to" and ">=" as "greater than or equal to". 144 2. Introduction 146 The IPPM framework RFC 2330 [RFC2330] describes two forms of metric 147 composition, spatial and temporal. Spatial composition encompasses 148 the definitions of performance metrics that are applicable to the 149 complete path, and to various sub-paths. Also, the text suggests 150 that the concepts of the analytical framework (or A-frame) would 151 help to define useful relationships between the complete path 152 metrics and the sub-path metrics. The effectiveness of such metrics 153 is dependent on their usefulness in analysis and applicability with 154 practical measurement methods. 156 The relationships may involve conjecture, and [RFC2330] lists four 157 points that the metric definitions should include: 159 + the specific conjecture applied to the metric, 160 + a justification of the practical utility of the composition in 161 terms of making accurate measurements of the metric on the path, 162 + a justification of the usefulness of the composition in terms of 163 making analysis of the path using A-frame concepts more 164 effective, and 165 + an analysis of how the conjecture could be incorrect. 167 RFC 2330 also gives an example where a conjecture that the delay of 168 a path is very nearly the sum of the delays of the exchanges and 169 clouds of the corresponding path digest. This example is 170 particularly relevant to those who wish to assess the performance of 171 an Inter-domain path without direct measurement, and the performance 172 estimate of the complete path is related to the measured results for 173 various sub-paths instead. 175 Approximate relationships between the sub-path and complete path 176 metrics are useful, with knowledge of the circumstances where the 177 relationships are/are not applicable. For example, we would not 178 expect that delay singletons from each sub-path would sum to produce 179 an accurate estimate of a delay singleton for the complete path 180 (unless all the delays were essentially constant - very unlikely). 181 However, other delay statistics (based on a reasonable sample size) 182 may have a sufficiently large set of circumstances where they are 183 applicable. 185 2.1 Motivation 187 One-way metrics defined in other IPPM RFCs all assume that the 188 measurement can be practically carried out between the source and 189 the destination of the interest. Sometimes there are reasons that 190 the measurement can not be executed from the source to the 191 destination. For instance, the measurement path may cross several 192 independent domains that have conflicting policies, measurement 193 tools and methods, and measurement timeslot assignment. and the 194 simple One-way measurement can not be carried out. The solution then 195 may be the composition of several sub-path measurements. That means 196 each domain performs the One-way measurement on a sub path between 197 two nodes that are involved in the complete path following it own 198 policy, using its own measurement tools and methods, and within its 199 own measurement timeslot. One can combine all the sub-path One-way 200 mmetric results to estimate the complete path One-way measurement 201 metric with some accuracy. 203 >>>>>>>>>>>>Open issue: 204 What is the relationship between the decomposition and composition 205 metrics? Should we put both kinds in one draft to make up a 206 framework? The motivation of decomposition is as follows: 208 The One-way measurement can provide result to show what the network 209 performance between two end hosts is and whether it meets operator 210 expectations or not. It cannot provide further information to 211 engineers where and how to improve the performance between the 212 source and the destination. For instance, if the network performance 213 is not acceptable in terms of the One-way measurement, in which part 214 of the network the engineers should put their efforts. This question 215 can to be answered by decompose the One-way measurement to sub-path 216 measurement to investigate the performance of different part of the 217 network. 219 Editor’s Questions for clarification: 220 What additional information would be provided to the decomposition 221 process, beyond the measurement of the complete path? 223 Is the decomposition described above intended to estimate a metric 224 for some/all disjoint sub-paths involved in the complete path? 226 >>>>>>>>>>>>>>>>>>> 228 3. Proposed Scope and Application 230 3.1 Scope of Work 232 For the primary IPPM metrics (currently Loss, Delay, and Delay 233 Variation), this memo gives a set of complete path metrics that can 234 be composed from the same or similar sub-path metrics. This means 235 that the complete path metric may be composed from: 237 + the same metric for each sub-path; 239 + multiple metrics for each sub-path (possibly one that is the same 240 as the complete path metric); 242 + a single sub-path metrics that is different from the complete 243 path metric; 245 + different measurement techniques like active and passive 246 (recognizing that PSAMP WG will define capabilities to sample 247 packets to support measurement). 249 Each metric will clearly state: 251 - the definition (and statistic, where appropriate); 253 - the composition relationship; 255 - the specific conjecture on which the relationship is based; 257 - a justification of practical utility or usefulness for analysis 258 using the A-frame concepts; 260 - one or more examples of how the conjecture could be incorrect and 261 lead to inaccuracy; 263 - the information to be reported; 265 3.2 Application 267 For each metric, the applicable circumstances are defined, in terms 268 of whether the composition: 270 Requires the same test packets to traverse all sub-paths, or may use 271 similar packets sent and collected separately in each sub-path. 273 Requires homogeneity of measurement methodologies, or can allow a 274 degree of flexibility (e.g., active or passive methods produce the 275 "same" metric). Also, the applicable sending streams will be 276 specified, such as Poisson, Periodic, or both. 278 Needs information or access that will only be available within an 279 operator's domain, or is applicable to Inter-domain composition. 281 Requires synchronized measurement time intervals in all sub-paths, 282 or largely overlapping, or no timing requirements. 284 Requires assumption of sub-path independence w.r.t. the metric being 285 defined/composed, or other assumptions. 287 Has known sources of inaccuracy/error, and identifies the sources. 289 3.3 Terminology 291 This section will define the terminology applicable to both complete 292 path and sub-path metrics. 294 Measurement Points: 296 298 Equivalent measure: 300 The equivalent measure is the end-to-end metric that a composite 301 metric is estimating. 303 Equivalent path: 305 The Equivalent path is the list of sub path that is equivalent to 306 the path of the end-to-end measure the composition measure is 307 estimating. 309 4. One-way Delay Composition Metrics and Statistics 311 4.1 Name: Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream 313 4.1.1 Metric Parameters: 315 + Src, the IP address of a host 317 + Dst, the IP address of a host 319 + T, a time (start of test interval) 321 + Tf, a time (end of test interval) 323 + lambda, a rate in reciprocal seconds (for Poisson Streams) 325 + incT, the nominal duration of inter-packet interval, first bit to 326 first bit (for Periodic Streams) 328 + T0, a time that MUST be selected at random from the interval 329 [T, T+dT] to start generating packets and taking measurements 330 (for Periodic Streams) 332 + TstampSrc, the wire time of the packet as measured at MP(Src) 334 + TstampDst, the wire time of the packet as measured at MP(Dst), 335 assigned to packets that arrive within a "reasonable" time. 337 4.1.2 Definition: 339 Using the parameters above, we obtain the value of Type-P-One-way- 340 Delay singleton as per RFC 2679 [RFC2679]. For each packet [i] that 341 has a finite One-way Delay (in other words, excluding packets which 342 have undefined, or infinite one-way delay): 344 Type-P-Finite-One-way-Delay-Poisson/Periodic-Stream[i] = 345 FiniteDelay[i] = TstampDst - TstampSrc 347 4.1.3 Discussion and other details... 349 4.1.4 Mean Statistic 351 + L, the total number of packets received at Dst (sent between T0 352 and Tf) 354 The 356 Type-P-Finite-One-way-Delay-Mean = 358 MeanDelay = (1/L)Sum(from i=1 to L, FiniteDelay[i]) 360 where all packets i= 1 through L have finite singleton delays. 362 4.1.5 Composition Relationship: Sum of Mean Delays 364 The Type-P-Finite—Composite-One-way-Delay-Mean, or MeanDelay for the 365 complete Source to Destination path can be calculated from sum of 366 the Mean Delays of all its S constituent sub-paths. 368 + S, the number of sub-paths involved in the complete Src-Dst path 370 Then the 372 Type-P-Finite-Composite-One-way-Delay-Mean = 374 CompMeanDelay = (1/S)Sum(from i=1 to S, MeanDelay[i]) 376 4.1.6 Statement of Conjecture 378 The mean of a sufficiently large stream of packets measured on each 379 sub-path during the interval [T, Tf] will be representative of the 380 true mean of the delay distribution (and the distributions 381 themselves are sufficiently independent), such that the means may be 382 added to produce an estimate of the complete path mean delay. 384 4.1.7 Justification for the composite relationship 386 It is sometimes impractical to conduct active measurements between 387 every Src-Dst pair. For example, it may not be possible to collect 388 the desired sample size in each test interval when access link speed 389 is limited, because of the potential for measurement traffic to 390 degrade the user traffic performance. The conditions on a low-speed 391 access link may be understood well-enough to permit use of a small 392 sample size/rate, while a larger sample size/rate may be used on 393 other sub-paths. 395 Also, since measurement operations have a real monetary cost, there 396 is value in re-using measurements where they are applicable, rather 397 than launching new measurements for every possible source- 398 destination pair. 400 4.1.8 Sources of Error 401 The measurement packets, each having source and destination 402 addresses intended for collection at edges of the sub-path, may take 403 a different specific path through the network equipment and parallel 404 exchanges than packets with the source and destination addresses of 405 the complete path. Therefore, the sub-path measurements may differ 406 from the performance experienced by packets on the complete path. 407 Multiple measurements employing sufficient sub-path address pairs 408 might produce bounds on the extent of this error. 410 others... 412 4.1.9 Specific cases where the conjecture might fail 414 If any of the sub-path distributions are bimodal, then the measured 415 means may not be stable, and in this case the mean will not be a 416 particularly useful statistic when describing the delay distribution 417 of the complete path. 419 The mean may not be sufficiently robust statistic to produce a 420 reliable estimate, or to be useful even if it can be measured. 422 others... 424 4.1.10 Application of Measurement Methodology 426 The methodology: 428 SHOULD use similar packets sent and collected separately in each 429 sub-path. 431 Allows a degree of flexibility (e.g., active or passive methods can 432 produce the "same" metric, but timing and correlation of passive 433 measurements is much more challenging). 435 Poisson and/or Periodic streams are RECOMMENDED. 437 Applicable to both Inter-domain and Intra-domain composition. 439 SHOULD have synchronized measurement time intervals in all sub- 440 paths, but largely overlapping intervals MAY suffice. 442 REQUIRES assumption of sub-path independence w.r.t. the metric being 443 defined/composed. 445 5. Loss Metrics/Statistics 447 >>>>>>>>>>>>>>>>> 448 Editor’s note: there is considerable redundancy between the material 449 in sections 5.1 and 4.1, need to determine how best to reduce it. 451 5.1 Name: Type-P-One-way-Packet-Loss-Poisson/Periodic-Stream 452 5.1.1 Metric Parameters: 454 + Src, the IP address of a host 456 + Dst, the IP address of a host 458 + T, a time (start of test interval) 460 + Tf, a time (end of test interval) 462 + lambda, a rate in reciprocal seconds (for Poisson Streams) 464 + incT, the nominal duration of inter-packet interval, first bit to 465 first bit (for Periodic Streams) 467 + T0, a time that MUST be selected at random from the interval 468 [T, T+dT] to start generating packets and taking measurements 469 (for Periodic Streams) 471 + TstampSrc, the wire time of the packet as measured at MP(Src) 473 + TstampDst, the wire time of the packet as measured at MP(Dst), 474 assigned to packets that arrive within a "reasonable" time. 476 + Tmax, a maximum waiting time for packets at the destination 478 5.1.2 Metric Units: 480 Using the parameters above, we obtain the value of Type-P-One-way- 481 Packet-Loss singleton and stream as per RFC 2680 [RFC2680]. We 482 obtain a sequence of pairs with elements as follows: 484 + TstampSrc, as above 486 + L, either zero or one, where L=1 indicates loss and L=0 indicates 487 arrival at the destination within TstampSrc + Tmax. 489 5.1.3 Discussion and other details... 491 5.1.4 Statistic: Type-P-One-way-Packet-Loss-Empirical-Probability 493 Given the following stream parameter 495 + N, the total number of packets sent between T0 and Tf 497 We can define the Empirical Probability of Loss Statistic (Ep), 498 consistent with Average Loss in [RFC2680], as follows: 500 Type-P-One-way-Packet-Loss-Empirical-Probability = 501 Ep = (1/N)Sum(from i=1 to N, L[i]) 503 where all packets i= 1 through N have a value for L. 505 5.1.5 Composition Relationship: Combination of Empirical Probabilities 507 The Type Type-P-One-way-Composite-Packet-Loss-Empirical-Probability, 508 or CompEp for the complete Source to Destination path can be 509 calculated by combining Ep of all its constituent sub-paths (Ep1, 510 Ep2, Ep3, ... Epn) as 512 Type-P-One-way-Composite-Packet-Loss-Empirical-Probability = 513 CompEp = 1 – {(1 - Ep1) x (1 – Ep2) x (1 – Ep3) x ... x (1 – Epn)} 515 5.1.6 Statement of Conjecture 517 The empirical probability of loss calculated on a sufficiently large 518 stream of packets measured on each sub-path during the interval [T, 519 Tf] will be representative of the true loss probability (and the 520 probabilities themselves are sufficiently independent), such that 521 the sub-path probabilities may be combined to produce an estimate of 522 the complete path loss probability. 524 5.1.7 Justification for the composite relationship 526 It is sometimes impractical to conduct active measurements between 527 every Src-Dst pair. For example, it may not be possible to collect 528 the desired sample size in each test interval when access link speed 529 is limited, because of the potential for measurement traffic to 530 degrade the user traffic performance. The conditions on a low-speed 531 access link may be understood well-enough to permit use of a small 532 sample size/rate, while a larger sample size/rate may be used on 533 other sub-paths. 535 Also, since measurement operations have a real monetary cost, there 536 is value in re-using measurements where they are applicable, rather 537 than launching new measurements for every possible source- 538 destination pair. 540 5.1.8 Sources of Error 542 The measurement packets, each having source and destination 543 addresses intended for collection at edges of the sub-path, may take 544 a different specific path through the network equipment and parallel 545 exchanges than packets with the source and destination addresses of 546 the complete path. Therefore, the sub-path measurements may differ 547 from the performance experienced by packets on the complete path. 548 Multiple measurements employing sufficient sub-path address pairs 549 might produce bounds on the extent of this error. 551 others... 553 5.1.9 Specific cases where the conjecture might fail 555 A concern for loss measurements combined in this way is that root 556 causes may be correlated to some degree. 558 For example, if the links of different networks follow the same 559 physical route, then a single event like a tunnel fire could cause 560 an outage or congestion on remaining paths in multiple networks. 561 Here it is important to ensure that measurements before the event 562 and after the event are not combined to estimate the composite 563 performance. 565 Or, when traffic volumes rise due to the rapid spread of an email- 566 born worm, loss due to queue overflow in one network may help 567 another network to carry its traffic without loss. 569 others... 571 5.1.10 Application of Measurement Methodology 573 The methodology: 575 SHOULD use similar packets sent and collected separately in each 576 sub-path. 578 Allows a degree of flexibility (e.g., active or passive methods can 579 produce the "same" metric, but timing and correlation of passive 580 measurements is much more challenging). 582 Poisson and/or Periodic streams are RECOMMENDED. 584 Applicable to both Inter-domain and Intra-domain composition. 586 SHOULD have synchronized measurement time intervals in all sub- 587 paths, but largely overlapping intervals MAY suffice. 589 REQUIRES assumption of sub-path independence w.r.t. the metric being 590 defined/composed. 592 6. Delay Variation Metrics/Statistics 594 >>>>>>>>>>>>> 595 Editor’s note: We have studied various approaches and have at least 596 one proposal for this section. We plan to add the text in the next 597 version. 598 >>>>>>>>>>>>> 600 7. Other Metrics/Statistics: One-way combined Metric 601 This definition may be the common part for the definition of "Loss 602 Metrics/Statistics" and for the definition of "One-way Delay 603 Composition Metrics and Statistics". 605 7.1 Metric Name 607 Type-P-One-way-Combo-mean 609 7.1.1 Metric Parameters: 611 Editorial notes (ES): parameters list to be completed 613 ...: 615 It is a stream of One-way delay corresponding either to an end 616 to end measure of a sub-path, or to the spatial measure of the 617 sub-path: 619 - Type-P-One-way-Delay-Poisson-Stream as per [RFC2679]; 620 - Type-P-One-way-Delay-Periodic-Stream a per [RFC3432]; 621 - Type-P-One-way-Composition-Stream as defined below; 622 - Type-P-subpath-One-way-Delay-Stream as per [I-D.stephan-ippm- 623 multimetrics]. 625 7.1.2 Definition: 627 Using the value ... of one of the One-way 628 delay Stream listed above, we define Type-P-One-way-Combo as the 629 couple (D,L) where D is the mean of the delay of the packets that 630 have a finite One-way, and where L is the average of lost of packets 631 (which have undefined, or infinite one-way delay). 633 D corresponds to the Type-P-Finite-One-way-Delay-Mean defined above. 635 L corresponds to the Type-P-One-way-Packet-Loss-Empirical- 636 Probability defined above. 638 7.1.3 Discussion and other details... 640 7.1.4 Type-P-One-way-Combo-subpathes-stream 642 Parameters: 644 + dT1,..., dTn a list of delay. 646 + , the equivalent path. 648 Definition: 650 Using Type-P-One-way-Combo-mean of each sub-path in the equivalent 651 path we define a Type-P-One-way-subpathes-stream as the list of 652 couples (D,L) of the sub-path list; 654 Results: {, , , … } 656 7.1.5 Type-P-One-way-composition 658 The composition over a path gives D and L which give an estimation 659 of the end-to-end delay and end-to-end packet lost over this path. 661 Parameters: 663 + , the equivalent path. 665 + {, , , … }, the composition stream 666 of the sub-pathes of a path. 668 Definition: 670 Using Type-P-One-way-subpathes-stream we define Type-P-One-way- 671 composition as the couple where D is the mean of the delays Di 672 and where L is the average of lost of Li. 674 Results: , where D is a delay and L is the lost 676 7.1.6 Type-P-One-way-composition-stream 678 The sample of Type-P-One-way-composition is defined to permit the 679 usage of the results of Type-P-One-way-composition measure in 680 computation of Type-P-One-way-Combo-mean composition. 682 Parameters: 684 + T1,..., Tn, a list of time; 686 + , the delay and the lost computed by composition. 688 Definition: 690 Using Type-P-One-way-composition we define Type-P-One-way- 691 composition-stream as the stream of couples over time. 693 Results: ... 695 7.1.7 Statement of Conjecture 697 7.1.8 Justification for the composite relationship 699 Combo metric is very easy to measure and to compose. 701 It gives the delay and the lost, so most of the need. 703 Combo metric may be performed on com metric too. 705 7.1.9 Sources of Error 707 Packets may cross different sub path than the equivalent end-to-end 708 measure because Type-P differ. 710 Packets may experiment different behavior than the equivalent end- 711 to-end measure because of access classification based on packet 712 addresses. 714 7.1.10 Specific cases where the conjecture might fail 716 When 718 + Sum of subpath differ from the equivalent path. 720 + Type-P differ. 722 + Size differ. 724 7.1.11 Application of Measurement Methodology 726 The methodology: 728 Is applicable to Intra and interdomain; 730 SHOULD report the context of the measure; 732 8. Security Considerations 734 8.1 Denial of Service Attacks 736 This metric requires a stream of packets sent from one host (source) 737 to another host (destination) through intervening networks. This 738 method could be abused for denial of service attacks directed at 739 destination and/or the intervening network(s). 741 Administrators of source, destination, and the intervening 742 network(s) should establish bilateral or multi-lateral agreements 743 regarding the timing, size, and frequency of collection of sample 744 metrics. Use of this method in excess of the terms agreed between 745 the participants may be cause for immediate rejection or discard of 746 packets or other escalation procedures defined between the affected 747 parties. 749 8.2 User data confidentiality 751 Active use of this method generates packets for a sample, rather 752 than taking samples based on user data, and does not threaten user 753 data confidentiality. Passive measurement must restrict attention to 754 the headers of interest. Since user payloads may be temporarily 755 stored for length analysis, suitable precautions MUST be taken to 756 keep this information safe and confidential. In most cases, a 757 hashing function will produce a value suitable for payload 758 comparisons. 760 8.3 Interference with the metric 762 It may be possible to identify that a certain packet or stream of 763 packets is part of a sample. With that knowledge at the destination 764 and/or the intervening networks, it is possible to change the 765 processing of the packets (e.g. increasing or decreasing delay) that 766 may distort the measured performance. It may also be possible to 767 generate additional packets that appear to be part of the sample 768 metric. These additional packets are likely to perturb the results 769 of the sample measurement. 771 To discourage the kind of interference mentioned above, packet 772 interference checks, such as cryptographic hash, may be used. 774 9. IANA Considerations 776 Metrics defined in this memo will be registered in the IANA IPPM 777 METRICS REGISTRY as described in initial version of the registry 778 [RFC4148]. 780 10. Normative References 782 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 783 September 1981. 784 Obtain via: http://www.rfc-editor.org/rfc/rfc791.txt 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", RFC 2119, March 1997. 788 Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt 790 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 791 "Framework for IP Performance Metrics", RFC 2330, May 792 1998. 793 Obtain via: http://www.rfc-editor.org/rfc/rfc2330.txt 795 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way 796 delay metric for IPPM", RFC 2679, September 1999. 797 Obtain via: http://www.rfc-editor.org/rfc/rfc2679.txt 799 [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A one-way 800 packet loss metric for IPPM", RFC 2680, September 1999. 801 Obtain via: http://www.rfc-editor.org/rfc/rfc2680.txt 803 [RFC3148] Mathis, M. and Allman, M., "A Framework for Defining 804 Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 805 2001. 806 Obtain via: http://www.rfc-editor.org/rfc/rfc3148.txt 808 [RFC3432] Raisanen, V., Grotefeld, G., and Morton, A., "Network 809 performance measurement with periodic streams", RFC 3432, 810 November 2002. 812 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 813 Registry", BCP 108, RFC 4148, August 2005. 815 11. Informative References 817 [I.356] ITU-T Recommendation I.356, "B-ISDN ATM layer cell 818 transfer performance", March 2000. 820 [Pax98] V.Paxson, "Measurements and Analysis of End-to-End 821 Internet Dynamics," Ph.D. dissertation, U.C. Berkeley, 822 1997, ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz. 824 [RFC3393] Demichelis, C., and Chimento, P., "IP Packet Delay 825 Variation Metric for IP Performance Metrics (IPPM)", RFC 826 3393, November 2002. 828 [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data 829 communication service - IP packet transfer and 830 availability performance parameters", December 2002. 832 [I-D.stephan-ippm-multimetrics] 833 Stephan, E., "IP Performance Metrics (IPPM) for spatial 834 and multicast", draft-stephan-ippm-multimetrics-01 (work 835 in progress), July 2005. 837 12. Open issues 839 Point1: 841 13. Acknowledgments 843 The authors would like to acknowledge many helpful discussions with 844 . . . (lots of people, eventually). 846 14. Author's Addresses 848 Al Morton 849 AT&T Labs 850 Room D3 - 3C06 851 200 Laurel Ave. South 852 Middletown, NJ 07748 USA 853 Phone +1 732 420 1571 854 EMail: 856 Need addresses for: 857 - Phil Chimento 858 - Reza Fardid 859 - Roman Krzanowski 860 - Maurizio Molina 862 - Emile Stephan 863 Stephan Emile 864 France Telecom Division R&D 865 2 avenue Pierre Marzin 866 Lannion, F-22307 868 Fax: +33 2 96 05 18 52 869 Email: emile.stephan@francetelecom.com 871 - Lei Liang 873 Full Copyright Statement 875 Copyright (C) The Internet Society (2005). 877 This document is subject to the rights, licenses and restrictions 878 contained in BCP 78, and except as set forth therein, the authors 879 retain all their rights. 881 This document and the information contained herein are provided on 882 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 883 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 884 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 885 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 886 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 887 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 889 Intellectual Property 891 The IETF takes no position regarding the validity or scope of any 892 Intellectual Property Rights or other rights that might be claimed 893 to pertain to the implementation or use of the technology described 894 in this document or the extent to which any license under such 895 rights might or might not be available; nor does it represent that 896 it has made any independent effort to identify any such rights. 897 Information on the procedures with respect to rights in RFC 898 documents can be found in BCP 78 and BCP 79. 900 Copies of IPR disclosures made to the IETF Secretariat and any 901 assurances of licenses to be made available, or the result of an 902 attempt made to obtain a general license or permission for the use 903 of such proprietary rights by implementers or users of this 904 specification can be obtained from the IETF on-line IPR repository 905 at http://www.ietf.org/ipr. 907 The IETF invites any interested party to bring to its attention any 908 copyrights, patents or patent applications, or other proprietary 909 rights that may cover technology that may be required to implement 910 this standard. Please address the information to the IETF at ietf- 911 ipr@ietf.org. 913 Acknowledgement 915 Funding for the RFC Editor function is currently provided by the 916 Internet Society.