Re: [Dyncast] CAN BoF issues #26 #28 #29 #31

huang.guangping@zte.com.cn Wed, 06 July 2022 03:11 UTC

Return-Path: <huang.guangping@zte.com.cn>
X-Original-To: dyncast@ietfa.amsl.com
Delivered-To: dyncast@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83346C15C6C5 for <dyncast@ietfa.amsl.com>; Tue, 5 Jul 2022 20:11:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.794
X-Spam-Level:
X-Spam-Status: No, score=-1.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARCo6bDTQcTx for <dyncast@ietfa.amsl.com>; Tue, 5 Jul 2022 20:11:47 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CB5C15C6C4 for <dyncast@ietf.org>; Tue, 5 Jul 2022 20:11:45 -0700 (PDT)
Received: from mse-fl2.zte.com.cn (unknown [10.5.228.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Ld4MM4mJcz8R03y; Wed, 6 Jul 2022 11:11:43 +0800 (CST)
Received: from szxlzmapp05.zte.com.cn ([10.5.230.85]) by mse-fl2.zte.com.cn with SMTP id 2663BQ5j016566; Wed, 6 Jul 2022 11:11:26 +0800 (GMT-8) (envelope-from huang.guangping@zte.com.cn)
Received: from mapi (szxlzmapp03[null]) by mapi (Zmail) with MAPI id mid17; Wed, 6 Jul 2022 11:11:25 +0800 (CST)
Date: Wed, 06 Jul 2022 11:11:25 +0800
X-Zmail-TransId: 2b0562c4fd5dffffffffd8709748
X-Mailer: Zmail v1.0
Message-ID: <202207061111250591309@zte.com.cn>
In-Reply-To: <20220706105220655994268@chinamobile.com>
References: CO1PR13MB49207A5646A942342E81B67585C99@CO1PR13MB4920.namprd13.prod.outlook.com, 20220531000035646550674@chinamobile.com, 2022070418172058976396@chinamobile.com, CO1PR13MB4920AA315AAF739492A37E4685819@CO1PR13MB4920.namprd13.prod.outlook.com, 20220706105220655994268@chinamobile.com
Mime-Version: 1.0
From: huang.guangping@zte.com.cn
To: liupengyjy@chinamobile.com
Cc: linda.dunbar@futurewei.com, dyncast@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn 2663BQ5j016566
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.137.novalocal with ID 62C4FD6F.001 by FangMail milter!
X-FangMail-Envelope: 1657077103/4Ld4MM4mJcz8R03y/62C4FD6F.001/10.5.228.82/[10.5.228.82]/mse-fl2.zte.com.cn/<huang.guangping@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 62C4FD6F.001/4Ld4MM4mJcz8R03y
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/RIjzE9OAvS-DrCMYxu41AMPzTaY>
Subject: Re: [Dyncast] CAN BoF issues #26 #28 #29 #31
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Dynamic Anycast <dyncast.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dyncast>, <mailto:dyncast-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dyncast/>
List-Post: <mailto:dyncast@ietf.org>
List-Help: <mailto:dyncast-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dyncast>, <mailto:dyncast-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2022 03:11:51 -0000

hi Linda and Peng,


it occurs to me that what we call "ingress" and "egress" is a logical term in terms of end2end flow while the actual CAN nodes upon which ingress and egress reside will have to operate both as ingress when it's the access node and egress when it's the proxy node of computing site.  IMHO, every CAN node which ususally is the edge network node needs to maintain the said computing status as well as executing the according forwarding actions, and the rest nodes would not be impacted by CAN protocol as well as encapsulation.






best regards,


Daniel Huang



























黄光平 huangguangping






架构团队/有线规划部 Wireline architecture team./Wireline Product R&D Institute









南京市雨花区软件大道50号中兴通讯2号楼 
R&D Building, ZTE
Corporation Software Road No.50, 
Yuhua District, Nanjing, P..R.China, 210012 
M: +86 13770311052 
E: huang.guangping@zte.com.cn 
www.zte.com.cn






Original



From: liupengyjy@chinamobile.com <liupengyjy@chinamobile.com>
To: linda.dunbar <linda.dunbar@futurewei.com>;dyncast <dyncast@ietf.org>;
Date: 2022年07月06日 10:47
Subject: Re: [Dyncast] CAN BoF issues #26 #28 #29 #31




--  
Dyncast mailing list
Dyncast@ietf.org
https://www.ietf.org/mailman/listinfo/dyncast

 Hi Linda,


It depends on the specific realization of D-MA(Dyncast Metric Agent) which gathers instances and network-related information. 


The D-MA may run in the egress(will impact) or separately on edge nodes(will not impact) . 


As for the packet sending from egress to instance, there might be local policy but that is not the basic demand of CAN dyncast.


Regards,
Peng

--------------------------------------------------------------------------------

liupengyjy@chinamobile.com


 


From: Linda Dunbar
Date: 2022-07-05 23:58
To: liupengyjy@chinamobile.com; dyncast
CC: David R. Oran; rtgwg
Subject: Re: [Dyncast] CAN BoF issues #26 #28 #29 #31





Peng,


 


For the #28: Does CAN Dyncast impact the Egress routers as well? When the computing site load changes, which entity notify the ingress nodes?


 


 


#28 Will CAN dyncast impact each and every router? How to avoid loops? 


CAN proposes an ingress-based architecture, so not every router will need to be impacted. If aspects of signaling will be realized via an existing routing protocol, it may impact but that will depend on the final solution.


Thanks, Linda


 



From: rtgwg <rtgwg-bounces@ietf.org> On Behalf Of liupengyjy@chinamobile.com
 Sent: Monday, July 4, 2022 5:17 AM
 To: dyncast <dyncast@ietf.org>
 Cc: David R. Oran <daveoran@orandom.net>; rtgwg <rtgwg@ietf.org>
 Subject: CAN BoF issues #26 #28 #29 #31




 


Dear All,



 



Here are the responses to issues #26 #28 #29 #31, which are related to dyncast. Any comments are welcome.



 



This email is also copied to the questioner (https://datatracker.ietf.org/doc/minutes-113-can/), hope for further suggestions and confirmations. Thanks.



 



#26 What's the assumed scale of a D-router? 10 ^ 6 sessions? 100^ 8? What's the assumed update rate? !Gb? 1Tb?


This question is only relevant if d-routers would maintain session information, which is not a given since it depends on the chosen solution. Update rates for compute/network metric information will heavily depend on the chosen algorithm for instance selection.



 
 


#28 Will CAN dyncast impact each and every router? How to avoid loops? 


CAN proposes an ingress-based architecture, so not every router will need to be impacted. If aspects of signaling will be realized via an existing routing protocol, it may impact but that will depend on the final solution.



 
 


#29 Is dyncast proposed to encapsulate? 


This will depend on the proposed solution. At this stage, the work is proposed more for control plane.



 
 


#31 For Dyncast, when the time is short, is it possible for the router to decide the routing? It is too fast. 


Solutions for dyncast may be as simple as a weighted round robin on possible (binding identifier) table entries, which should be implementable at the suitable speed. Also, depending on the realization of affinity, the ingress decision may not be required for every request.





 



Any detailed discussion is expected to be only within dyncast mailing list. You can also check and add your comments to any of them(https://github.com/CAN-IETF/CAN-BoF-ietf113/issues).  



 



Regards,



Peng




 



 
--------------------------------------------------------------------------------



liupengyjy@chinamobile.com





 




From: Linda Dunbar



Date: 2022-05-11 06:11



To: dyncast@ietf.org



Subject: [Dyncast] Categories of the CAN BoF issues





CAN BoF proponents:


 


Many thanks for creating the CAN BoF issues tracking  in the Github: https://github.com/CAN-IETF/CAN-BoF-ietf113/issues/created_by/CAN-IETF?page=1&q=is%3Aopen+is%3Aissue+author%3ACAN-IETF


 


I went through the issues captured in the Github and characterized them into groups. Some issues can be lumped together for the discussion. There are quite a few issues related to the requirements, which need to be clarified.



 


Best Regards, Linda


 



 


Issues associated with Applications vs. Underlay networks:


·         Consider not to load underlay network with application details. #35


·         We have multiple upper layer application. Do we have additional needs for routing(e.g. WG?) or we are using those applications and won't need such new WG? #30


·         It needs application information too, so it can't just make a decision at the network layer. #23


·         This is not striked as a routing problem; it's all service discovery that can be done in higher layers. #21


·         3GPP and URSP solve this based on UPF selection. It uses both endpoint + application. #20


·         One overlay plane per application. Resources/metric specific to the plane. #19


·         How does the application layer or the transport layer learn the network status to steering traffic? #16


 


Need more clear requirements for CAN (to be addressed by draft-liu-dyncast-ps-usecases):


·         Need to understand if three are requirement to avoid extra messages or 1ms of latency #36


·         Regarding the flow affinity, is it from network perspective or from application/computation perspective? #33


·         How to effectively compute paths? Shall we put CPUs into account? #32


·         What happens when the user moves? If so we also need to move application context. #25


·         It can only move the services around as fast as it can update the routing plane. which comes back to the point about service discovery (waiting for convergence/distribution as opposed to just updating the SD server) #24


·         Whether the interests of the organization deploying the application and the organization providing the network connectivity are aligned. Google doesn't worry about this because they are both. #17


o    The question is more what the scope and semantic of information is that will need to cross organizational boundaries. This needs further study, in particular when assuming stakeholder division between service and network provider.


·         It seems impossible to satisfy that requirement simultaneously with the latency requirement. #15


·         It wasn't clear that how hard of a requirement session persistence is. #13


o    A session usually creates ephemeral state. If execution changes from one (e.g., virtualized) service instance to another, state/context needs transfer to another. Such required transfer of state/context makes it desirable to have session persistence (or instance affinity) as the default, removing the need for explicit context transfer, while also supporting an explicit state/context transfer (e.g., when metrics change significantly).


·         Should it select UPF based on the application? Steering is done per user? or per application? #9


·         This seems to assume conventional non-distributed applications just running at the edge. what about modern frameworks like Sapphire? and Ray? #7


o    It would be good to understand the multi-site requirements of such framework, which I have understood to mainly run in single DCs.


·         Relation to 3GPP UPF #6


·         Relation to ALTO #5


·         Do the mobility issues and associated protocols are also in scope? There are scenarios where routing alone would not be sufficient. #4


·         What is the position in the edge location regarding to UPF? #3


·         Is there some sort of authorization model so that an edge can indicate whether or not it will provide compute services? #2


·         What is CNC and the relationship with CAN #1


 


Measurement of the Computing Resources (to be addressed by draft-du-computing-resource-representation):


·         It is hard to use existing work to measure the computation, but we can optimize the latency through the performance monitoring. We have performance/measurement matrix over there. #34


·         Clarifications on the computing resource, its requirements and characteristics would be helpful. #27


·         Each application may have a different definition of "resources" these then have to be boiled down into a single topology Network Aware Computing (NAC! :) does scale #14


·         Is computing resource measurable? #10


o    It is, and how to use the measurement would be solution related. See IFIP Networking 2022 paper on how to simply expose “computing capability” and achieve better steering with such simple measure.


·         Why compute resource is different with other resources? #8


·          

 
Load Balance based solutions:


·         The point is that we need a standardized LB protocol #18


·         The LB as part of the application itself is superior (part of the distributed application itself is to obtain and keep updating the "best" unicast location to use). #22


·         If there is anything missing from current lbs that would prevent their use as-is? other than there is for market reasons no interop standard between different lbs? #12


·         For the load balance, should it learn the network’s status? #11


·          


Dyncast based Solution issues:


·         For Dyncast, when the time is short, is it possible for the router to decide the routing? It is too fast. #31


·         Is dyncast proposed to encapsulate? #29


·         Will CAN dyncast impact each and every router? How to avoid loops? #28


·         What's the assumed scale of a D-router? 10 ^ 6 sessions? 100^ 8? What's the assumed update rate? !Gb? 1Tb? #26