Precise Priority-based Flow Control with Gateway

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 17 December 2026.¶

Copyright Notice

Copyright (c) 2026 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

In modern network deployments such as data centers and wide-area interconnections, multiple source clients frequently communicate through a shared ingress gateway. When substantial traffic is directed to a common server, these flows often converge onto a single bottleneck link within the network. Traditional end-to-end congestion control mechanisms��such as BBR and ECN��rely on feedback that must traverse the full return path to senders, introducing at least one round-trip time (RTT) of delay before rate adjustments take effect. This delay is particularly problematic in high-throughput, low-latency environments where transient congestion can severely impact performance.¶

The PPFC (Precise Priority-based Flow Control) as per [I-D.xz-rtgwg-ppfc-notification] can address this limitation by enabling network-assisted congestion control near the sources clients. The key idea is to instantaneously pause or throttle sources at the ingress point (e.g., a gateway), allowing the network to quickly recover from congestion.¶

This document proposes an enhancement to existing congestion control by introducing a PPFC mechanism at the gateway. By deploying PPFC at a gateway that aggregates traffic from multiple sources destined for a common destination, the gateway can prevent new flows from exacerbating existing congestion. It will significantly mitigate the congested link when the traffic transfers to the same destination.¶

2. Conventions Used in This Document

3. Precise Priority-based Flow Control with Gateway

Upon receiving the congestion in PPFC mechanism, the gateway can record the states and apply immediate congestion control to any subsequent traffic for that server. Furthermore, the gateway can perform source flow control, when new traffic arrives, it may reject or pause new flows to prevent worsening existing congestion.¶

The following figure illustrates this interaction:¶

               3-PPFC Notification (e.g.Server, Pause, 10us)
         ***************************************************
         *                     *                           *
         *                     *                           *
         *                     *                           *
         V                     V                           *
    +---+----+ 1-Traffic A +---+---+     +-------+     +---+---+     +-------+
    |Client A|<----------->|Gateway|<--->|Node X |<--->|Node Y |<--->|Server |
    +--------+      +----->+-------+     +-------+     +-------+     +-------+
         4-Traffic B|  ****+                           2-Congestion
    +--------+      |  *                                 Occurs
    |Client B+<-----+  * 5-PPFC Fast Feedback (e.g.Server, Pause, 10us)
    +--------+<*********

                         Figure 1: PPFC Mechanism at Gateway

The example at gateway is shown in Figure 1 and the steps are as follows.¶

Step 1: Client A sends traffic to the Server via the Gateway, Node X, and Node Y.¶

Step 2: Congestion occurs at the interface of Node Y towards the Server.¶

Step 3: Node Y generates an PPFC Notification containing the destination (Server) and a pause duration (10us), sending it to the Node X and the Node X transits it to the the Gateway.¶

Step 4: Client B attempts to send traffic to the same Server.¶

Step 5: The Gateway, having recorded the congested state for the Server, applies source flow control to Client B's new traffic. This may involve holding packets or sending an PPFC Feedback message with pause duration (e.g. 10us). which may apply the format as per [I-D.xz-rtgwg-ppfc-rocev2] to Client B, preventing its traffic from entering the network and aggravating the congestion at Node Y.¶

4. Security Considerations

To be discussed in future versions of this document.¶

5. IANA Considerations

This document does not currently require any IANA actions.¶

6. Contributors

The following people have substantially contributed to this document:¶

Qinghua Shao
ZTE Corporation
Email: shao.qinghua@zte.com.cn

7. Normative References

[I-D.xz-rtgwg-ppfc-notification]

Xiong, Q. and X. Zhu, "Precise Priority-based Flow Control Notification", Work in Progress, Internet-Draft, draft-xz-rtgwg-ppfc-notification-00, 12 June 2026, <https://datatracker.ietf.org/doc/html/draft-xz-rtgwg-ppfc-notification-00>.

[I-D.xz-rtgwg-ppfc-rocev2]

"*** BROKEN REFERENCE ***".

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

Authors' Addresses