Jie, What bothers me about this approach is that it presumes that there is a magical delivery mechanism that this group will discover that delivers instantaneous messages.
This is clearly absurd; we have what we have. John Sent from my iPhone > On Jan 17, 2026, at 3:12 AM, Dongjie (Jimmy) > <[email protected]> wrote: > Hi Joel, > > You're right that the focus of this document is on notification. The goal is > to minimize the delivery time of the notification, and to provide > fine-grained network condition information to enable prompt and precise > actions. These enhancements in notification could help to improve the > performance of the applications, including those that require very-low-loss > delivery. > > As for the applicable use cases, we believe fast network notification in > general can help in all these use cases. It is understood that the delivery > time and some specific processing can be different in some of these cases, > while it is expected that the design principle and basic mechanism for fast > notification could be shared. What we are doing at this stage is collecting > all the required characteristics and information for fast network > notifications, so as to show the general problem space. In the next step they > could be further classified into common information and characteristics and > scenario-specific information and characteristics using a detailed > information model, which would be used to guide the solution design. > > Best regards, > Jie > >> -----Original Message----- >> From: Joel Halpern <[email protected]> >> Sent: Saturday, January 17, 2026 1:23 AM >> To: Dongjie (Jimmy) <[email protected]>; Yingzhen Qu >> <[email protected]>; [email protected]; [email protected] >> Subject: Re: [fantel] Re: [rtgwg] Re: Call for adoption: >> draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) >> >> 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] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
