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

[[e-mail]]

Very clear and comprehensive explanations.
Thank you Eddie and Carlos!

Cheers,
Xiao Min


Original


From: EddieRuan <[e-mail]>
  
To: Dongjie (Jimmy) <jie.dong=[e-mail]>;Joel Halpern <[e-mail]>;肖敏10093570;
  
Cc: [e-mail] <[e-mail]>;
Date: 2026年08月05日 23:30
  
Subject: 回复：[Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)
  





Hi，




Thanks for raising this. The confusion is real, and as chairs we think it comes from the charter and the draft using different vocabulary rather than from an actual disagreement about scope. 
                        

The short version of where we see the line: FANN defines what notifications a fabric generates and how they are delivered; it does not define how a transport reacts to them. An end host can therefore  legitimately receive a FANN notification without transport-layer congestion control becoming FANN work. That is the distinction the IETF 126 comment was drawing, and we should have stated it more clearly at the time.     
                                                                                                                                                                                                     
On "node": the charter consistently says "nodes" / "network nodes", while §4.2 of the draft under adoption lists End Hosts as a recipient. Those two are only inconsistent if "network node" is read as "router/switch". We do not read it that way. It is really depending on the use cases. For AI cluster, we have seen two different approaches. Cloud providers tends to include end hosts into AI fabric consideration, such as Microsoft / Open AI’s MRC, Alibaba’s HPN., while some enterprise customers may still want to keep AI fabric for traditional network devices.   
   
Smart NICs/DPUs started their journey before  the AI wave and remain costly. So outside bare-metal use cases, the  adoption has been limited. In large AI clusters we more often see "super NICs" than DPUs getting deployed.  But either way the NIC increasingly performs fabric functions: e.g. MRC-style designs rely on the NIC to impose SRv6 encapsulation and steer flows onto selected paths. The charter's choice of "nodes" correctly captures this blurring host/network boundary instead of freezing a legacy network devices only.  
                                                                                                                                       
On the broader framing, we would like to propose that FANN focus explicitly on AI infrastructure across scale-up, scale-out, and scale-across (DCI). Even within those three the boundary differs. For scale-out, cloud providers generally treat the end host as part of the AI fabric solution, while some enterprise deployments prefer VOQ-style in-network approaches with no host involvement.  

FANN Charter has already accommodated the blurring host/network boundary. Instead we would ask the authors to align §4.2 with the charter's vocabulary:  "nodes, including host-resident fabric elements" rather than "End Hosts”.

From there, let us describe the problems and develop solutions against specific use cases. 

Thanks

Carlos & Eddie




------------------------------------------------------------------
发件人：Dongjie (Jimmy) <jie.dong=[e-mail]>
发送时间：2026年8月3日(周一) 03:15
收件人：Joel Halpern<[e-mail]>; "[e-mail]"<[e-mail]>
抄　送："[e-mail]"<[e-mail]>
主　题：[Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)


Hi Joel,
 
Thanks for your reply and the interpretation of the charter scope. Yes there is no qualification of the “remote nodes” in the charter text, from this point I agree that notifications  to hosts seem to be in the charter, and it is also mentioned in the current problem statement draft. 
 
In my reply to Min’s question (which was sent to this adoption call thread), I just provided my personal understanding to the concerns raised about “notifications to the host” during  the IETF FANN session. For further discussion on this point , a separate thread may be more appropriate. 
 
Best regards,
Jie
 

From: Joel Halpern <[e-mail]> 
Sent: Thursday, July 30, 2026 11:51 PM
To: Dongjie (Jimmy) <jie.dong=[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: [Fann] Re: Call for adoption: draft-dong-fann-problem-statement-00 (Ends 2026-08-18)


 
Jie,
    It is unclear whether your emails intends to claim that the scoping of the WG is up to the WG.  The question of whether to treat all parts of the scope as one, or as I and others would prefer to be more explicit about various segments  of the scope and their differences, is indeed up to the WG.  However, the overall scoping is not.   Unless we choose to update the charter and get IESG approval of such an update, the charter is clear that notifications are to "remote nodes" without any qualification  as to "network nodes", "host nodes", "control nodes", etc.  As such, notifications to hosts would seem to be as much in charter as notifications to any of the other kinds of nodes that are discussed.  Whether we choose adopt any problem descriptions, requirements,  or later solutions, for any given subset is up to the working group.  But the scope of the WG is defined by the charter.
Yours,
Joel

On 7/30/2026 11:37 AM, Dongjie (Jimmy) wrote:



Hi Min, 
 
Thanks for raising the question about the scope of the WG. This is a topic for WG discussion, and further discussion on the WG scope could happen on a separate thread. 
 
I can just share some personal view. As specified in section 4.2 of this draft, the fast network notifications can be sent to different types of recipients, which include adjacent  network nodes,  network nodes which are multiple hops away, the ingress network nodes, and the end hosts. While the type of recipients is not explicitly mentioned in the WG charter text. IMO the comment during IETF 126 meeting was mainly about the possible  overlap/interaction with the work in the transport area, which was also raised in the TSV review of this draft. Another point is whether FANN will define a unified notification mechanism which applies to both the network nodes, and the hosts/edge nodes, or  separate notification mechanisms need to be defined for network nodes and the hosts respectively. And if separate notifications are needed, which one should be prioritized in the WG?  Currently I have no answer to these questions, the problem statement draft  can be updated to reflect the WG’s decision.
 
Best regards,
Jie
 

From:[e-mail] <[e-mail]> 
Sent: Thursday, July 30, 2026 11:09 AM
To: [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)


 
Hi all,
 
In Section 4.2 of this draft in adoption poll, it describes *End Hosts* as a type of recipient of fast network notification, however when I presented problems and gap analysis for  DCI congestion notification at IETF 126, I heard a statement that said if the end host is a consumer of congestion notification then the congestion notification is outside the scope of the FANN WG, so what on earth is it within or outside the scope of this  new working group?

 Cheers,
Xiao Min
Original

From: CarlosJesúsBernardosviaDatatracker  <[e-mail]>  
To: [e-mail] <[e-mail]>;[e-mail]  <[e-mail]>;[e-mail] <[e-mail]>;   
Date: 2026年07月28日  20:02  
Subject: [Fann] Call for adoption: draft-dong-fann-problem-statement-00  (Ends 2026-08-18)  
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]
 



_______________________________________________Fann mailing list -- [e-mail] unsubscribe send an email to [e-mail]