Internet DRAFT - draft-shi-ippm-congestion-measurement-data
draft-shi-ippm-congestion-measurement-data
IP Performance Measurement H. Shi, Ed.
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: 5 September 2024 Z. Li
China Mobile
4 March 2024
Data Fields for Congestion Measurement
draft-shi-ippm-congestion-measurement-data-00
Abstract
Congestion Measurement collects the congestion information in the
packet while the packet traverses a path. The sender sets the
congestion measurement command in the packet header indicating the
network device along the path to update the congestion information
field in the packet. When the packet arrive at the receiver, the
congestion information field will reflect the degree of congestion
across network path. Congestion Measurement can enable precise
congestion control, aids in effective load balancing, and simplifies
network debugging. This document defines data fields for Congestion
Measurement. Congestion Measurement Data-Fields can be encapsulated
into a variety of protocols, such as Network Service Header (NSH),
Segment Routing, Generic Network Virtualization Encapsulation
(Geneve), or IPv6.
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 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Shi, et al. Expires 5 September 2024 [Page 1]
Internet-Draft CM March 2024
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Data fields for Congestion Measurement . . . . . . . . . . . 4
4. Example: HPCC with Congestion Measurement . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
To effectively manage network congestion, a detailed understanding of
congestion levels across the network is imperative. Congestion
control algorithms, therefore, necessitate precise congestion
measurements to adapt and optimize data flow. This approach involves
monitoring various metrics such as packet loss, delay variations, and
throughput, which can provide a glimpse of the network's congestion
state. Enhanced congestion metrics allow for a more nuanced response
to congestion, enabling algorithms to adjust sending rates with
greater precision, thereby improving overall network performance and
efficiency.
Furthermore, the detailed congestion measurements obtained are not
solely beneficial for congestion control; they serve multifaceted
purposes, including load balancing and network operations debugging.
By analyzing congestion data, network operators can identify and
resolve bottlenecks, optimize traffic distribution, and ensure a
balanced load across the network. This data-driven approach
facilitates proactive network management, allowing for timely
interventions that can preempt potential disruptions and enhance
network reliability and performance.
Shi, et al. Expires 5 September 2024 [Page 2]
Internet-Draft CM March 2024
Addressing the limitations of High Precision Congestion Control
(HPCC)[I-D.draft-an-ccwg-hpcc], which leverages in-band telemetry for
detailed congestion signal collection but faces challenges with
packet size increases and computational redundancy, our proposed
solution introduces data fields for Congestion Measurement.
Congestion Measurement expands the conventional single-bit ECN to
multiple bits, allowing network devices to update congestion
information at each hop more granularly. Consequently, when packets
reach the receiver, the congestion information field in the packet
accurately not just the presence of congestion but the degree of
congestion across the link's path. This nuanced approach facilitates
a richer set of data for decision-making, supporting not only more
precise congestion control but also improving load balancing and
network debugging efforts. By overcoming HPCC's shortcomings, our
approach enhances network efficiency, reduces computational overhead
at endpoints, and offers a scalable solution to managing congestion
in complex network environments. Congestion Measurement Data-Fields
can be encapsulated into a variety of protocols, such as Network
Service Header (NSH), Segment Routing, Generic Network Virtualization
Encapsulation (Geneve), or IPv6.
1.1. Terminology
* ECN: Explicit Congestion Notification
* HPCC: High Precision Congestion Control[I-D.draft-an-ccwg-hpcc]
* DRE: Discounting Rate Estimator[CONGA]
1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Overview
Figure 1 shows the overview procedure of Congestion Measurement.
First the sender MUST marks the packet with data fields for
Congestion Measurement (see Section 3) which specifies what kind of
the congestion information that the sending node intends to collect
from transit nodes. As the packet traverses through the network,
each router should inspect the data fields and update the Congestion
Info field accordingly. Upon reaching the receiver, the updated
congestion info data within the packet is extracted and then send
back to the sender. The sender, now equipped with the congestion
Shi, et al. Expires 5 September 2024 [Page 3]
Internet-Draft CM March 2024
information reflective of the packet's journey, uses this data to
make informed adjustments to its sending rate or load balancing
decisions.
Mark Update Update Export
Congestion Congestion Congestion Congestion
Measurement Info Info Info
| | | |
| | | |
| | | |
+-------+ +-------+ +-------+ +---------+
|Sending|========>|Transit|=========>|Transit|======= >|Receiving|
| Node | | Node1 | | Node2 | | Node |
+-------+ Link-1 +-------+ Link-2 +-------+ Link-3 +---------+
Figure 1: Overview of Congestion Measurement
3. Data fields for Congestion Measurement
Figure 2 shown the format of data fields for Congestion Measurement.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved |C| Congestion Info Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Info Data |
~ .... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Data Fields for Congestion Measurement
where:
* Flags: An 8-bit field.
- The first bit(U) indicates whether the Congestion Info Data
field needs to be updated by transit nodes. If set, the
transit nodes will update the Congestion Info Data. If not,
the transit node will not update it.
- The last bit(C) indicates the Congestion Info Data is
customized and used only in limited domain such as Data center
network. If the C is 0, the Congestion Info Type is a bitmap.
Other bits are reserved.
Shi, et al. Expires 5 September 2024 [Page 4]
Internet-Draft CM March 2024
* Congestion Info Type: A 24-bit map that specifies the present
Congestion Info Data. Supported Congestion Info Data is listed in
Table 1. Note that it is possible for multiple Congestion Info
Data to coexist in one packet for the endpoint to collect the
detailed raw congestion information.
* Congestion Info Data: A variable length field including the
congestion information data. Router MUST update this field based
on local load status. The length and the update operation is
listed in Table 1.
+=====+=========================+========+===========+
| Bit | Congestion Info Data | Length | Operation |
+=====+=========================+========+===========+
| 0 | Inflight Ratio | 8 | Max |
+-----+-------------------------+--------+-----------+
| 1 | DRE | 8 | Max |
+-----+-------------------------+--------+-----------+
| 2 | Queue Utilization Ratio | 8 | Max |
+-----+-------------------------+--------+-----------+
| 3 | Queue Delay | 8 | Add |
+-----+-------------------------+--------+-----------+
| 4 | Congested Hops | 8 | Add |
+-----+-------------------------+--------+-----------+
Table 1: Congestion Info Data
4. Example: HPCC with Congestion Measurement
HPCC calculates the inflight ratio of each link(represent the link
utilization of the link) from the collected raw load information
carried in the INT. Then maximum inflight ratio along the path is
identified and used to adjust the sending rate. The formula to
calculate the inflight ratio of each link is shown below:
txRate = (txBytes_1 - txBytes_2)/(t_1-t_2)
inflight ratio = qlen/(B*T) + txRate/B
where:
* txBytes: link total transmitted bytes associated with timestamp ts
* qlen: link queue length
* B: link bandwidth
* T: Baseline RTT
Shi, et al. Expires 5 September 2024 [Page 5]
Internet-Draft CM March 2024
Leveraging Congestion Measurement, the router participates in
calculation of the maximum inflight ratio. Each router MUST
calculate the inflight ratio of the down link and then compare it to
the one in the Congestion Info Data field and keep the larger one.
When the packet arrives at the endpoint, the Congestion Info Data
field already contains the maximum inflight ratio. The sending rate
adjustment algorithm remains unchanged. By allowing routers to
conduct these calculations, the computing overhead is reduced for the
endpoint. Since the update of value is in-place, the packet size
remains unchanged regardless of the hops count.
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. References
7.1. Normative References
[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/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
7.2. Informative References
[CONGA] Alizadeh, M., Edsall, T., Dharmapurikar, S., Vaidyanathan,
R., Chu, K., Fingerhut, A., Lam, V., Matus, F., Pan, R.,
Yadav, N., and G. Varghese, "CONGA: distributed
congestion-aware load balancing for datacenters",
Proceedings of the 2014 ACM conference on SIGCOMM,
DOI 10.1145/2619239, August 2014,
<https://doi.org/10.1145/2619239>.
Shi, et al. Expires 5 September 2024 [Page 6]
Internet-Draft CM March 2024
[I-D.draft-an-ccwg-hpcc]
An, Q., Gao, J., Anubolu, S., Pan, R., Lee, J., Gafni, B.,
Shpigelman, Y., Tantsura, J., and G. Caspary, "HPCC++:
Enhanced High Precision Congestion Control", Work in
Progress, Internet-Draft, draft-an-ccwg-hpcc-00, 30 June
2023, <https://datatracker.ietf.org/doc/html/draft-an-
ccwg-hpcc-00>.
Authors' Addresses
Hang Shi (editor)
Huawei
Beijing
China
Email: shihang9@huawei.com
Tianran Zhou
Huawei
Beijing
China
Email: zhoutianran@huawei.com
Zhenqiang Li
China Mobile
Beijing
China
Email: li_zhenqiang@hotmail.com
Shi, et al. Expires 5 September 2024 [Page 7]
