<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-fabini-ippm-2330-time-00"
     ipr="trust200902" updates="2330">
  <front>
    <title abbrev="IPPM Time">Updates for IPPM's Framework: Timestamping and
    Use Cases</title>

    <author fullname="Joachim Fabini" initials="J." surname="Fabini">
      <organization>TU Wien</organization>

      <address>
        <postal>
          <street>Gusshausstrasse 25/E389</street>

          <city>Vienna</city>

          <region/>

          <code>1040</code>

          <country>Austria</country>
        </postal>

        <phone>+43 1 58801 38813</phone>

        <facsimile>+43 1 58801 38898</facsimile>

        <email>Joachim.Fabini@tuwien.ac.at</email>

        <uri>http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/</uri>
      </address>
    </author>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri>http://home.comcast.net/~acmacm/</uri>
      </address>
    </author>

    <date day="14" month="October" year="2015"/>

    <abstract>
      <t>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.</t>
    </abstract>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IETF IP Performance Metrics (IPPM) working group first created a
      framework for metric development in <xref target="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 <xref target="RFC5835"/>, and in several areas related to
      active stream measurement of modern networks with reactive properties
      <xref target="RFC7312"/>.</t>

      <t>Time is fundamental to measurements. The IPPM framework <xref
      target="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 significant
      variances in timestamp values <xref target="MCDC"/>. This is a
      consequence of just one alternative that the IPPM framework <xref
      target="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.</t>

      <t>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.</t>

      <t>This memo revisits and updates time-related IPPM framework <xref
      target="RFC2330"/> definitions like host time and wire time in the light
      of technological advances.</t>
    </section>

    <section title="Scope">
      <t>The purpose of this memo is to update the IPPM metrics framework
      <xref target="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.</t>

      <t>The scope is to update key sections of <xref target="RFC2330"/>
      ...</t>

      <t>Potential Topics (Draft outline for discussion):</t>

      <t>- Fundamentals</t>

      <t>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.</t>

      <t>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</t>

      <t>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.</t>

      <t>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.</t>

      <t>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?</t>
    </section>

    <section title="Definition and Use of Wire Time">
      <t><xref target="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):<list style="symbols">
          <t>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</t>

          <t>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.</t>
        </list></t>

      <t>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.</t>

      <t>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.</t>

      <t/>

      <section title="Virtualization">
        <t>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?</t>

        <t>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:</t>

        <t><figure>
            <artwork><![CDATA[
        Host
    |'''''''''''|
    |           |
    | |'''''''| |
    | |  UDP  | |  H
    | :-------: |  o
    | |   IP  | |  s
    | :-------: |  t
    | |  Link | |      
    | :.......: |  T
    | |  NIC  | |  i
    | `.......' |  m
    |____||_____|  e
         ||
         || Wire Time
         ||
         ::
]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Definition and Use of Host Time">
      <t>Section 3 of <xref target="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 <xref target="RFC2679"/> or round-trip
      delay in section 2.7 of <xref target="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.</t>

      <t>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 <xref
      target="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.</t>

      <section title="Virtualization">
        <t>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.</t>

        <t><figure>
            <artwork><![CDATA[
                                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

]]></artwork>
          </figure></t>
      </section>
    </section>

    <section title="Encryption">
      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>The security considerations that apply to any active measurement of
      live paths are relevant here as well. See <xref target="RFC4656"/> and
      <xref target="RFC5357"/>.</t>

      <t>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 <xref
      target="RFC7594"/>, which covers active and passive techniques.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo makes no requests of IANA.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors thank ...</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.0791'?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.2330'?>

      <?rfc include='reference.RFC.2460'?>

      <?rfc include='reference.RFC.2675'?>

      <?rfc include='reference.RFC.2679'?>

      <?rfc include='reference.RFC.2681'?>

      <?rfc include='reference.RFC.2780'?>

      <?rfc include='reference.RFC.3168'?>

      <?rfc include='reference.RFC.4494'?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.5644'?>

      <?rfc include='reference.RFC.5835'?>

      <?rfc include='reference.RFC.6282'?>

      <?rfc include='reference.RFC.6437'?>

      <?rfc include='reference.RFC.6564'?>

      <?rfc include='reference.RFC.7045'?>

      <?rfc include='reference.RFC.7312'?>
    </references>

    <references title="Informative References">
      <?rfc ?>

      <?rfc include='reference.RFC.7594'?>

      <reference anchor="MCDC">
        <front>
          <title>M2M communication delay challenges: Application and
          measurement perspectives</title>

          <author fullname="Joachim Fabini" initials="J.F." surname="Fabini">
            <!-- fullname="J.Fabini" -->

            <organization>TU Wien</organization>
          </author>

          <author fullname="Tanja Zseby" initials="T.Z." surname="Zseby">
            <!-- fullname="T.Zseby" -->

            <organization>TU Wien</organization>
          </author>

          <date day="11-14" month="May" year="2015"/>
        </front>

        <seriesInfo name="IEEE International Instrumentation and Measurement Technology Conference (I2MTC 2015)"
                    value="doi: 10.1109/I2MTC.2015.7151564"/>
      </reference>
    </references>
  </back>
</rfc>
