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

[Vishnu Pavan Beeram <[e-mail]>]

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]> 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]>
> *Sent:* Wednesday, July 29, 2026 9:11 PM
> *To:* Carlos Jesús Bernardos <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [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]> 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]
> To unsubscribe send an email to [e-mail]
>
>