A One-Path Congestion
Metric for IPPMHuaweiBeijingChinadangjuanna@huawei.comChina TelecomBeijingChinawangjl50@chinatelecom.cnLG U+SeoulKorealeesy@lguplus.co.krTencentBeijingChinanikyan@tencent.comThis 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.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, 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 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 .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.Path GroupThere 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 or tunnel.PathOne path of the path groupPath CongestionA 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.As 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.Type-P-Path-Congestion use the Type-P convention as described
in .Src, the IP address of a hostDst, the IP address of a hostdpt, 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 timeSrcCountp, 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 or VXLAN ID.The value of a Type-P-Path-Congestion is either a real number or an
undefined (informally, infinite) number.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.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.The measurement methodology described in this section assumes the
measurement and determination of Type-P-Path-Congestion in
real-time.As 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.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 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 measurementAt 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 measurementAfter 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 ) -1In long-term measurement, the congestion parameters are
calculated as follows:c = (SrcCountp / DstCountp)-1Therefore, 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.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).The goal of the sample definition is to make it possible to compute
the statistics of sequences of Path Congestion measurements.Type-P-Path-Congestion-Poisson-streamSrc, the IP address of a hostDst, the IP address of a hostdpt[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 itT0, a timeTf, a timelambda, a rate in reciprocal secondsSrcCountp[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 or VXLAN ID.A sequence of four parameters whose elements are:T, a time, andc, either a zero (signifying no congestion transmission of the
packet) or greater than a zero (signifying congestion).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.The methodologies follow directly from:The selection of specific times using the specified Poisson
arrival process, andThe methodologies discussion already given for the singleton
Type-P-One-Path-Congestion metric.Type-P-Path-Congestion[i] = ( ( SrcCountp[i]) / (
DstCountp[i]) ) -1If 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.The calibration and context for the underlying singletons MUST be
reported along with the stream.The path congestion metric has the same security properties as , and thus they inherit the security considerations of
that document.TBDTBDA One-Way Delay Metric for IP Performance Metrics
(IPPM)Framework for IP Performance MetricsSegment Routing Policy ArchitectureVirtual eXtensible Local Area Network (VXLAN)Reporting IP Network Performance Metrics: Different Points of
ViewRFC2780Segment Routing ArchitectureActive and Passive Metrics and Methods (with Hybrid Types
In-Between)Alternate-Marking Method for Passive and Hybrid Performance
MonitoringInstant Congestion Assessment Network (iCAN) for Traffic
EngineeringMulti-Path Concurrent Measurement for IPPM