[Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)

["Dongjie (Jimmy)" <[e-mail]>]

Hi Tony,

Thanks for your suggestion. The current version of the draft acknowledges that there could be difference in providing fast notifications in different scenarios. The authors will consider whether and how much this draft needs to specify for different scenarios, or it can be done based on some classification.

Best regards,
Jie

From: Tony Li <[e-mail]> On Behalf Of Tony Li
Sent: Thursday, July 30, 2026 1:27 AM
To: Vishnu Pavan Beeram <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; Carlos Jesús Bernardos <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Fann] Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)


Hi Jie,

FANN is attempting to tackle a complex problem.  Trying to treat it as a single, simple problem is not going to lead to a good outcome.  I support explicitly articulating all of the different aspects of the problem at hand.

Specifically, if you are trying to deal with sub-100us requirements within the DC, then you’re not going to be able to address those when your interconnect has 10ms of latency.  No amount of wordsmithing is going to change the speed of light.

Regards,
Tony



On Jul 29, 2026, at 8:34 AM, Vishnu Pavan Beeram - vishnupavan.ietf at gmail.com <[e-mail]<mailto:[e-mail]>> wrote:

Jie,

Thanks for the prompt response and for taking the comments into consideration. I'd encourage using the sufficiently long adoption discussion window (adoption ends 8/18) to get WG input on these topics rather than deferring entirely to the next revision. Specifically, it would be helpful if you could propose some text and share your thoughts on how the DC vs. DCI distinction should be framed. Same goes for the other points raised (notification storms, failure vs. congestion decomposition, thundering herd) — even a rough sketch of how you plan to address them would help the WG evaluate the document's direction during the adoption discussion.

Regards,
-Pavan

On Wed, Jul 29, 2026 at 7:33 AM Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>> wrote:
Hi Pavan,

Thanks for your support and valuable comments. We will take them into consideration in next revision.

Please find some short replies inline:

From: Vishnu Pavan Beeram <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 29, 2026 9:11 PM
To: Carlos Jesús Bernardos <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Fann] Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)

WG,

I've reviewed draft-dong-fann-problem-statement-00 and support its adoption as a WG document, with comments that I believe should be addressed/discussed sooner than later.

The document does a good job motivating the need for fast network notifications and correctly scopes itself as a problem statement without prescribing solutions.

That said, I'd like to see the following addressed/discussed:

1. Explicitly distinguish DC and DCI contexts:
The document acknowledges that "mechanisms may differ depending on topology and deployment context" and states "this document does not assume one-size-fits-all" — but it never explicitly separates the requirements for DC fabric vs. DCI (and potentially WAN) environments. These differ significantly in propagation delay (microseconds vs. milliseconds), notification scope, congestion characteristics (incast/microbursts vs. sustained), trust boundaries, and what "fast" means in practice. The problem statement would be stronger if it explicitly acknowledged this spectrum.

Jie> I agree the difference in the problems of DC and DCI scenarios can be elaborated further.

2. Notification storms:
Section 4.5 touches on scaling but doesn't adequately address the fundamental problem: a spine failure can cause many leaf nodes to generate notifications simultaneously — creating a notification storm exactly when the network is already stressed. This deserves more attention as a problem dimension.

Jie> In the third bullet of section 4.5, it discussed the stress on the network when notifications are delivered to a number of recipients. I think your point is similar to that one, while slightly different in that the notification may be sent by multiple nodes which detect the event. We can add some text to that section.


3. Failure vs. congestion — different problems:
The document treats link/node failure (binary event, one-time propagation) and congestion/degradation (continuous state, frequent, threshold-based) as a unified problem. These have very different scalability profiles, frequency characteristics, and design considerations. Explicitly decomposing them would sharpen the problem statement.

Jie> Both failure and congestion are events which may trigger fast notifications. It was not the intention to treat failure and congestion as the same problem, although I agree the difference between them can be further described.


4. Coordinated action:
Section 4.4 lists possible recipient actions but doesn't address what happens when multiple recipients simultaneously act on the same notification — potentially overloading alternate paths. This is a fundamental dimension of the problem space.

Jie> In section 4.4 there is some text about coordination: “The sender of the fast network notification needs to take this into consideration if some coordination in the actions is needed.”

I guess what you mean is related to this, while may be more as a problem on the recipients’ side? We could take this into consideration in next revision.


If the document evolves to cover requirements as well (as the authors have indicated earlier on the list):
I'd expect the following to be addressed:

  *   Notification reliability: What happens when a notification is lost during the very failure/congestion event that triggered it? Whether at-most-once or at-least-once delivery is needed is a key requirement.
  *   In-band vs. out-of-band transport: The problem space should identify this as a key design dimension — in-band is faster but affected by the congestion it reports; out-of-band is more reliable but adds infrastructure.
  *   Suppression and aggregation: Requirements around dampening, reporter election, or aggregation mechanisms to prevent notification storms from exacerbating the very problems they report.

Jie> All of these are good points on the requirements for the solution. We will think about them and see how they can be reflected in the draft.

Editorial nits:

  *   "Preferrably" → "Preferably" (Section 4.3)
  *   "Actions to Fast Network Notifications" → "Actions in Response to Fast Network Notifications" (Section 4.4 title)
  *   "Acknowledgement" → "Acknowledgments" (Section 8, per RFC style)

Jie> Thanks for catching the nits. Will fix them in next revision.
Best regards,
Jie

Regards,
Pavan

On Tue, Jul 28, 2026 at 5:03 AM Carlos Jesús Bernardos via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
This message starts a fann WG Call for Adoption of:
draft-dong-fann-problem-statement-00

This Working Group Call for Adoption ends on 2026-08-18

Abstract:
   Many network applications, ranging from Artificial Intelligence (AI)
   /Machine Learning (ML) training/inference to cloud services, require
   networks with various combination of high bandwidth, low delay and
   low jitter and minimal packet loss in data transfer.  This requires
   that the networks must rapidly adapt to the presence of faults,
   degradation and congestion.  However, existing routing and traffic
   management mechanisms often face limitations in responsiveness,
   coverage, and operational complexity, particularly in large-scale and
   high-bandwidth network environments (e.g. data center (DC) and data
   center interconnect (DCI)).  A good and timely understanding of
   network conditions can help to enable faster response to critical
   events, so as to enable the selection of paths with reduced latency
   and improve network utilization.  This document describes the gap
   analysis and the need for fast network notification, and identifies
   the set of problems which a fast network notification solution needs
   to address.

Please reply to this message and indicate whether or not you support adoption
of this Internet-Draft by the fann 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-fann-problem-statement/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-dong-fann-problem-statement-00

_______________________________________________
Fann mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Fann mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>