Network Working Group D. Dang, Ed.
Internet-Draft Huawei
Intended status: Informational March 4, 2019
Expires: September 5, 2019

A One-Path Congestion Metric for IPPM


This memo defines a metric for one path congestion across Internet paths. The traditional mode evaluates network congestion based on the bandwidth utilization of the link. However, there is a lack of E2E path congestion that is truly service oriented. So A Path Congestion Metric is required.

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

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 September 5, 2019.

Copyright Notice

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

This memo defines a metric for a path congestion across Internet paths.

Currently there is no path congestion metric specified according to [RFC2330] framework, so the notions and conventions of Path Congestion will be introduced to extend RFC 2330.

1.1. 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.

1.2. Terminology & Abbreviations

1.3. Motivation

      Import Traffic to the path1
 bandwidth utilization     30%              30%     |       70%
     of the links                                   |

Figure 1: A Path

As Figure 1 is shown, there is a path between nodes A through B. Some traffic is imported into this path.

The congestion of this bottleneck link may be suspected to be caused by traffic coming from NodeN1, or coming from NodeN3. There is a lack of a measure of a path congestion. So A Path Congestion Metric is required to directly report the degree of path congestion, and is accurate.

2. A singleton definition of a Type-P-Path-Congestion Metric

2.1. Metric Name

Type-P-Path-Congestion use the Type-P convention as described in[RFC2330] .

2.2. Metric Parameters

2.3. Metric unit

The value of a Type-P-Path-Congestion is either a real number or an undefined (informally, infinite) number.

2.4. Definition

For a real number c,

In theory, this metric is larger while the path congestion is more serious.

2.5. Methodologies

As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, Differentiated Services (DS) Field[RFC2780].

The measurement methodology described in this section assumes the measurement and determination of Type-P-Path-Congestion in real-time.

Src     -------------------------------
         \   |     \   |                 
          \  |      \  |                   
           \ |       \ |                    
            \|        \|                     
Dst     -------------------------------
             I2       I3
            dpr = (I3 - I2) = (n*dpt + PathQueueDelay)                               

Figure 2: Measurement

As Figure 2 is shown, for a given Type-P, the methodology would proceed as follows:

Therefore, the overall solution needs to consider two methods of long-period measurement and short-period measurement. The two data from the two method can also be verified against each other if necessary.

2.6. Reporting the Metric

The calibration and context in which the metric is measured MUST be carefully considered and SHOULD always be reported along with metric results. We now present four items to consider: the Type-P of test packets, the threshold of infinite delay (if any), error calibration, and the path traversed by the test packets. This list is not exhaustive; any additional information that could be useful in interpreting applications of the metrics should also be reported (see [RFC6703] for extensive discussion of reporting considerations for different audiences)[RFC6703].

3. A Definition for Samples of Path Congestion

The goal of the sample definition is to make it possible to compute the statistics of sequences of Path Congestion measurements.

3.1. Metric Name


3.2. Metric Parameters

3.3. Metric Units

A sequence of four parameters whose elements are:

3.4. Definition

Given T0, Tf, and lambda, we compute a pseudorandom Poisson process beginning at or before T0, with average arrival rate lambda, and ending at or after Tf. Those time values greater than or equal to T0 and less than or equal to Tf are then selected.

At each of the selected times in this process, we obtain one value of Type-P-One-Path-Congestion. The value of the sample is the sequence made up of the resulting <time, c> pair . If there are no such pair, the sequence is of length zero and the sample is said to be empty.

3.5. Methodologies

The methodologies follow directly from:

3.6. Reporting the Metric

The calibration and context for the underlying singletons MUST be reported along with the stream.

4. Security Considerations

The path congestion metric has the same security properties as [RFC7679], and thus they inherit the security considerations of that document.

5. IANA Considerations


6. Acknowledgements


7. Normative References

[draft-dang-ippm-multi-paths-concurrent-measurement] "Multi-paths Concurrent Measurement"
[draft-ietf-spring-segment-routing-policy] "Segment Routing Policy Architecture"
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2330] "Framework for IP Performance Metrics"
[RFC2780] "RFC2780"
[RFC6703] "Reporting IP Network Performance Metrics: Different Points of View"
[RFC7348] "Virtual eXtensible Local Area Network (VXLAN)"
[RFC7679] "A One-Way Delay Metric for IP Performance Metrics (IPPM)"
[RFC7799] "Active and Passive Metrics and Methods (with Hybrid Types In-Between)"
[RFC8321] "Alternate-Marking Method for Passive and Hybrid Performance Monitoring"
[RFC8402] "Segment Routing Architecture"

Author's Address

Joanna Dang (editor) Huawei Beijing, China EMail: