A One-Path Congestion Metric for IPPM
draft-dang-ippm-congestion-03

Abstract

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 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 February 14, 2021.

Copyright Notice

Copyright (c) 2020 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 (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
• 1.1. Requirements Language
• 1.2. Terminology & Abbreviations
• 1.3. Motivation
• 2. A singleton definition of a Type-P-Path-Congestion Metric
• 2.1. Metric Name
• 2.2. Metric Parameters
• 2.3. Metric unit
• 2.4. Definition
• 2.5. Methodologies
• 2.6. Reporting the Metric
• 3. A Definition for Samples of Path Congestion
• 3.1. Metric Name
• 3.2. Metric Parameters
• 3.3. Metric Units
• 3.4. Definition
• 3.5. Methodologies
• 3.6. Reporting the Metric
• 4. Security Considerations
• 5. IANA Considerations
• 6. Acknowledgements
• 7. Normative References
• Authors' Addresses

1. Introduction

As we know, the current network has been already being in load balancing mode, however it is partially congested. To solve the problem of unbalanced network load[draft-liu-ican], Congestion of paths requires an assessment metric. 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 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.

• A 'singleton*' analytic metric, called Type-P-Path-Congestion, will be introduced to measure a single observation of A Path Congestion.
• Using this singleton metric, a 'sample*' called Type-P-One-Path-Congestion-Poisson-Stream is introduced to measure a sequence of singleton congestions sent at times taken from a Poisson process, defined in Section 11.1.1 of [RFC2330].

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

• Path Group
  • There are multiple channels between two nodes in the network. These channels may be equal-cost multi-path (ECMP) mode or unequal-cost multiple (UCMP) mode. In a real network, they might be one [draft-ietf-spring-segment-routing-policy] or [RFC7348] tunnel.
• Path
  • One path of the path group
• Path Congestion
  • A path is congested, indicating that the traffic of the path exceeds its own throughput. The result of path congestion is that the buffer of the nodes along the path cache traffic or the buffer along the way is insufficient to cause packet loss.

1.3. Motivation

      Import Traffic to the path1
                  \
                   \       
                   NodeA----------NodeN1----------NodeN2----------NodeB
 bandwidth utilization     30%              30%     |       70%
     of the links                                   |
                                                    |
                                                 NodeN3

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.

• At node A, the traffic is imported to path1.
• The bandwidth utilization of the links passed by path1 (Such as the link from Node A to NodeN1, the link from NodeN1 to NodeN2, the link from NodeN2 to NodeB) need to be checked. The bottleneck links identified where bandwidth utilization (70%) of the link between node N2 and NodeB exceeds the threshold (65%). The node where the bottleneck link is located is facing expansion and adapt some flows to another path, in order to ensure the service experiences.

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

• Src, the IP address of a host
• Dst, the IP address of a host
• dpt, transmission period of a measurement. For example, a measurement is trigged once dpt (such as 3.3 milliseconds)
• dt, interval from when Src initiates the measurement message to when Dst receives it.
• T, a time
• SrcCountp, the number of packets at source node in one dpt period. When Src sent the first bit of a Type-P packet to Dst, This parameter starts counting. And The counting is terminated after the end of the cycle. This data can be collected locally at the entry of the traffic import the path from Src to Dst.
• DstCountp, the number of packets at destination node in one dpt period. When Dst receive the first bit of a Type-P packet to Dst and the counting is terminated after the end of the cycle. Because the statistics of the counting is based on the path ,the related data can be collected locally based on the PathID what may be SR label list[RFC8402] or VXLAN ID[RFC7348].

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,

• the *Type-P-Path-Congestion* from Src to Dst at T is 0, which means that Src sent the first bit of a Type-P packet to Dst at wire time* T and that there is no path congestion to Dst.
• the *Type-P-One-way-Delay* from Src to Dst at T is greater than 0, which means that Src sent the first bit of a Type-P packet to Dst at wire time* T and there is the path congestion to Dst.

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.

        |---dpt---|---dpt---|---dpt---|
        I1
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:

• Start after time I1. At the Src host, select Src and Dst IP addresses, and form test packets of Type-P with these addresses according to a given technique (e.g., the Poisson sampling technique). The test packet can be used to dye traffic packets or generate a packet[RFC7799][RFC8321].
• At the Dst host, arrange to receive the packet.
• At the Src host, place a timestamp in the prepared Type-P packet, and send it towards Dst.
• If the packet arrives within a reasonable period of time, take a time stamp I2 as soon as possible upon the receipt of the packet. By subtracting the two time stamps, an estimate of 5.3. Type-P-One-way-Delay-Minimum[RFC7679] can be computed.
• If the packet meets the selection function criterion for the first packet, record this first Type-P-One-way-Delay-Minimum value.
  • Long-term measurement
    • At the Src host, the packets continue to be generated according to the given methodology. The Src host places a time stamp in the Type-P packet, and send it towards Dst. If the packet arrives within a reasonable period of time, the Dst host take a time stamp I3 as soon as possible upon the receipt of the packet.
  • Short-term measurement
    • After sending the first test message, the Src host sends a measurement message once dpt. Generating the Type-P packet stream is as above.
    • At the Dst host, when receiving the first measurement packet, it also sends a response packet to the Dst Host once dpt. The purpose of this is to improve measurement accuracy. Because when the packet is sent back the measured packet may not reach the Dst Host.
• So
  • In long term measurement, the congestion parameters are calculated as follows:
    • c = (( I3 - I2) / dpt ) -1
  • In long-term measurement, the congestion parameters are calculated as follows:
    • c = (SrcCountp / DstCountp)-1

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.

If a packet loss is detected on the path within a certain period, the congestion assessment will be terminated. The next measurement of the path can only be restarted after initialization.

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

Type-P-Path-Congestion-Poisson-stream

3.2. Metric Parameters

• Src, the IP address of a host
• Dst, the IP address of a host
• dpt[i], transmission period of a measurement. For example, a measurement is trigged once dpt (such as 3.3 milliseconds).
• dt[i], interval from when Src initiates the measurement message to when Dst receives it
• T0, a time
• Tf, a time
• lambda, a rate in reciprocal seconds
• SrcCountp[i], the number of packets at source node in one dpt period. When Src sent the first bit of a Type-P packet to Dst, This parameter starts counting. And The counting is terminated after the end of the cycle. This data can be collected locally at the entry of the traffic import the path from Src to Dst.
• DstCountp[i], the number of packets at destination node in one dpt period. When Dst receive the first bit of a Type-P packet to Dst and the counting is terminated after the end of the cycle. Because the statistics of the counting is based on the path ,the related data can be collected locally based on the PathID what may be SR label list[RFC8402] or VXLAN ID[RFC7348].

3.3. Metric Units

A sequence of four parameters whose elements are:

• T, a time, and
• c, either a zero (signifying no congestion transmission of the packet) or greater than a zero (signifying congestion).

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:

[draft-dang-ippm-multiple-path-measurement].

• The selection of specific times using the specified Poisson arrival process, and
• The methodologies discussion already given for the singleton Type-P-One-Path-Congestion metric.
  • Type-P-Path-Congestion[i] = ( ( SrcCountp[i]) / ( DstCountp[i]) ) -1

If applied in a load-sharing network, Multi-Path Concurrent Measurement for IPPM is recommended

If a packet loss is detected on the path within a certain period, the congestion assessment will be terminated. The next measurement of the path can only be restarted after initialization.

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[RFC2330].

5. IANA Considerations

TBD

6. Acknowledgements

TBD

7. Normative References

Authors' Addresses