idnits 2.17.00 (12 Aug 2021) /tmp/idnits32497/draft-zheng-ippm-passive-gap-analysis-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2013) is 3130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-ippm-2330-update has been published as RFC 7312 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft S. Aldrin 4 Intended status: Informational Huawei Technologies 5 Expires: April 21, 2014 October 18, 2013 7 Gap Analysis of IPPM Passive Measurements 8 draft-zheng-ippm-passive-gap-analysis-00.txt 10 Abstract 12 This document performs a gap analysis of the current state of IPPM WG 13 and ongoing work, in terms of passive measurements, according to the 14 new charter of the IPPM WG. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC 2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Passive Measurements VS Active Measurements . . . . . . . . . 2 58 3. Gap Analysis for Passive Measurements . . . . . . . . . . . . 3 59 3.1. Framework for IP Performance Metrics . . . . . . . . . . 3 60 3.2. IP Performance Metrics . . . . . . . . . . . . . . . . . 4 61 3.3. Registry . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Future Work for Passive Measurement . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 The IPPM working group has been recently re-chartered. According to 74 the new charter, passive measurement and hybrid measurement methods 75 are now included. This document performs a gap analysis of the 76 current status of work in the IPPM WG in terms of passive 77 measurements. Section 2 of the document gives a brief introduction 78 of passive measurement. Section 3 summarizes the current status of 79 the IPPM, and gives an analysis on what is missing or was not 80 considered, for passive measurements, in terms of framework of 81 metrics, measurement of metrics, registry, etc. Section 4 lists the 82 future work required for passive measurements based on the gap 83 analysis. The analysis for hybrid measurements is out of the scope 84 of this document. 86 2. Passive Measurements VS Active Measurements 88 Passive and active measurements are two common approaches for 89 monitoring the network. The passive approach measures real traffic 90 and does not increase the traffic on the network for the 91 measurements. This makes it attractive for in-service monitoring, 92 network trouble-shooting and fault location. Since the passive 93 approach may require viewing packets on the network, there can be 94 privacy or security issues. The active approach relies on the 95 capability to inject test packets into the network, but as such it 96 creates extra traffic. The benefit of active measurements is that 97 they can be run from virtually anywhere in the network. One 98 difficulty, though, is that the discrete nature of active probing 99 limits the resolution of the measurements. There is also evidence of 100 limitations of probe-based packet loss measurement in low-loss 101 environments. Both passive and active measurements have their 102 strengths and should be regarded as complementary. 104 3. Gap Analysis for Passive Measurements 106 This section gives an analysis on what is missing for passive 107 measurements in relation to IPPM, in terms of framework of metrics, 108 measurement of metrics and registry. 110 3.1. Framework for IP Performance Metrics 112 The IETF IP Performance Metrics (IPPM) working group first created a 113 framework for metric development in [RFC2330], which enabled 114 development of many fundamental metrics. [RFC2330] has been updated 115 once by [RFC5835], which describes a detailed framework for composing 116 and aggregating metrics originally defined in [RFC2330]. 118 The ongoing work [I-D.ietf-ippm-2330-update] proposes to update the 119 IPPM Framework with advanced considerations for measurement 120 methodology and testing. It describes new stream parameters for both 121 network characterization and support of application design using IPPM 122 metrics. All the previous work done for IP performance metrics 123 framework and the ongoing update for the framework has the 124 assumption, which is not explicitly stated, that the measurement 125 method of the metrics is active measurement. 127 The result of this is, while many of the current framework aspects 128 are still applicable to passive measurement, some of them are not 129 applicable. In one example, section 11 of [RFC2330] introduces a 130 separation between three distinct notions: singletons, samples, and 131 statistics, which are not applicable to passive measurements, since 132 the test packet is not required for passive measurements, nor is the 133 sampling. 135 But there are certainly equivalent concepts in passive measurements. 136 For example, consider using TCP traffic to determine the two-way 137 delay between two hosts. A singleton would be the timing of a single 138 sequence number - acknowledgement pairing, a sample would be a 139 collection of these, and the statistical metric would take the 140 minimum, over a short time interval (in order to reduce or eliminate 141 think-time and delayed-ACK effects). In another example, the concept 142 of a packet of type "P", while still applicable in principle, will 143 have to be specified differently. An updated or new passive 144 framework document is needed, while equivalent concepts need to be 145 carried over as much as possible with passive-friendly definitions. 147 3.2. IP Performance Metrics 149 The IPPM WG has defined more than 30 metrics, the most recently 150 published document that defines metrics is [RFC6049]. The commonly 151 used metrics include IPPM Metrics for Measuring Connectivity 152 [RFC2678], One-way Delay Metrics[RFC2679], One-way Packet Loss 153 Metrics [RFC2680], Round-trip Delay Metrics [RFC2681], One-way Loss 154 Pattern Sample Metrics[RFC3357], IP Packet Delay Variation Metric 155 [RFC3393], IPPM Metrics for periodic streams [RFC3432] etc. 157 All the existing metrics defined follow the framework for IP 158 performance metrics [RFC2330] , which has the implicit assumption 159 that the measurement method of the metrics is active measurement. 160 Passive methodologies for existing [RFC2330] based active metrics 161 need to be defined, which would require loosening some of the 162 constraints as well as changes to the guidelines. For example, the 163 measurement methodologies for One-way Delay Metrics [RFC2679] and 164 One-way Packet Loss Metrics [RFC2680] call for, amongst other things, 165 selection of the Src and Dst addresses at the Src host. This will be 166 difficult to achieve for passive measurement. 168 Careful examination and thorough analysis needs to be made, in order 169 to decide, which aspects of current metrics need to be redefined for 170 passive measurements, and which aspects could be reused by passive 171 measurements as is. 173 3.3. Registry 175 [RFC4148] defines an initial registry of the metrics defined in the 176 IPPM WG and the rules to manage the registry. However, [RFC4148] was 177 obsoleted by [RFC6248] because it was "not believed to be feasible or 178 even useful to register every possible combination of Type P, metric 179 parameters, and Stream parameters using the current structure of the 180 IPPM Metrics Registry". This led to the [RFC4148] registry having 181 "very few users, if any". 183 The ongoing work [I-D.bagnulo-ippm-new-registry-independent] and 184 [I-D.bagnulo-ippm-new-registry] creates, a registry for commonly used 185 metrics, defines the rules for assignments in the new registry and 186 performs initial allocations, respectively. 187 [I-D.bagnulo-ippm-new-registry-independent] proposes one particular 188 registry structure with independent registries for each of the fields 189 involved, while [I-D.bagnulo-ippm-new-registry] explores an 190 alternative structure with a single registry with multiple sub- 191 registries. The metrics for passive measurement should be taken into 192 consideration for both registry structure designs. 194 4. Future Work for Passive Measurement 196 Based on the above gap analysis, it could be concluded that the 197 following new work needs to be done in the IPPM working group: 199 1. Framework for metrics: An passive-friendly updated framework 200 document is needed for passive measurement. 202 2. Metrics: Careful examination on currently defined metrics, 203 particularly the measurement aspects, needs to be made by the working 204 group. Some metrics need to be updated for passive measurement, some 205 metrics may be reused by passive measurements as is. New metrics may 206 also need to be defined for passive measurement. 208 3. Registry: The passive measurement should be taken into 209 consideration for the ongoing registry structure design work. 211 5. Security Considerations 213 This document does not bring new security issue to IPPM. 215 6. IANA Considerations 217 This document makes no request to IANA. 219 7. Acknowledgements 221 The authors would like to thank Brain Trammell, Paul Coverdale for 222 their valuable comments. 224 8. References 225 8.1. Normative References 227 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 228 Requirement Levels", BCP 14, RFC 2119, March 1997. 230 8.2. Informative References 232 [I-D.bagnulo-ippm-new-registry-independent] 233 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 234 A. Morton, "A registry for commonly used metrics. 235 Independent registries", draft-bagnulo-ippm-new-registry- 236 independent-01 (work in progress), July 2013. 238 [I-D.bagnulo-ippm-new-registry] 239 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 240 A. Morton, "A registry for commonly used metrics", draft- 241 bagnulo-ippm-new-registry-01 (work in progress), July 242 2013. 244 [I-D.ietf-ippm-2330-update] 245 Fabini, J. and A. Morton, "Advanced Stream and Sampling 246 Framework for IPPM", draft-ietf-ippm-2330-update-01 (work 247 in progress), October 2013. 249 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 250 "Framework for IP Performance Metrics", RFC 2330, May 251 1998. 253 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 254 Connectivity", RFC 2678, September 1999. 256 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 257 Delay Metric for IPPM", RFC 2679, September 1999. 259 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 260 Packet Loss Metric for IPPM", RFC 2680, September 1999. 262 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 263 Delay Metric for IPPM", RFC 2681, September 1999. 265 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 266 Metrics", RFC 3357, August 2002. 268 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 269 Metric for IP Performance Metrics (IPPM)", RFC 3393, 270 November 2002. 272 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 273 performance measurement with periodic streams", RFC 3432, 274 November 2002. 276 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 277 Registry", BCP 108, RFC 4148, August 2005. 279 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 280 Composition", RFC 5835, April 2010. 282 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 283 Metrics", RFC 6049, January 2011. 285 [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics 286 (IPPM) Registry of Metrics Are Obsolete", RFC 6248, April 287 2011. 289 Authors' Addresses 291 Lianshu Zheng 292 Huawei Technologies 293 China 295 Email: vero.zheng@huawei.com 297 Sam K. Aldrin 298 Huawei Technologies 300 Email: aldrin.ietf@gmail.com