Hi David, Thanks a lot for your valuable comments both during the meeting and on the list.
Yes this draft does not attempt to reinvent any congestion control mechanism, and we will make this clearer in the text. Please see further replies inline with [Jie]: -----Original Message----- From: Black, David <[email protected]> Sent: Thursday, December 4, 2025 11:13 AM To: Dongjie (Jimmy) <[email protected]>; RTGWG <[email protected]> Cc: [email protected]; [email protected]; Black, David <[email protected]> Subject: draft-dong-fantel-problem-statement-02.txt & Congestion Congestion is mentioned a number of times in this draft. Based on my experience in this area (e.g., I'm an author of RFC 3168 and RFC 8311), I have a couple of suggestions. [1] The draft needs to be clear that it is not attempting to reinvent end-to-end congestion control, e.g., the sender backoff response found in protocols such as TCP and QUIC). For the most part, the draft does a reasonable job of that, although there is room for improvement. I suggest modifying the second paragraph of the introduction to a) remove a potentially misleading use of "end-to-end" and b) state that the notification delivery (and hence reaction) time can be substantially shorter than the RTT for the traffic involved, e.g.: This document summarizes the limitations of existing mechanisms that prevent rapid notification and action to critical network events, including link or node failures and congestion. It also identifies the need for fast network notification which is critical for enabling fast reaction. In the context of this draft, fast does not imply a OLD single, rigid numerical time threshold. Instead, it characterizes a class of mechanisms to minimize the delivery time so that the end-to- end latency of the notification is on the order of sub-milliseconds or milliseconds, depending on the operational objective and the range of the network domain. NEW single, rigid numerical time threshold. Instead, it characterizes a class of mechanisms to minimize the delivery time so that the latency of the notification is on the order of sub-milliseconds or milliseconds, depending on the operational objective and the range of the network domain, and can be substantially shorter than the Round-Trip-Time (RTT) of the network traffic involved. [Jie] Thanks for the proposed text, it looks good and we will incorporate it into the next revision. [2] I found a problem in the discussion of ECN - the second itemized paragraph in section 3 begins with: * Coarse-Grained Signals: Classic ECN [RFC3168] and similar mechanisms only provide binary or threshold-based feedback. The lack of granularity prevents rapid, fine-tuned adjustments, which can lead to either overreaction and underutilization of the available capacity , or underreaction that fails to alleviate the congestion. What would be useful is a set of notifications that aren't just "on-off" state reports but can also convey more information like congestion level/utilization information, latency spikes, queue buildup or flow characteristics, so that it can trigger immediate and precise responses like rerouting, rate adjustment, or protection switching for specific flows. That first sentence ("... only provide binary or threshold-based feedback ...") is not correct. There is "running code" that derives significantly richer feedback by considering more than one received ECN CE indication, e.g., DCTCP - see RFC 8257 in general, and Section 3.3 in particular. The correctness of the second sentence ("... lack of granularity prevents rapid, fine-tuned adjustments ...") depends on the network environment - it's correct for some networks and not correct for others. A far more valid criticism of ECN is the RTT-based criticism provided in the immediately preceding Slow Reaction paragraph. I suggest reorienting the Coarse-Grain Signals paragraph to focus on the richness/content of feedback benefit described in the last sentence ("What would be useful ..."). This would involve removing the first two sentences and replacing them with text that observes that ECN's use of a 2-bit header field inherently limits the information it can report to congestion indications, which sets up the "convey more information" value in the last sentence. [Jie] Thanks for the suggestion, it makes sense to be more precise about the descriptions of the ECN approach, we will take this into consideration and revise the text accordingly. Best regards, Jie Thanks, --David -----Original Message----- From: Dongjie (Jimmy) <[email protected]> Sent: Tuesday, November 25, 2025 5:24 AM To: RTGWG <[email protected]> Cc: [email protected]; [email protected] Subject: [rtgwg] FW: New Version Notification for draft-dong-fantel-problem-statement-02.txt [EXTERNAL EMAIL] Dear RTGWG, Thanks a lot for the good discussion and valuable comments on network notifications problem statement at IETF 124. A new revision of this draft has been submitted to incorporate the comments and suggestions. According to the feedbacks from the meeting, the scope of the problem has been narrowed to "Fast Network Notifications", and some description about the motivation and characteristics of fast notification is added. And as suggested by several people at the mic, one subsection about the actions to fast network notifications is also added. There are also some editorial changes, including the clarification about the classic ECN mechanism mentioned in this draft, and text to improve readability. Further review and comments are welcome. Best regards, Jie (on behalf of coauthors) -----Original Message----- From: [email protected] <[email protected]> Sent: Tuesday, November 25, 2025 3:21 PM To: Francois Clad (editor) <[email protected]>; Dongjie (Jimmy) <[email protected]>; Luis M. Contreras <[email protected]>; Mike McBride (editor) <[email protected]>; DURMUS Mehmet <[email protected]>; Francois Clad <[email protected]>; Hao Lu <[email protected]>; Jeffrey Zhang <[email protected]>; Dongjie (Jimmy) <[email protected]>; Luis Contreras <[email protected]>; Mehmet Durmus <[email protected]>; Mike McBride <[email protected]>; Ran Pang <[email protected]>; Rui Zhuang <[email protected]>; Xiaohu Xu <[email protected]>; Yadong Liu <[email protected]>; Yongqing Zhu <[email protected]>; Zhaohui Zhang <[email protected]> Subject: New Version Notification for draft-dong-fantel-problem-statement-02.txt A new version of Internet-Draft draft-dong-fantel-problem-statement-02.txt has been successfully submitted by Jie Dong (editor) and posted to the IETF repository. Name: draft-dong-fantel-problem-statement Revision: 02 Title: Fast Network Notifications Problem Statement Date: 2025-11-25 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-dong-fantel-problem-statement-02.txt Status: https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ HTMLized: https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement Diff: https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-02 Abstract: Modern networks require adaptive traffic manipulation including Traffic Engineering (TE), load balancing, flow control and protection etc. to support applications like AI training and real-time services. A good and timely understanding of network operational status, such as congestion and failures, can help to improve utilization, reduce latency, and enable faster response to critical events. This document describes the existing problems and why the IETF may need a new set of fast network notifications related solutions to support any high-throughput, low-latency and lossless application. The IETF Secretariat _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
