Skip to main content

IP Packet loss rate measurement testing and problem statement
draft-fan-opsawg-packet-loss-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 Peng Fan , Lu Huang
Last updated 2013-02-18
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-fan-opsawg-packet-loss-00
Network Working Group                                             P. Fan
Internet-Draft                                                  L. Huang
Intended status: Informational                              China Mobile
Expires: August 22, 2013                               February 18, 2013

     IP Packet loss rate measurement testing and problem statement
                    draft-fan-opsawg-packet-loss-00

Abstract

   This document describes common methods for measuring packet loss rate
   and their effectiveness.  Issues encountered when using the methods
   and necessary considerations are also discussed and recommended.

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 August 22, 2013.

Copyright Notice

   Copyright (c) 2013 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
   (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.

Fan & Huang              Expires August 22, 2013                [Page 1]
Internet-Draft           Packet loss measurement           February 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Methods for packet loss rate measurement  . . . . . . . . . . . 3
   3.  Test on packet loss rate measurement  . . . . . . . . . . . . . 4
   4.  Measurement Issues  . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Considerations and recommendations  . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Fan & Huang              Expires August 22, 2013                [Page 2]
Internet-Draft           Packet loss measurement           February 2013

1.  Introduction

   IP packet loss rate is one of the important metrics that are
   frequently used to measure IP performance of a data path or link.  A
   general framework of IP performance metrics is provided in [RFC2330],
   including fundamental concepts definition and issues related to
   defining sound metrics and methodologies.  [RFC2680] and [RFC6673]
   further define metrics for one-way and round-trip packet loss.

   In practical network operation, a number of methods are used by
   network engineers to calculate packet loss rate, and one of the
   common ways is to use ping.  By checking ping statistics, people
   expect to get the idea of traffic transmission condition on the link.
   This document describes a test on packet loss rate measurement with
   multiple methods using routers from different vendors, followed by
   issues that should be taken into consideration during the
   measurement.  Causes analysis and processing mechanisms of routers
   are also covered.  It is expected that an operable measurement scheme
   with consistent testing results and equal treatment of network
   components can be reached.

2.  Methods for packet loss rate measurement

   This section describes frequently used methods nowadays for measuring
   packet loss rate.

   1.  Ping

   Ping (ICMP echo request/reply) is a useful tool to examine the
   connectivity and performance of the link between two nodes in the
   network.  The source node generates echo request packets with
   configured size, interval, count and other settings, and the
   destination node sends back an echo reply packet once it receives a
   request.  Then we count the packets sent out and received and get the
   round-trip packet loss rate on the link between source and
   destination.  This approach is clear and convenient, and is
   frequently used by engineers when packet loss rate is needed.

   In practical network operation, the ping testing can be initiated
   manually and directly on the node by engineers, for example through
   the command line interface (CLI) of a router, or activated indirectly
   by instructions, for example through SNMP messages sent from network
   management system.

   No matter through CLI or SNMP, ping testing can be conducted directly
   on the endpoint devices of the link to be tested, or other nodes as
   long as the request/reply packets pass through the link.  Those nodes

Fan & Huang              Expires August 22, 2013                [Page 3]
Internet-Draft           Packet loss measurement           February 2013

   are often referred to as probes, which can be a router or a PC
   server, directly connected or indirectly reachable to the endpoints.
   Usually the probes and paths to the endpoints are not supposed to be
   congested to avoid affecting the ping testing result.

   2.  Diagnosis toolset

   Routers have diagnosis toolsets to provide automatic detection of IP
   performance.  An example of the toolsets is Juniper's RPM.  By
   necessary configurations on the router, toolset support multi-service
   testing of multiple queues on an interface, including ICMP, TCP/UDP,
   and HTTP.  Packet loss rate can be measured with ICMP ping function
   of the toolset.  Routers send out ping packets automatically
   according to the configured parameters, so toolset is working in a
   similar way as ping method described above.

   3.  Interface statistics report

   Forwarding devices maintain statistics report of every interface.
   The report shows the detailed status of the interface as well as
   traffic information, including inbound and outbound speed and packet
   count.  For a typical router, traffic statistics show number of
   packets transmitted and discarded by an interface, and even on the
   basis of QoS queue, so the entire packet loss rate of a link or
   packet loss rates regarding different queues can be calculated.
   Traffic data on the report can be displayed through CLI or obtained
   using SNMP which allows automatic packet loss sampling.

3.  Test on packet loss rate measurement

   This section describes test result on packet loss rate measurement
   using different methods.  Test equipment covers routers from several
   vendors.  Results show the diverse outcome of the methods used, and
   the diverse responding mechanism of routers.

   Details are to be added.

4.  Measurement Issues

   This section describes issues encountered when measuring the packet
   loss rate of a link using different testing methods.

   1.  Ping

   Routers from every vendors have their unique processing procedure
   when sending and receiving ICMP packets, thus resulting in diverse

Fan & Huang              Expires August 22, 2013                [Page 4]
Internet-Draft           Packet loss measurement           February 2013

   ping packet loss rates, as described in the section above.  Errors
   exist using the ping method, and in some cases ping no longer
   reflects the actual packet loss rate correctly.  Relevant issues that
   have to be taken into account include:

   a) Forwarding class

   When sending ping packets locally, routers are likely to put the
   packets into a certain QoS queue/class although the DSCP field of
   ICMP packets is kept zero.  QoS queue of ping may be different than
   that of the traffic to be measured, and even ping packets sent by CLI
   commands and SNMP are in different queues by default.  Usually
   forwarding class can be adjusted by CLI or SNMP commands.

   b) Inner priority

   For some routers, although ping traffic and service traffic will not
   be treated differently by QoS, packets sent out by the router itself,
   for example ping packets, are put into an inner high priority while
   other forwarding service traffic into low priority.  These kinds of
   inner priority are valid within the interior of routers and do not
   rewrite the packets.  One of the purposes of using the priorities is
   to get the protocol packets (ping included) processed in prior.
   These priorities are set by vendor and may not be able to adjust, so
   in this case ping will not give the correct packet loss rate as ping
   packets are not processed and discarded together with service
   traffic.

   c) Ingress line card

   If the ping testing is conducted on a probe which is connected or IP
   reachable to the router, then the ping packets will be treated by the
   router as forwarding traffic, eliminating the queue and priority
   issues.  However, the location of interfaces through which ingress
   traffic is received matters when using some types of routers.  In
   this case, the router employs a polling schedule which allows traffic
   from different line cards or modules to get forwarding chance.  For a
   card with small volume of traffic, the chance will be little but not
   none.  So if ping packets come through a card different from the
   high-volume service traffic, the packets would probably get enough
   forwarding resources as ping traffic itself requires little
   bandwidth.  As a result, ping will suffer little from congestion and
   shows disaccord in packet loss rate.

   2.  Diagnosis toolset

   Although diagnosis toolsets provide integrated automatic testing
   method, the basic principle is still to ping from the router itself.

Fan & Huang              Expires August 22, 2013                [Page 5]
Internet-Draft           Packet loss measurement           February 2013

   So it is believed toolset method will experience the same issues
   about class and priority as local ping from router does.  We did not
   test diagnosis toolsets, and the discussion is left to be further
   continued.

   3.  Interface statistics report

   Interface statistic is the most direct and accurate way to get
   performance of an interface.  Packet loss rate calculated from
   traffic statistics is in accordance with the expected value.  By
   referring to statistics collected from the endpoint routers,
   bidirectional packet loss rate can easily be obtained.

   However, this approach requires access to routers, while in some
   scenarios it is difficult to do that.  For example, if we would like
   to know the inbound packet loss rate of the interconnection link to
   another service operator, we may have to rely on statistics provided
   by the peering router.  Normally, this information is not easily
   shared by interworking operators.

5.  Considerations and recommendations

   TBD.

6.  Security Considerations

   TBD.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Normative References

   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
              "Framework for IP Performance Metrics", RFC 2330,
              May 1998.

   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
              Packet Loss Metric for IPPM", RFC 2680, September 1999.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

Fan & Huang              Expires August 22, 2013                [Page 6]
Internet-Draft           Packet loss measurement           February 2013

   [RFC6673]  Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673,
              August 2012.

   [RFC792]   Postel, J., "Internet Control Message Protocol", RFC 792,
              September 1981.

Authors' Addresses

   Peng Fan
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing  100053
   P.R. China

   Email: fanpeng@chinamobile.com

   Lu Huang
   China Mobile
   32 Xuanwumen West Street, Xicheng District
   Beijing  100053
   P.R. China

   Email: huanglu@chinamobile.com

Fan & Huang              Expires August 22, 2013                [Page 7]