Hi Joel, We just submitted a new revision (-05) to address your below comments. We'd appreciate your review of the updates and see if you are OK with the text. Thanks.
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-05 Best regards, Jie (on behalf of coauthors) > -----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]
