Internet DRAFT - draft-fabini-ippm-2330-time
draft-fabini-ippm-2330-time
Network Working Group J. Fabini
Internet-Draft TU Wien
Updates: 2330 (if approved) A. Morton
Intended status: Informational AT&T Labs
Expires: April 16, 2016 October 14, 2015
Updates for IPPM's Framework: Timestamping and Use Cases
draft-fabini-ippm-2330-time-00
Abstract
Quality and accuracy of measurements depend on the selection of
appropriate locations and timers for timestamp acquisition. This
memo updates the IP Performance Metrics (IPPM) Framework RFC 2330
with new considerations on timers, timestamps and time-related
definitions with particular focus on wireless networks and
virtualized hosts.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fabini & Morton Expires April 16, 2016 [Page 1]
Internet-Draft IPPM Time October 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition and Use of Wire Time . . . . . . . . . . . . . . . 4
3.1. Virtualization . . . . . . . . . . . . . . . . . . . . . 5
4. Definition and Use of Host Time . . . . . . . . . . . . . . . 5
4.1. Virtualization . . . . . . . . . . . . . . . . . . . . . 6
5. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
The IETF IP Performance Metrics (IPPM) working group first created a
framework for metric development in [RFC2330]. This framework has
stood the test of time and enabled development of many fundamental
metrics. It has been updated in the area of metric composition
[RFC5835], and in several areas related to active stream measurement
of modern networks with reactive properties [RFC7312].
Time is fundamental to measurements. The IPPM framework [RFC2330]
includes a comprehensive terminology, definition and discussion of
time- and clock-related concepts. But network technology has evolved
since 1998. First, host computing performance and software
complexity have increased while network delays have decreased. These
advances enable development of new concepts like host virtualization
in cloud computing, and network function virtualization. One side-
effect of these technologies is that packets spend more and more time
in software, their propagation through the stack being biased by a
series of uncertainty factors like buffers, queues and operating
system scheduling. Measurements can acquire timestamps in various
locations within the host's software stack, causing potentially
Fabini & Morton Expires April 16, 2016 [Page 2]
Internet-Draft IPPM Time October 2015
significant variances in timestamp values [MCDC]. This is a
consequence of just one alternative that the IPPM framework [RFC2330]
defines for these timestamps: host time. This memo seeks to update
this aspect of the IPPM framework by discussing alternatives and
proposing generic solutions that can be referenced by metric
definitions.
Second, the IPPM framework was approved one year before the release
of the first IEEE 802.11 series standard. This was a time when the
data communication landscape was dominated by wired communication
technologies and wireless data communications were in their infancy.
This fact originated IPPM definitions like host time or wire time.
Today, after more than one decade and half, wireless IEEE 802.11
networks and cellular packet-switched data technologies like High-
Speed Packet Access (HSPA) and Long Term Evolution (LTE) are
responsible for an essential part of the worldwide Internet access
traffic. This raises the question, how the IPPM framework concept of
wire time can be mapped to wireless networks.
This memo revisits and updates time-related IPPM framework [RFC2330]
definitions like host time and wire time in the light of
technological advances.
2. Scope
The purpose of this memo is to update the IPPM metrics framework
[RFC2330] with respect to timestamps and virtualization. Concepts
like "host time" or "wire time" must be revisited to be applicable
for wireless networks and virtualized environments.
The scope is to update key sections of [RFC2330] ...
Potential Topics (Draft outline for discussion):
- Fundamentals
1. Host Time (further develop the definition as mentioned but not
defined in RFC2330. Explain variants, propose examples and
guidance). Dedicated subsection and challenge: virtualization.
2. Wire Time (rename "Wire Time" to "Medium Time" or "Media Time" to
account for wireless networks; revisit the definition of "Media
Arrival Time" and "Media Exit Time" in the light of encryption,
complex network coding, interleaving etc. Define how to measure
media time in wireless networks) Dedicated subsection and challenge:
virtualization
Fabini & Morton Expires April 16, 2016 [Page 3]
Internet-Draft IPPM Time October 2015
3. Define new terms wrt timestamps that help to differentiate
between software delays within a host. Ideally it should give
guidance and define terms that allow to differentiate between delays
(uncertainties) that a) are caused by host load, timer resolution,
system scheduling, etc. and b) the ones that originate when packets
wait in drivers because of network access policies or network
congestion. A "network (or IP) timestamp" can be useful in
(virtualized) environments it might make sense to define the term
"network timestamp" as "tcpdump timestamp of the host instance that
is located closest to the hardware". Hypervisor tcpdump timestamps
should be preferred over VM timestamps.
4. (optional) Protocol design considerations: (Security vs.
flexibility): adding timestamps into headers/payload protocol fields
at driver level (tcpdump equivalent) is difficult/impossible if link
is protected using SSL/TLS/IPsec. Meaningful: insert timestamp in
application space.
5. (probably not in IPPM) NTP is understood to operate sub-optimally
for time-transfer to virtual machines (VM) as guest-clients in some
hosts. What meachanisms can be employed to improve time accuracy and
stability when VMs intend to perform time measurement?
3. Definition and Use of Wire Time
[RFC2330] defines the following terms related to wire time (defined
in terms of an Internet host H observing an Internet link L at a
particular location):
o For a given packet P, the 'wire arrival time' of P at H on L is
the first time T at which any bit of P has appeared at H's
observational position on L
o For a given packet P, the 'wire exit time' of P at H on L is the
first time T at which all the bits of P have appeared at H's
observational position on L.
However, wireless LAN and cellular networks are essential components
of today's Internet. This memo proposes to replace the term "wire
time" by the equivalent term "media time" and provides additional
guidance for wireless network measurements.
This definition of media time raises one additional challenge: how
can "media arrival time" and "media exit time" be defined for
wireless networks. Aligning with existing physical-layer standards
of other standardization organizations like the 3GPP, this memo
recommends the antenna connector of the Host(?) to be used for
measuring media time in wireless networks.
Fabini & Morton Expires April 16, 2016 [Page 4]
Internet-Draft IPPM Time October 2015
3.1. Virtualization
Virtualization adds additional level of uncertainty for timestamps:
VM application, VM tcpdump, Hypervisor tcpdump. What about wire time
for virtual network interfaces? Should it be bound to the related
physical interface or to the hypervisor/virtual interface?
There was some flexibility in the original mention of Host Time.
Virtualization adds more layers where host timestamps could b e
applied or derived, and the specification requires its own framework:
Host
|'''''''''''|
| |
| |'''''''| |
| | UDP | | H
| :-------: | o
| | IP | | s
| :-------: | t
| | Link | |
| :.......: | T
| | NIC | | i
| `.......' | m
|____||_____| e
||
|| Wire Time
||
::
4. Definition and Use of Host Time
Section 3 of [RFC2330] includes an occurrence of the term "host time"
but does not define it. Some metric definitions like one-way delay
in section 3.7.2 of [RFC2679] or round-trip delay in section 2.7 of
[RFC2681] discuss the consequences of differences between wire time
and host time. Common to these metric definitions is the request to
report errors and uncertainties resulting from the difference between
host time and wire time.
However, the evolution of network technology has decreased the
network delay substantially. Today, the delay of wireless and wired
LAN links are in the same order of magnitude as the uncertainty of
host time, the difference between timestamps at application layer and
the ones in kernel space being substantial as pointed out in [MCDC]).
Instead of accepting this uncertainty as an inherent part of
measurements, this memo recommends to accurately define the location
within the stack where timestamps are assigned to a packet.
Fabini & Morton Expires April 16, 2016 [Page 5]
Internet-Draft IPPM Time October 2015
4.1. Virtualization
Virtualization extends the concept of host time beyond earlier
limits. For instance packet captures (tcpdump) in virtualized
environments are possible at VM-level and at hypervisor level.
Therefore, the definition of "Host Time" spans a broad range of
timestamps, encompassing anything from timestamps acquired by an
application running on top of a VM, down to tcpdump timestamps
acquired within the VM or hypervisor network stack.
Host
|'''''''''''|
Host | | V
|'''''''''''| | |'''''''| | i
| | | | UDP | | r
| |'''''''| | | :-------: | t
| | UDP | | H | | IP | | u
| :-------: | o | :-------: | a
| | IP | | s | | Link | | l
| :-------: | t | :-------: |
| | Link | | | |OverLay| | M
| :.......: | T | :-------: |*****
| | NIC | | i | |FrontEnd | H
| `.......' | m | :-------: | Y
|____||_____| e | I/O | P
|| | Ring | E
|| Wire Time | | R
|| | :-------: | -
:: |BackEnd| V
| :-------: | i
| |Native | | s
| : NIC : | o
| |Driver | | r
| :-------: |
|___________|
||
|| Wire Time
Xen VM based on: ||
http://www.cc.gatech.edu/~lingliu/papers/2012/YiRen-CollaborateCom2012.pdf
5. Encryption
6. Security Considerations
The security considerations that apply to any active measurement of
live paths are relevant here as well. See [RFC4656] and [RFC5357].
Fabini & Morton Expires April 16, 2016 [Page 6]
Internet-Draft IPPM Time October 2015
When considering privacy of those involved in measurement or those
whose traffic is measured, the sensitive information available to
potential observers is greatly reduced when using active techniques
which are within this scope of work. Passive observations of user
traffic for measurement purposes raise many privacy issues. We refer
the reader to the privacy considerations described in the Large Scale
Measurement of Broadband Performance (LMAP) Framework [RFC7594],
which covers active and passive techniques.
7. IANA Considerations
This memo makes no requests of IANA.
8. Acknowledgements
The authors thank ...
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
DOI 10.17487/RFC2330, May 1998,
<http://www.rfc-editor.org/info/rfc2330>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, DOI 10.17487/RFC2675, August 1999,
<http://www.rfc-editor.org/info/rfc2675>.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
September 1999, <http://www.rfc-editor.org/info/rfc2679>.
Fabini & Morton Expires April 16, 2016 [Page 7]
Internet-Draft IPPM Time October 2015
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <http://www.rfc-editor.org/info/rfc2681>.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, DOI 10.17487/RFC2780, March 2000,
<http://www.rfc-editor.org/info/rfc2780>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC4494] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494,
DOI 10.17487/RFC4494, June 2006,
<http://www.rfc-editor.org/info/rfc4494>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance
Metrics (IPPM): Spatial and Multicast", RFC 5644,
DOI 10.17487/RFC5644, October 2009,
<http://www.rfc-editor.org/info/rfc5644>.
[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for
Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April
2010, <http://www.rfc-editor.org/info/rfc5835>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
Fabini & Morton Expires April 16, 2016 [Page 8]
Internet-Draft IPPM Time October 2015
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<http://www.rfc-editor.org/info/rfc6564>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
Framework for IP Performance Metrics (IPPM)", RFC 7312,
DOI 10.17487/RFC7312, August 2014,
<http://www.rfc-editor.org/info/rfc7312>.
9.2. Informative References
[MCDC] Fabini, J. and T. Zseby, "M2M communication delay
challenges: Application and measurement perspectives",
IEEE International Instrumentation and Measurement
Technology Conference (I2MTC 2015) doi:
10.1109/I2MTC.2015.7151564, May 2015.
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T.,
Aitken, P., and A. Akhter, "A Framework for Large-Scale
Measurement of Broadband Performance (LMAP)", RFC 7594,
DOI 10.17487/RFC7594, September 2015,
<http://www.rfc-editor.org/info/rfc7594>.
Authors' Addresses
Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
Vienna 1040
Austria
Phone: +43 1 58801 38813
Fax: +43 1 58801 38898
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Fabini & Morton Expires April 16, 2016 [Page 9]
Internet-Draft IPPM Time October 2015
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ 07748
USA
Phone: +1 732 420 1571
Fax: +1 732 368 1192
Email: acmorton@att.com
URI: http://home.comcast.net/~acmacm/
Fabini & Morton Expires April 16, 2016 [Page 10]
