Skip to main content

One-way Delay Measurement Based on Reference Delay
draft-li-ippm-ref-delay-measurement-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yang Li , Tao Sun , Hongwei Yang , Danyang Chen
Last updated 2021-02-22
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-li-ippm-ref-delay-measurement-00
Network Working Group                                              Y. Li
Internet-Draft                                                    T. Sun
Intended status: Informational                                   H. Yang
Expires: August 26, 2021                                         D. Chen
                                                            China Mobile
                                                       February 22, 2021

           One-way Delay Measurement Based on Reference Delay
                 draft-li-ippm-ref-delay-measurement-00

Abstract

   The end-to-end network one-way delay is an important performance
   indicator of the arising 5G network.  One type of existing methods
   requires the end-to-end deployment of accurate clock synchronization
   mechanism, such as PTP or GPS, which results in relatively high
   deployment cost.  Another type of existing methods uses round-trip
   delay measurements to estimate the one-way delay.  However, since the
   delay of the downlink and uplink of the 5G network may be asymmetric,
   the accuracy is relatively low.  This document introduces a method to
   accurately measure end-to-end network one-way delay using reference
   delay without deploying clock synchronization.

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 https://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 August 26, 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Li, et al.               Expires August 26, 2021                [Page 1]
Internet-Draft            Network Working Group            February 2021

   (https://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.  Conventions Used in This Document . . . . . . . . . . . . . .   4
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   3.  The method of One-way Delay Measurement Based on Reference
       Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  One-way Delay Measurement Method  . . . . . . . . . . . .   5
     3.2.  Packet and Measurement Header Format  . . . . . . . . . .   7
   4.  Acquisition of Reference Delay  . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   With the gradual promotion of new-generation network technologies
   (such as 5G networks) and their application in various industries,
   SLA guarantees for network quality become more and more important.
   For example, different 5G services have different requirements for
   network performance indicators such as delay, jitter, packet loss,
   and bandwidth.  Among them, the 5G network delay is defined as end-
   to-end one-way delay of the network.  Real-time and accurate
   measurement of the end-to-end one-way delay is very important for the
   SLA guarantee of network services, and has become an urgent and
   important requirement.

   A common scenario for end-to-end one-way delay measurement, such as a
   5G network HD video surveillance service scenario, is shown in figure
   1.  One end of the network is a high-definition surveillance camera,
   as shown in the wireless access side on the left in figure 1, and the
   other end of the network is a video server.  The end-to-end one-way
   delay measurement of the above-mentioned network is the one-way delay
   from the surveillance camera to the video server, including wireless
   access network, optical transmission network, 5G core network, and IP
   data network.  The delay is the sum of T1, T2, T3 and T4 as shown in
   figure 1.

Li, et al.               Expires August 26, 2021                [Page 2]
Internet-Draft            Network Working Group            February 2021

              +--------+   +-------+   +-------+   +-------+
   +------+   |Wireless|   |Optical|   |5G Core|   |  IP   |   +------+
   |Camera+<->+ Access +<->+ Trans +<->+Network+<->+ Data  +<->+Server|
   +------+   |Network |   |Network|   |       |   |Network|   +------+
              +--------+   +-------+   +-------+   +-------+

          |<---- T1 ---->|<--- T2 -->|<--- T3 -->|<--- T4 ---->|

             Figure 1:A Scenario for End-to-end One-way Delay

   The existing one-way delay measurement solutions are divided into two
   categories.  The first type is a one-way delay measurement solution
   based on round-trip communication delay, such as TWAMP[RFC8186].  The
   second type of one-way delay measurement solution is based on
   accurate network time synchronization mechanism, such as NTP[RFC5905]
   or PTP[IEEE.1588.2008].

   The one-way delay measurement solution based on the round-trip delay
   requires the deployment of network measurement probes on the source
   end, namely the surveillance camera side, and the destination end,
   namely the server side.  The source sends the measurement packet; the
   destination reflects the received measurement packet; after the
   source receives the measurement packet reflected by the destination,
   the round-trip delay can be obtained.  By dividing the round-trip
   delay by two, the end-to-end one-way delay can be approximated.
   However, because the uplink delay and downlink delay of an end-to-end
   network (such as a 5G network) are not equal, the accuracy of the
   end-to-end one-way delay approximated by the round-trip communication
   delay is low.  It cannot meet the requirements for accurate end-to-
   end one-way delay measurement.

   The one-way delay measurement solution based on precise network time
   synchronization requires the deployment of an end-to-end time
   synchronization mechanism.  The current time synchronization accuracy
   based on the NTP protocol can only reach millisecond level, which
   cannot fully meet the measurement accuracy requirements, while the
   time synchronization accuracy based on the GPS module or the PTP
   protocol can meet the requirements.  On the basis of end-to-end time
   synchronization, the source sends a measurement packet with an
   accurate egress timestamp; when the destination receives the
   measurement packet, the accurate ingress timestamp is marked.  Since
   the source and destination have already performed end-to-end time
   synchronization, the ingress timestamp is subtracted from the egress
   timestamp to obtain the end-to-end one-way delay.  However, for GPS
   module-based time synchronization solutions, in actual deployment
   scenarios, many data centers are located underground or in rooms
   without GPS signals,so GPS clock information cannot be continuously
   obtained for time synchronization.  For time synchronization

Li, et al.               Expires August 26, 2021                [Page 3]
Internet-Draft            Network Working Group            February 2021

   solutions based on the PTP protocol, end-to-end deployment is
   required, which is to say, each device in the wireless access
   network, optical transmission network, 5G core network and IP data
   network must support the PTP protocol, which is unrealistic at the
   moment.  So the one-way delay measurement solution based on precise
   end-to-end time synchronization is expensive and difficult to be
   deployed.

   This document introduces a one-way delay measurement solution based
   on reference delay.  The end-to-end one-way delay of a reference
   packet with a stable delay is used as the reference delay, which is
   known in advance and has extremely low jitter.  For example, next
   generation networks are gradually supporting deterministic
   network[RFC8655] and end-to-end network slicing technologies, which
   are characterized by bounded end-to-end delay and extremely low
   jitter of transmitted packets, which are ideal for reference packets.
   We can use the reference delay provided by the reference packet to
   indirectly measure the one-way delay of other packet streams under
   measurement.

2.  Conventions Used in This Document

2.1.  Terminology

   NTP Network Time Protocol

   PTP Precision Time Protocol

   TWAMP Two-Way Active Measurement Protocol

   SLA Service Level Agreement

2.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14[RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  The method of One-way Delay Measurement Based on Reference Delay

   The end-to-end one-way delay of a reference packet with a stable
   delay in the network can be used as a reference delay, denoted as
   Dref, which is known in advance and has extremely low jitter.  This
   section will describe in detail the end-to-end one-way delay
   measurement method based on reference delay of the reference packet.
   Assume that the end-to-end one-way delay from the sender to the

Li, et al.               Expires August 26, 2021                [Page 4]
Internet-Draft            Network Working Group            February 2021

   receiver is measured, as shown in figure 2.  The intermediate network
   devices other than the sender and receiver are hidden in the figure.

          +------------+                   +------------+
          |            |   Clock Offset    |            |
          |   Sender   | +---------------> |  Receiver  |
          |            |                   |            |
          +------------+                   +------------+

   Reference  +-----+          Dref           +-----+
     Packet:  | Ts1 |  +------------------->  | Tr1 |
              +-----+                         +-----+

    Target    +-----+         Dtarget         +-----+
    Packet:   | Ts2 |  +------------------->  | Tr2 |
              +-----+                         +-----+

              Figure 2:Topology of One-way Delay Measurement

3.1.  One-way Delay Measurement Method

   The measurement steps are shown in figure 3, which describe the
   measurement steps at the sender side and receiver side respectively.
   For the sender side, a reference packet is sent.  In the first step,
   the sender gets ready to send a reference packet; in the second step,
   the sender marks an egress timestamp Ts1 for the reference packet; in
   the third step, the sender encapsulates the egress timestamp of the
   reference packet in the measurement header of the reference packet;
   in the fourth step, the sender sends the reference packet.  For the
   target packet, the sender side procedures are the same,we omit it for
   simplicity.  The sending time of the target packet is according to
   the traffic model of real applications.  On the other hand, the
   sender can send the reference packet according to a fixed frequency
   or adjust the sending frequency according to the link usage rate, so
   that the target packet can always find a nearby reference packet to
   make sure that the sending time interval between the reference packet
   and the target packet is small.

   For the reference packet, the processing steps at the receiver are
   shown in figure 3.  In the first step, the reference packet arrives
   at the receiver, and the receiver receives the reference packet; in
   the second step, the receiver timestamps the reference packet at the
   entrance, which is denoted as Tr1; in the third step, the receiver
   decapsulates the measurement header of the reference packet to obtain
   the sender side timestamp Ts1; in the fourth step, the receiver
   records the timestamp information of Ts1 and Tr1; in the fifth step,
   the receiver uses the source/destination pair obtained by
   decapsulation in the third step as the search key, queries the

Li, et al.               Expires August 26, 2021                [Page 5]
Internet-Draft            Network Working Group            February 2021

   reference delay table and records the reference delay search result,
   denoted as Dref.

   For the target packet, the processing steps at the receiver are also
   shown in figure 3.  In the first step, the target packet arrives at
   the receiver, and the receiver receives the target packet; in the
   second step, the receiver timestamps the target packet at the
   entrance, which is denoted as Tr2; in the third step, the receiver
   decapsulates the measurement header of the target packet to obtain
   the sender side timestamp Ts2; in the fourth step, the receiver
   records the timestamp information of Ts2 and Tr2; in the fifth step,
   the receiver calculates the target one-way delay, which we want to
   measure, according to the recorded timestamp information Ts1, Ts2,
   Tr1, Tr2 and reference delay information Dref.  The target one-way
   delay of the target packet is recorded as Dtarget.

 Sender Side Procedures for both Reference and Target Packet:

 +-------+   +------------+   +-------------+   +-------+
 |Sender |   |Sender Side |   |Sender Side  |   |Sending|
 |Ready  +-->+Timestamping+-->+Encapsulation+-->+ Packet|
 |       |   |            |   |             |   |       |
 +-------+   +------------+   +-------------+   +-------+

 Receiver Side Procedures for Reference Packet:

 +---------+  +-------------+  +-------------+  +---------+  +---------+
 |Reference|  |Receiver Side|  |Receiver Side|  |Timestamp|  |Query for|
 |Packet   +->+Timestamping +->+Decapsulation+->+Recorded +->+Reference|
 |Arrival  |  |             |  |             |  |         |  |  Delay  |
 +---------+  +-------------+  +-------------+  +---------+  +---------+

 Receiver Side Procedures for Target Packet:

 +-------+  +-------------+  +-------------+  +---------+  +-----------+
 | Target|  |Receiver Side|  |Receiver Side|  |Timestamp|  |  One-way  |
 | Packet+->+Timestamping +->+Decapsulation+->+Recorded +->+   Delay   |
 |Arrival|  |             |  |             |  |         |  |Calculation|
 +-------+  +-------------+  +-------------+  +---------+  +-----------+

     Figure 3: Measurement steps for Sender and Receiver Respectively

   Now we describe the fifth step of the receiver procedures for the
   target packet in figure 3, that is, calculating the one-way delay
   Dtarget of the target packet based on the recorded timestamp
   information Ts1, Ts2, Tr1, Tr2 and the reference delay information
   Dref.  The calculation method is the core of this solution.  For the

Li, et al.               Expires August 26, 2021                [Page 6]
Internet-Draft            Network Working Group            February 2021

   reference packet, leveraging the receiver timestamp minus the sender
   timestamp, we can get Equation 1.

   Equation 1: Tr1 - Ts1 = Dref + Offset1

   where Offset1 is the time offset between the sender and the receiver
   when the reference packet transmission occurs.  Similarly, for the
   target packet, we can get Equation 2 using the same method.

   Equation 2: Tr2 - Ts2 = Dtarget + Offset2

   where Offset2 is the time offset between the sender and the receiver
   when the target packet transmission occurs.  Assuming that the
   sending time interval between the reference packet and the target
   packet is very small, we can get that Offset1 = Offset2.  By
   (Equation 2 - Equation 1), we can get Equation 3.

   Equation 3: Dtarget = (Tr2 + Ts1) - (Tr1 + Ts2) + Dref

   So the one-way delay of the target packet can be calculated by
   Equation 3.

3.2.  Packet and Measurement Header Format

   The sender encapsulates the timestamp information and sender-receiver
   pair information in the measurement header of the sent packet, as
   shown in figure 4.  The position of measurement header is in the
   option field of the TCP protocol header.  Detailed measurement header
   format is shown in figure 5.  The Kind value can be 253 or 254, and
   the Length value is 8, which is in accordance with TCP
   option[RFC4727].  The sender ID is one octet, and the receiver ID is
   also one octet.  The sender side timestamp is 4 octets, which can
   store accurate timestamp information.

Li, et al.               Expires August 26, 2021                [Page 7]
Internet-Draft            Network Working Group            February 2021

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                    Ethernet header (14 octets)                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       IP header (20 octets)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       TCP header (20 octets)                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Measurement Header in TCP option (8 octets)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Data                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Format of Reference or Target Packet

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Kind     |    Length     |  Sender ID    | Receiver ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Sender Side Timestamp (4 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 5: Detailed Measurement Header Format

4.  Acquisition of Reference Delay

   The end-to-end one-way delay includes three parts, namely the
   transmission delay, the internal processing delay of the network
   devices, and the internal queueing delay of the network devices.
   Among them, fixed parts of the delay include transmission delay and
   internal processing delay.  The transmission delay is related to
   transmission distance and transmission media.  For example, in
   optical fiber, it is about 5ns per meter.  With transmission path and
   media determined, it is basically a fixed value.  The internal
   processing delay of a network device includes processing delay of the
   device's internal pipeline or processor and serial-to-parallel
   conversion delay of the interface, which is related to in/out port
   rate of the device, message length and forwarding behavior.  The
   magnitude of the internal processing delay is at microsecond level,
   and it is basically a fixed value related to the chip design

Li, et al.               Expires August 26, 2021                [Page 8]
Internet-Draft            Network Working Group            February 2021

   specifications of a particular network device.  Variable part of the
   delay is the internal queueing delay.  The queueing delay of the
   device internal buffer is related to the queue depth, queue
   scheduling algorithm, message priority and message length.  For each
   device along the end-to-end path, the queueing delay can reach
   microsecond or even millisecond level, depending on values of the
   above parameters and network congestion state.

   With the continuous development of networking technologies and
   application requirements, a series of new network technologies have
   emerged which can guarantee bounded end-to-end delay and ultra small
   jitter.  For example, deterministic network[RFC8655], by leveraging
   novel scheduling algorithms and packet priority settings, can
   stabilize queuing delay of network device on the end-to-end path.  As
   a result, the end-to-end one-way delay is extremely low and bounded.
   So packets transmitted by a deterministic network with delay
   guarantee can be used as reference packets, and their end-to-end one-
   way delay can be used as reference delays.  The acquisition method of
   reference delay is not limited to the above method based on
   deterministic network technology.

5.  Security Considerations

   TBD.

6.  IANA Considerations

   TBD.

7.  Normative References

   [IEEE.1588.2008]
              IEEE, "IEEE Standard for a Precision Clock Synchronization
              Protocol for Networked Measurement and Control Systems",
              July 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727,
              DOI 10.17487/RFC4727, November 2006,
              <https://www.rfc-editor.org/info/rfc4727>.

Li, et al.               Expires August 26, 2021                [Page 9]
Internet-Draft            Network Working Group            February 2021

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8186]  Mirsky, G. and I. Meilik, "Support of the IEEE 1588
              Timestamp Format in a Two-Way Active Measurement Protocol
              (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017,
              <https://www.rfc-editor.org/info/rfc8186>.

   [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,
              "Deterministic Networking Architecture", RFC 8655,
              DOI 10.17487/RFC8655, October 2019,
              <https://www.rfc-editor.org/info/rfc8655>.

Authors' Addresses

   Yang Li
   China Mobile
   Beijing  100053
   China

   Email: liyangzn@chinamobile.com

   Tao Sun
   China Mobile
   Beijing  100053
   China

   Email: suntao@chinamobile.com

   Hongwei Yang
   China Mobile
   Beijing  100053
   China

   Email: yanghongwei@chinamobile.com

Li, et al.               Expires August 26, 2021               [Page 10]
Internet-Draft            Network Working Group            February 2021

   Danyang Chen
   China Mobile
   Beijing  100053
   China

   Email: chendanyang@chinamobile.com

Li, et al.               Expires August 26, 2021               [Page 11]