[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                       D. Dang, Ed.
Internet-Draft                                                    Huawei
Intended status: Informational                                   W. Wang
Expires: May 7, 2020                                       China Telecom
                                                                  W. LEE
                                                                   LG U+
                                                                  W. Yan
                                                                 Tencent
                                                        November 4, 2019


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

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 May 7, 2020.

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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Dang, et al.               Expires May 7, 2020                  [Page 1]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


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

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.





Dang, et al.               Expires May 7, 2020                  [Page 2]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   o  A 'singleton*' analytic metric, called Type-P-Path-Congestion,
      will be introduced to measure a single observation of A Path
      Congestion.

   o  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

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

   o  Path

      *  One path of the path group

   o  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



Dang, et al.               Expires May 7, 2020                  [Page 3]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


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

   o  At node A, the traffic is imported to path1.

   o  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

   o  Src, the IP address of a host

   o  Dst, the IP address of a host

   o  dpt, transmission period of a measurement.  For example, a
      measurement is trigged once dpt (such as 3.3 milliseconds)

   o  dt, interval from when Src initiates the measurement message to
      when Dst receives it.

   o  T, a time

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





Dang, et al.               Expires May 7, 2020                  [Page 4]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   o  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,

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

   o  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



Dang, et al.               Expires May 7, 2020                  [Page 5]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


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

   o  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].

   o  At the Dst host, arrange to receive the packet.

   o  At the Src host, place a timestamp in the prepared Type-P packet,
      and send it towards Dst.

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

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

   o  So

      *  In long term measurement, the congestion parameters are
         calculated as follows:




Dang, et al.               Expires May 7, 2020                  [Page 6]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


         +  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

   o  Src, the IP address of a host

   o  Dst, the IP address of a host

   o  dpt[i], transmission period of a measurement.  For example, a
      measurement is trigged once dpt (such as 3.3 milliseconds).

   o  dt[i], interval from when Src initiates the measurement message to
      when Dst receives it



Dang, et al.               Expires May 7, 2020                  [Page 7]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   o  T0, a time

   o  Tf, a time

   o  lambda, a rate in reciprocal seconds

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

   o  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:

   o  T, a time, and

   o  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:

   o  The selection of specific times using the specified Poisson
      arrival process, and





Dang, et al.               Expires May 7, 2020                  [Page 8]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   o  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[draft-dang-ippm-multiple-path-measurement].

   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

   [draft-dang-ippm-multiple-path-measurement]
              "Multi-Path Concurrent Measurement for IPPM",
              <https://tools.ietf.org/html/draft-dang-ippm-multiple-
              path-measurement-02>.

   [draft-ietf-spring-segment-routing-policy]
              "Segment Routing Policy Architecture",
              <https://tools.ietf.org/html/draft-ietf-spring-segment-
              routing-policy-02>.







Dang, et al.               Expires May 7, 2020                  [Page 9]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   [draft-liu-ican]
              "Instant Congestion Assessment Network (iCAN) for Traffic
              Engineering",
              <https://tools.ietf.org/html/draft-liu-ican-02>.

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

   [RFC2330]  "Framework for IP Performance Metrics",
              <https://tools.ietf.org/html/rfc2330>.

   [RFC2780]  "RFC2780", <https://tools.ietf.org/html/rfc2780>.

   [RFC6703]  "Reporting IP Network Performance Metrics: Different
              Points of View",
              <https://datatracker.ietf.org/doc/rfc6703/>.

   [RFC7348]  "Virtual eXtensible Local Area Network (VXLAN)",
              <https://datatracker.ietf.org/doc/rfc7348/>.

   [RFC7679]  "A One-Way Delay Metric for IP Performance Metrics
              (IPPM)", <https://tools.ietf.org/html/rfc7679>.

   [RFC7799]  "Active and Passive Metrics and Methods (with Hybrid Types
              In-Between)", <https://tools.ietf.org/html/rfc7799>.

   [RFC8321]  "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring",
              <https://tools.ietf.org/html/rfc8321>.

   [RFC8402]  "Segment Routing Architecture",
              <https://datatracker.ietf.org/doc/rfc8402/>.

Authors' Addresses

   Joanna Dang (editor)
   Huawei
   Beijing
   China

   Email: dangjuanna@huawei.com








Dang, et al.               Expires May 7, 2020                 [Page 10]


Internet-Draft      A Path Congestion Metric for IPPM      November 2019


   Jianglong
   China Telecom
   Beijing
   China

   Email: wangjl50@chinatelecom.cn


   Shinyoung
   LG U+
   Seoul
   Korea

   Email: leesy@lguplus.co.kr


   Hongbo
   Tencent
   Beijing
   China

   Email: nikyan@tencent.com





























Dang, et al.               Expires May 7, 2020                 [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/