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