If the focus is on notifications, and not on the responses to
notifications, then issues such as very-low-loss delivery should be
described as potential results, not as goals of the work.
Separately, I think it is a mistake to conflate the intra-data center,
one-hop-wan, and arbitrary communication path cases. The time and
processing constraints for these cases are VERY different, and likely
useful notification approaches are likely to be different (and some
cases may not be amenable to significant improvement). As such, at the
very least I would expect identification of problem spaces with
different characteristics, and possibly explicit statements that they
should be addressed with different techniques.
Yours,
Joel
On 1/15/2026 10:13 PM, Dongjie (Jimmy) wrote:
Hi Joel,
Many thanks to your review and clarification questions. Please see replies
inline:
-----Original Message-----
From: Joel Halpern <[email protected]>
Sent: Friday, January 16, 2026 5:09 AM
To: Yingzhen Qu <[email protected]>; [email protected]; [email protected]
Subject: [rtgwg] Re: [fantel] Call for adoption:
draft-dong-fantel-problem-statement-03 (Ends 2026-01-30)
I have several basic concerns with the draft.
1) The draft starts by asserting that there is a need for lossless traffic delivery. It
is possible you actually mean lossless. In which case I consider the target impossible
for any general use network. It is mor elikely you mean very low loss (e.g 1 in 10^6
packet loss over any 1 minute time period.) If so, you need to state that and not refer
to "lossless".
[Jie] Thanks for pointing this out. "Lossless" used in the abstract and the introduction
section refers to the expectation of some applications to the network. This is similar to the
target of Detnet on "zero congestion loss". For the network it is difficult to guarantee
lossless in all scenarios and situations, what it network can do is to minimize packet loss and
control the loss rate below certain level (as you suggested), so that it does not impact the
performance of the applications. We can clarify this further in next revision, and consider to use
other word to avoid confusion.
2) Unless I missed it, other than in terms of examples the draft does not seem
to state whether it wants to solve an intra-data-center problem (a interesting,
important, and solvable problem), one hop wide are anetwork ( aproblem where it
may be possible to do something, depending upon the link delay, srbitrary but
special constructed wide area interconnects (demonstrated to be addressable by
throwing money at the problem), or arbitrary multi-use, multi-hop wide area
networks. The demands and difficulties of these different cases are different.
[Jie] The network scenarios you listed above are considered as potential use
cases of the fast notification mechanism. I agree there are differences in
these cases, while in general fast notification would help to enable prompt and
precise action upon network condition changes. Thus it is not limited to any
specific network scenario.
3) There is also an assertion that "faster" responsiveness to issues is needed.
Without some quantification of what kind of speed is needed, I do not see how this
claim can be evaluated, nor how solutions can be considered.
[Jie] Based on the discussion during the BoF and in RTGWG, in recent revisions
some text was added to the introduction and section 3 to quantify the expected
speed of fast notification (in the order of sub-milliseconds or milliseconds),
and why it is considered faster than existing mechanisms.
Net: While I see a nice sketch of a topic for investigation, I do not see
enough clarity for adoption.
[Jie] Hope the above can answer your clarification questions.
[Jie] BTW, after the submission of the -03 version, we asked the WG to give opinion on which term to use for
this work. "Fantel" was previously used for the BoF and in several drafts following that, while
according to the discussion and feedbacks, we would focus on the notification part and not limit the actions
to TE and load balancing. Thus another term "FANN" was proposed for "FAst Network
Notification". We'd appreciate your opinion on which term is better, or you are welcome to propose other
terms. Thanks.
Bes regards,
Jie
Yours,
Joel
On 1/15/2026 2:12 PM, Yingzhen Qu via Datatracker wrote:
This message starts a rtgwg WG Call for Adoption of:
draft-dong-fantel-problem-statement-03
This Working Group Call for Adoption ends on 2026-01-30
Abstract:
Modern networks require adaptive traffic manipulation including
Traffic Engineering (TE), load balancing, flow control, and
protection, to support high-throughput, low-latency, and lossless
applications such as Artificial Intelligence (AI) /Machine Learning
(ML) training and real-time services. A good and timely
understanding of network operational status, such as congestion and
failures, can help to improve network utilization, enable the
selection of paths with reduced latency, and enable faster response
to critical events. This document describes the existing problems
and why a new set of fast network notification solutions are needed.
Please reply to this message and indicate whether or not you support
adoption of this Internet-Draft by the rtgwg WG. Comments to explain
your preference are greatly appreciated. Please reply to all
recipients of this message and include this message in your response.
Authors, and WG participants in general, are reminded of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[2].
Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy
can be found at [3].
Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/
There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statem
ent-03
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-st
atement-03
_______________________________________________
fantel 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]
_______________________________________________
fantel 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]
