idnits 2.17.1 draft-fabini-ippm-2330-time-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC2330, but the abstract doesn't seem to directly say this. It does mention RFC2330 though, so this could be OK. 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. (Using the creation date from RFC2330, updated by this document, for RFC5378 checks: 1998-05-01) -- 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.) -- The document date (October 14, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'RFC2675' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC3168' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC4494' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC5644' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC6282' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'RFC6437' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC6564' is defined on line 381, but no explicit reference was found in the text == Unused Reference: 'RFC7045' is defined on line 386, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Fabini 3 Internet-Draft TU Wien 4 Updates: 2330 (if approved) A. Morton 5 Intended status: Informational AT&T Labs 6 Expires: April 16, 2016 October 14, 2015 8 Updates for IPPM's Framework: Timestamping and Use Cases 9 draft-fabini-ippm-2330-time-00 11 Abstract 13 Quality and accuracy of measurements depend on the selection of 14 appropriate locations and timers for timestamp acquisition. This 15 memo updates the IP Performance Metrics (IPPM) Framework RFC 2330 16 with new considerations on timers, timestamps and time-related 17 definitions with particular focus on wireless networks and 18 virtualized hosts. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 16, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Definition and Use of Wire Time . . . . . . . . . . . . . . . 4 63 3.1. Virtualization . . . . . . . . . . . . . . . . . . . . . 5 64 4. Definition and Use of Host Time . . . . . . . . . . . . . . . 5 65 4.1. Virtualization . . . . . . . . . . . . . . . . . . . . . 6 66 5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 The IETF IP Performance Metrics (IPPM) working group first created a 78 framework for metric development in [RFC2330]. This framework has 79 stood the test of time and enabled development of many fundamental 80 metrics. It has been updated in the area of metric composition 81 [RFC5835], and in several areas related to active stream measurement 82 of modern networks with reactive properties [RFC7312]. 84 Time is fundamental to measurements. The IPPM framework [RFC2330] 85 includes a comprehensive terminology, definition and discussion of 86 time- and clock-related concepts. But network technology has evolved 87 since 1998. First, host computing performance and software 88 complexity have increased while network delays have decreased. These 89 advances enable development of new concepts like host virtualization 90 in cloud computing, and network function virtualization. One side- 91 effect of these technologies is that packets spend more and more time 92 in software, their propagation through the stack being biased by a 93 series of uncertainty factors like buffers, queues and operating 94 system scheduling. Measurements can acquire timestamps in various 95 locations within the host's software stack, causing potentially 96 significant variances in timestamp values [MCDC]. This is a 97 consequence of just one alternative that the IPPM framework [RFC2330] 98 defines for these timestamps: host time. This memo seeks to update 99 this aspect of the IPPM framework by discussing alternatives and 100 proposing generic solutions that can be referenced by metric 101 definitions. 103 Second, the IPPM framework was approved one year before the release 104 of the first IEEE 802.11 series standard. This was a time when the 105 data communication landscape was dominated by wired communication 106 technologies and wireless data communications were in their infancy. 107 This fact originated IPPM definitions like host time or wire time. 108 Today, after more than one decade and half, wireless IEEE 802.11 109 networks and cellular packet-switched data technologies like High- 110 Speed Packet Access (HSPA) and Long Term Evolution (LTE) are 111 responsible for an essential part of the worldwide Internet access 112 traffic. This raises the question, how the IPPM framework concept of 113 wire time can be mapped to wireless networks. 115 This memo revisits and updates time-related IPPM framework [RFC2330] 116 definitions like host time and wire time in the light of 117 technological advances. 119 2. Scope 121 The purpose of this memo is to update the IPPM metrics framework 122 [RFC2330] with respect to timestamps and virtualization. Concepts 123 like "host time" or "wire time" must be revisited to be applicable 124 for wireless networks and virtualized environments. 126 The scope is to update key sections of [RFC2330] ... 128 Potential Topics (Draft outline for discussion): 130 - Fundamentals 132 1. Host Time (further develop the definition as mentioned but not 133 defined in RFC2330. Explain variants, propose examples and 134 guidance). Dedicated subsection and challenge: virtualization. 136 2. Wire Time (rename "Wire Time" to "Medium Time" or "Media Time" to 137 account for wireless networks; revisit the definition of "Media 138 Arrival Time" and "Media Exit Time" in the light of encryption, 139 complex network coding, interleaving etc. Define how to measure 140 media time in wireless networks) Dedicated subsection and challenge: 141 virtualization 142 3. Define new terms wrt timestamps that help to differentiate 143 between software delays within a host. Ideally it should give 144 guidance and define terms that allow to differentiate between delays 145 (uncertainties) that a) are caused by host load, timer resolution, 146 system scheduling, etc. and b) the ones that originate when packets 147 wait in drivers because of network access policies or network 148 congestion. A "network (or IP) timestamp" can be useful in 149 (virtualized) environments it might make sense to define the term 150 "network timestamp" as "tcpdump timestamp of the host instance that 151 is located closest to the hardware". Hypervisor tcpdump timestamps 152 should be preferred over VM timestamps. 154 4. (optional) Protocol design considerations: (Security vs. 155 flexibility): adding timestamps into headers/payload protocol fields 156 at driver level (tcpdump equivalent) is difficult/impossible if link 157 is protected using SSL/TLS/IPsec. Meaningful: insert timestamp in 158 application space. 160 5. (probably not in IPPM) NTP is understood to operate sub-optimally 161 for time-transfer to virtual machines (VM) as guest-clients in some 162 hosts. What meachanisms can be employed to improve time accuracy and 163 stability when VMs intend to perform time measurement? 165 3. Definition and Use of Wire Time 167 [RFC2330] defines the following terms related to wire time (defined 168 in terms of an Internet host H observing an Internet link L at a 169 particular location): 171 o For a given packet P, the 'wire arrival time' of P at H on L is 172 the first time T at which any bit of P has appeared at H's 173 observational position on L 175 o For a given packet P, the 'wire exit time' of P at H on L is the 176 first time T at which all the bits of P have appeared at H's 177 observational position on L. 179 However, wireless LAN and cellular networks are essential components 180 of today's Internet. This memo proposes to replace the term "wire 181 time" by the equivalent term "media time" and provides additional 182 guidance for wireless network measurements. 184 This definition of media time raises one additional challenge: how 185 can "media arrival time" and "media exit time" be defined for 186 wireless networks. Aligning with existing physical-layer standards 187 of other standardization organizations like the 3GPP, this memo 188 recommends the antenna connector of the Host(?) to be used for 189 measuring media time in wireless networks. 191 3.1. Virtualization 193 Virtualization adds additional level of uncertainty for timestamps: 194 VM application, VM tcpdump, Hypervisor tcpdump. What about wire time 195 for virtual network interfaces? Should it be bound to the related 196 physical interface or to the hypervisor/virtual interface? 198 There was some flexibility in the original mention of Host Time. 199 Virtualization adds more layers where host timestamps could b e 200 applied or derived, and the specification requires its own framework: 202 Host 203 |'''''''''''| 204 | | 205 | |'''''''| | 206 | | UDP | | H 207 | :-------: | o 208 | | IP | | s 209 | :-------: | t 210 | | Link | | 211 | :.......: | T 212 | | NIC | | i 213 | `.......' | m 214 |____||_____| e 215 || 216 || Wire Time 217 || 218 :: 220 4. Definition and Use of Host Time 222 Section 3 of [RFC2330] includes an occurrence of the term "host time" 223 but does not define it. Some metric definitions like one-way delay 224 in section 3.7.2 of [RFC2679] or round-trip delay in section 2.7 of 225 [RFC2681] discuss the consequences of differences between wire time 226 and host time. Common to these metric definitions is the request to 227 report errors and uncertainties resulting from the difference between 228 host time and wire time. 230 However, the evolution of network technology has decreased the 231 network delay substantially. Today, the delay of wireless and wired 232 LAN links are in the same order of magnitude as the uncertainty of 233 host time, the difference between timestamps at application layer and 234 the ones in kernel space being substantial as pointed out in [MCDC]). 235 Instead of accepting this uncertainty as an inherent part of 236 measurements, this memo recommends to accurately define the location 237 within the stack where timestamps are assigned to a packet. 239 4.1. Virtualization 241 Virtualization extends the concept of host time beyond earlier 242 limits. For instance packet captures (tcpdump) in virtualized 243 environments are possible at VM-level and at hypervisor level. 244 Therefore, the definition of "Host Time" spans a broad range of 245 timestamps, encompassing anything from timestamps acquired by an 246 application running on top of a VM, down to tcpdump timestamps 247 acquired within the VM or hypervisor network stack. 249 Host 250 |'''''''''''| 251 Host | | V 252 |'''''''''''| | |'''''''| | i 253 | | | | UDP | | r 254 | |'''''''| | | :-------: | t 255 | | UDP | | H | | IP | | u 256 | :-------: | o | :-------: | a 257 | | IP | | s | | Link | | l 258 | :-------: | t | :-------: | 259 | | Link | | | |OverLay| | M 260 | :.......: | T | :-------: |***** 261 | | NIC | | i | |FrontEnd | H 262 | `.......' | m | :-------: | Y 263 |____||_____| e | I/O | P 264 || | Ring | E 265 || Wire Time | | R 266 || | :-------: | - 267 :: |BackEnd| V 268 | :-------: | i 269 | |Native | | s 270 | : NIC : | o 271 | |Driver | | r 272 | :-------: | 273 |___________| 274 || 275 || Wire Time 276 Xen VM based on: || 277 http://www.cc.gatech.edu/~lingliu/papers/2012/YiRen-CollaborateCom2012.pdf 279 5. Encryption 281 6. Security Considerations 283 The security considerations that apply to any active measurement of 284 live paths are relevant here as well. See [RFC4656] and [RFC5357]. 286 When considering privacy of those involved in measurement or those 287 whose traffic is measured, the sensitive information available to 288 potential observers is greatly reduced when using active techniques 289 which are within this scope of work. Passive observations of user 290 traffic for measurement purposes raise many privacy issues. We refer 291 the reader to the privacy considerations described in the Large Scale 292 Measurement of Broadband Performance (LMAP) Framework [RFC7594], 293 which covers active and passive techniques. 295 7. IANA Considerations 297 This memo makes no requests of IANA. 299 8. Acknowledgements 301 The authors thank ... 303 9. References 305 9.1. Normative References 307 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 308 DOI 10.17487/RFC0791, September 1981, 309 . 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, 313 DOI 10.17487/RFC2119, March 1997, 314 . 316 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 317 "Framework for IP Performance Metrics", RFC 2330, 318 DOI 10.17487/RFC2330, May 1998, 319 . 321 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 322 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 323 December 1998, . 325 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 326 RFC 2675, DOI 10.17487/RFC2675, August 1999, 327 . 329 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 330 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 331 September 1999, . 333 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 334 Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, 335 September 1999, . 337 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 338 Values In the Internet Protocol and Related Headers", 339 BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000, 340 . 342 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 343 of Explicit Congestion Notification (ECN) to IP", 344 RFC 3168, DOI 10.17487/RFC3168, September 2001, 345 . 347 [RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 348 Algorithm and Its Use with IPsec", RFC 4494, 349 DOI 10.17487/RFC4494, June 2006, 350 . 352 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 353 Zekauskas, "A One-way Active Measurement Protocol 354 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 355 . 357 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 358 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 359 RFC 5357, DOI 10.17487/RFC5357, October 2008, 360 . 362 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 363 Metrics (IPPM): Spatial and Multicast", RFC 5644, 364 DOI 10.17487/RFC5644, October 2009, 365 . 367 [RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for 368 Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 369 2010, . 371 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 372 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 373 DOI 10.17487/RFC6282, September 2011, 374 . 376 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 377 "IPv6 Flow Label Specification", RFC 6437, 378 DOI 10.17487/RFC6437, November 2011, 379 . 381 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 382 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 383 RFC 6564, DOI 10.17487/RFC6564, April 2012, 384 . 386 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 387 of IPv6 Extension Headers", RFC 7045, 388 DOI 10.17487/RFC7045, December 2013, 389 . 391 [RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling 392 Framework for IP Performance Metrics (IPPM)", RFC 7312, 393 DOI 10.17487/RFC7312, August 2014, 394 . 396 9.2. Informative References 398 [MCDC] Fabini, J. and T. Zseby, "M2M communication delay 399 challenges: Application and measurement perspectives", 400 IEEE International Instrumentation and Measurement 401 Technology Conference (I2MTC 2015) doi: 402 10.1109/I2MTC.2015.7151564, May 2015. 404 [RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 405 Aitken, P., and A. Akhter, "A Framework for Large-Scale 406 Measurement of Broadband Performance (LMAP)", RFC 7594, 407 DOI 10.17487/RFC7594, September 2015, 408 . 410 Authors' Addresses 412 Joachim Fabini 413 TU Wien 414 Gusshausstrasse 25/E389 415 Vienna 1040 416 Austria 418 Phone: +43 1 58801 38813 419 Fax: +43 1 58801 38898 420 Email: Joachim.Fabini@tuwien.ac.at 421 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 422 Al Morton 423 AT&T Labs 424 200 Laurel Avenue South 425 Middletown, NJ 07748 426 USA 428 Phone: +1 732 420 1571 429 Fax: +1 732 368 1192 430 Email: acmorton@att.com 431 URI: http://home.comcast.net/~acmacm/