Data Fields for Congestion Measurement

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

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

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

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

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 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  +---------+

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                      |
~                            ....                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

• 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.¶

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¶

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

Authors' Addresses