From nobody Tue Jul 5 08:58:26 2022 Return-Path: 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 6A9B8C139C27; Tue, 5 Jul 2022 08:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com 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 DeKG_Fzq6qCj; Tue, 5 Jul 2022 08:58:20 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2109.outbound.protection.outlook.com [40.107.220.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE97C13C55F; Tue, 5 Jul 2022 08:58:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kn2x2t3jDZHGkh71vbLppgDor3ItwMreKU3cpNZ/xeFjz2sJtHF3dVsDTvuug+IZ00mBqh0HvQNpi6DPvAY4ajiMg/Mggd+GehCiV7ki9F2yaOjx0WIpJSRzJlYBa8aCyNoAZSk3e3rpzZ20Gk7X9JvjOAiicGKqihn1EuhG+Bd+AiZDYY6GEK1Qcyi8RkEY41sNL/ElxpBFWJI4NkFA/cDHAr09LG1O9YdxHZLAikf1svhg7mRlTyfFC93Wb184L9O5IEmJD2vFcaYd4vcNpe1zVEhfhqtSHWUb3WT5g/1dZZlhZZk/8GR2WquVXYbtQVc8dPCPiLE3YqD8IGOtKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4x/e6lUfz479TTC7g/k67UHXsDtyqP6Nyp4IXsSnGic=; b=bsGrOX/Ljk3GsJAwzA3t8a7Ofif95Jd7XYQz3g79Uw934gWs41TTLinDcT5gqnDbwHrXzIuSwHJTrUFPl5e2qtMCIqyC1Y/nHK/x6yY+WkGQKCbiEfez0HhqyVmUrWu5brv7Ny2WIX+vbNjLrAlvxE2td7NIDa/rWMH736r7rmkWsqjSmMAhzTuHSNT/ta0Cnd1BDFf1Vp6LZNQKG+vKkUuMv3LOvNPMv5PTsC3yoJq3SivXkePQY8Q70nBZHDx6C9+3vPeWdKj3n/Ifdt/p/FFSP9xAcbK9LWSazP6AaadBd09zMsh+Bey0UzBr5zOz7ZHOI+P7tOS16QNLvYPKOw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4x/e6lUfz479TTC7g/k67UHXsDtyqP6Nyp4IXsSnGic=; b=CxPCMB2WZcoRAQgxgR0hDox8EU8GQtQZgpJD9UyV16XTTtQYz27a4P0ZccB56TTSeFRwdg0B3f1DyMukN3Y+gfWzbfRWJscQM3x842g/AsAk/LAQYEsWMbbsm+pA66EtrScDde+4fqAxeJBuR+PsrZP5EUOhzzUpYOeRBozhgjo= Received: from CO1PR13MB4920.namprd13.prod.outlook.com (2603:10b6:303:f7::17) by DM6PR13MB2524.namprd13.prod.outlook.com (2603:10b6:5:ca::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.8; Tue, 5 Jul 2022 15:58:16 +0000 Received: from CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::51c4:9a4:3a10:ee32]) by CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::51c4:9a4:3a10:ee32%9]) with mapi id 15.20.5417.013; Tue, 5 Jul 2022 15:58:16 +0000 From: Linda Dunbar To: "liupengyjy@chinamobile.com" , dyncast CC: "David R. Oran" , rtgwg Thread-Topic: CAN BoF issues #26 #28 #29 #31 Thread-Index: AQHYj46hAxK1WGcRQEe3/sjsv0FWN61v8dEQ Date: Tue, 5 Jul 2022 15:58:16 +0000 Message-ID: References: , <20220531000035646550674@chinamobile.com> <2022070418172058976396@chinamobile.com> In-Reply-To: <2022070418172058976396@chinamobile.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9bf41fbb-229d-4978-d5f2-08da5e9f2c7b x-ms-traffictypediagnostic: DM6PR13MB2524:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qSBKmvs5P/y8Sz3XwqPYdEAesK7nZkCCm3LKXTCuxOwC42c/rscelGEUKhE9GYwx1RZGSMxobOBgKInz0qgfaNqylnKs2a49U7OMsBXS9tF1kvruDXZyWWx0c5nJ2G2cZUQ8TglTemqoqp/dKC4V1ndwZuoSBGcXqtUp64nCVjkU4kz/6I3vxezGwX2b1v1JTGuYgOC0H2asHTyUS9pg3uyBM5BFc9LDV4f0qpCo008jARarENiQbHG2++iM7JNAOh6gBG9X4zMaPnsgFqoyJcsrj2Ekn/qbb+OVzkVL3jrEsukha8qPS/nIZ5MRVN2ooaCeuYPXde6gIcxUplQXsYjN3Z6bj7FFg4hDlStSfaKx3hwvNHq4JLw8teFtldnQjMH54ZpRQGOe4InXiTmX3yMlBYjiAFdvr5hyNULvMM+dwnB2cSDr2Wg6P5zppsIFeXKjYY58zzLxw8HBuUJnSB4PeMnNcG7pmLlfyF8m4bNgLgqS9RzkLPi+V+HoXL1USExrgTPt9woub2z7GC2sied1QGltnsk/xpBwhz4L8hbsZpVVxaungZw/fqSU6cTRNjFmMHcyIaOICnB7rvRf2Y2OYS90SHcH9OntliIlEMqzd+q0YDKuoF4SLOmzgvvTNEjeH2RCFrxqah+zVQi/amCrCVzCqsdRf2fnEA+/zpjfRrDNws+BVwKg18QPTQKCCe5BbTVkCAh/0BmJBGOdsOs7K70lljnulcSAwDVkvqfCKKgt9c/sVW4x27mdN2inxcxabnqO9XPQ7GLETvL78TJLmyAJJUj6cDPl6AJaBq7V3z5hcD/EYyDI+OFYdZoXWyeIw4cdezBJI2vHw6xmHxW8KmYnVNN1w4zh2a6ij75ZdgccuKn+b8wMZL62qEfM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB4920.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(366004)(136003)(346002)(39840400004)(396003)(376002)(64756008)(52536014)(66476007)(5660300002)(86362001)(44832011)(66556008)(55016003)(76116006)(33656002)(66446008)(8676002)(4326008)(2906002)(66946007)(8936002)(316002)(166002)(83380400001)(186003)(38100700002)(38070700005)(122000001)(9686003)(6506007)(7696005)(966005)(110136005)(41300700001)(71200400001)(478600001)(54906003)(66574015)(53546011)(26005)(559001)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?X1embfMFOBmhyhSy+uBT63pr6WcMlUwnkwhpOnzIYAk1ICNc85OyZQylufXa?= =?us-ascii?Q?rTANLPzLt6aqe+9GAXZerw44dngJmfFc4bxDeXblxtHFwPoiyTP/2APrgWh7?= =?us-ascii?Q?TGbZ8YxvdniPYZKAa5ZqDy8nyMsvrKFugYTJRflg24QpkbRx2s6p2l9XLa8k?= =?us-ascii?Q?f/nn/KnO9FF9giVlPvmLrsuHmTab3/nvEZEpt4z+RLTOt0szq9Xqw+uW6ANB?= =?us-ascii?Q?zDTqBozVrAksckKzj8ApHwLYw2xw4mEH1+Vx+RTe72sW7vcdD8k/T/vwm5rz?= =?us-ascii?Q?Gx/OOJnJp/fxYkZI3nYGgG6Tv+CpmlF0c9MvUpsA04uXbALZ2kri06NwFXlM?= =?us-ascii?Q?mL0V7AfkIZ+2AdxbVntDOFyvckfCRPtvsE4+iuB1pqgXk+hkgwx9uFjBJ9Aq?= =?us-ascii?Q?CvHTETN0ehYZBDgXToOUl+moEqhfbcx755hJezNP62fO+z3cXAwiaHHmL9Xo?= =?us-ascii?Q?8/RTIzqgcgbe8PQmCfTjq0bW9G8OcNIER8zRXo9K10g8+JFTTtV5r3FJkkgs?= =?us-ascii?Q?9wXVX8mTJLDhFQgtSS6puU6D7CHGt0gUm8qTP403Yqdf30FQ0pqfHuo5b0uI?= =?us-ascii?Q?8PS4NGWAOlbSN2PiPg7IH7L/ajc9ivO069UK2MgGJWhW7Qc5TjPB9R2zBcRu?= =?us-ascii?Q?uZDeJOJnfdI7JNZt77YUsXlsr4FzvzMbOQw2Jvp0SpotxVcbm6Hw+jSZycPX?= =?us-ascii?Q?APJVuavI8ioKUsqFC2tnrCJYc5+bbTbIfN8rFxz9z3TqQLronSx/1qx7x4H8?= =?us-ascii?Q?kRH6RwXmtfhlXnevHVLxVv2HvBVSjPBs/+KCSXj4Z+VFS1wGGkbzm5UkHNpp?= =?us-ascii?Q?L/XTI8zer/HAwNX92QGoS02+iymQj0AVzOHCkSSWomrIJXXYJVBaQLa/gmpY?= =?us-ascii?Q?4YthqOlsVlXclwV9mnDXoP7ctFceP3m546xWq2UWvqu7p0a7qWnRxnKztuvG?= =?us-ascii?Q?Gqd2rGyY4WLuKb3W7ReDbvHfMsDAKYaIC6AxG4Zzzs733AotxfZALQcgt0Qz?= =?us-ascii?Q?LSyD+fjjCAqe67ShbB+H58C/mCaEm2yK8Tjfx0gwwNAeBlw5LFJtckSYkGPh?= =?us-ascii?Q?7McJQHHPMZFKx75/wiBi+XTHCiGYPRGtRkg+YzxddHBhzMziQd4004es6a+U?= =?us-ascii?Q?T0pAO0GuI+4s+9OvSVFruM6vveBxzyhFLy1wjjgRtbYL6QZaiMSUBBHSYzqK?= =?us-ascii?Q?zugAQv2fkLLZtoxHe2xDAORyt89A7NYH2zyXLQD9OmPDP53EyFYPECaNSgal?= =?us-ascii?Q?x48CxOD8x86i1f7Am6N4tRzZzsE2Gey2I6U9Ke3qcJMViaQhIk1/+QivLNUy?= =?us-ascii?Q?0JrW0Tv1uYQ8ihziWerZRsWW8xJ9BT+wR7bH+Dg3wyEEJvDpYJwttx9dq4UF?= =?us-ascii?Q?QyB1LubA3vAHt0arEryt+myWZBPgQQJeiYTjmuphel4nT1x1lGmvqiVrlZqA?= =?us-ascii?Q?2TnNzZ1ZAWZrIc2y4ImuAvIqN4f5xCU2QqriiIyz7uGRZ0IOkfxmQYfPk8+n?= =?us-ascii?Q?02BMv1eLKuTkp1sKRG9Csrfw17k1PT6JAqcfSFFhh0xvffl6bGHXMDsRQmgm?= =?us-ascii?Q?8pBGZEVUWVEllksWasgYO9WUBntVeP53oQs+nQN7?= Content-Type: multipart/alternative; boundary="_000_CO1PR13MB4920AA315AAF739492A37E4685819CO1PR13MB4920namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB4920.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9bf41fbb-229d-4978-d5f2-08da5e9f2c7b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2022 15:58:16.5002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MthEsV12DrVRflsCTqdITcbXBVIFRxh9XEeK4GgZMJ1Qk70gmuMamgusqJgSQ5Te38vd/B1Xw4BqUJIEwyUSEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB2524 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2022 15:58:24 -0000 --_000_CO1PR13MB4920AA315AAF739492A37E4685819CO1PR13MB4920namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peng, For the #28: Does CAN Dyncast impact the Egress routers as well? When the c= omputing 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 t= o be impacted. If aspects of signaling will be realized via an existing rou= ting protocol, it may impact but that will depend on the final solution. Thanks, Linda From: rtgwg On Behalf Of liupengyjy@chinamobile.co= m Sent: Monday, July 4, 2022 5:17 AM To: dyncast Cc: David R. Oran ; rtgwg Subject: CAN BoF issues #26 #28 #29 #31 Dear All, Here are the responses to issues #26 #28 #29 #31, which are related to dync= ast. Any comments are welcome. This email is also copied to the questioner (https://datatracker.ietf.org/doc/minutes-= 113-can/), hope for fu= rther 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 informat= ion, which is not a given since it depends on the chosen solution. Update r= ates for compute/network metric information will heavily depend on the chos= en 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 t= o be impacted. If aspects of signaling will be realized via an existing rou= ting 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 propo= sed more for control plane. #31 For Dyncast, when the time is short, is it possible for the router to d= ecide the routing? It is too fast. Solutions for dyncast may be as simple as a weighted round robin on possibl= e (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=3D1&q= =3Dis%3Aopen+is%3Aissue+author%3ACAN-IETF I went through the issues captured in the Github and characterized them int= o 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 n= eeds for routing(e.g. WG?) or we are using those applications and won't nee= d such new WG? #30 * It needs application information too, so it can't just make a dec= ision at the network layer. #23 * This is not striked as a routing problem; it's all service discov= ery that can be done in higher layers. #21 * 3GPP and URSP solve this based on UPF selection. It uses both end= point + application. #20 * One overlay plane per application. Resources/metric specific to t= he plane. #19 * How does the application layer or the transport layer learn the n= etwork 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 messag= es or 1ms of latency #36 * Regarding the flow affinity, is it from network perspective or fr= om 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 appl= ication 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 (wait= ing for convergence/distribution as opposed to just updating the SD server)= #24 * Whether the interests of the organization deploying the applicati= on and the organization providing the network connectivity are aligned. Goo= gle doesn't worry about this because they are both. #17 o The question is more what the scope and semantic of information is tha= t will need to cross organizational boundaries. This needs further study, i= n particular when assuming stakeholder division between service and network= provider. * It seems impossible to satisfy that requirement simultaneously wi= th the latency requirement. #15 * It wasn't clear that how hard of a requirement session persistenc= e is. #13 o A session usually creates ephemeral state. If execution changes from o= ne (e.g., virtualized) service instance to another, state/context needs tra= nsfer to another. Such required transfer of state/context makes it desirabl= e to have session persistence (or instance affinity) as the default, removi= ng the need for explicit context transfer, while also supporting an explici= t state/context transfer (e.g., when metrics change significantly). * Should it select UPF based on the application? Steering is done p= er user? or per application? #9 * This seems to assume conventional non-distributed applications ju= st 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 fra= mework, 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 ind= icate 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-computi= ng-resource-representation): * It is hard to use existing work to measure the computation, but w= e can optimize the latency through the performance monitoring. We have perf= ormance/measurement matrix over there. #34 * Clarifications on the computing resource, its requirements and ch= aracteristics would be helpful. #27 * Each application may have a different definition of "resources" t= hese then have to be boiled down into a single topology Network Aware Compu= ting (NAC! :) does scale #14 * Is computing resource measurable? #10 o It is, and how to use the measurement would be solution related. See I= FIP Networking 2022 paper on how to simply expose "computing capability" an= d 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" u= nicast 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 route= r 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 --_000_CO1PR13MB4920AA315AAF739492A37E4685819CO1PR13MB4920namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peng,

 

For the #28: Does CAN Dyncast impact the Egress rout= ers 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 eve= ry router will need to be impacted. If aspects of signaling will be realize= d 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 issue= s #26 #28 #29 #31, which are related to dyncast. Any comments are= welcome.

 

This email is also copied to th= e 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 assum= ed update rate? !Gb? 1Tb?

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



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

CAN proposes an ingress-based architecture, so not eve= ry router will need to be impacted. If aspects of signaling will be realize= d 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 sta= ge, the work is proposed more for control plane.



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

Solutions for dyncast may be as simple as a weighted r= ound 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 f= or every request.

 

Any detailed discussion is expe= cted to be only within dyncast mailing list. You can also check and ad= d your comments to any of them(https://github.com/CAN-IETF/CAN-B= oF-ietf113/issues).  

 

Regards,

Peng

 

 

From: Linda Dunbar

Date: 2022-05-11 06:11

Subject:<= /span> [Dyncast] Categories of the CAN BoF issues<= /o:p>

CAN BoF proponents:=

 =

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

 =

I went through the issue= s captured in the Github and characterized them into groups. Some issues ca= n be lumped together for the discussion. There are quite a few issues relat= ed to the requirements, which need to be clarified.

 =

Best Regards, Linda=

 =

 =

Issu= es associated with Applications vs. Underlay networks:

·    &nbs= p;    Consider not to = load underlay network with application details. #35

·    &nbs= p;    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

·    &nbs= p;    It needs applica= tion information too, so it can't just make a decision at the network layer= . #23

·    &nbs= p;    This is not stri= ked as a routing problem; it's all service discovery that can be done in hi= gher layers. #21

·    &nbs= p;    3GPP and URSP= solve this based on UPF selection. It uses both endpoint + application. #2= 0

·    &nbs= p;    One overlay plan= e per application. Resources/metric specific to the plane. #19

·    &nbs= p;    How does the app= lication 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):

·    &nbs= p;    Need to understa= nd if three are requirement to avoid extra messages or 1ms of latency #36

·    &nbs= p;    Regarding the fl= ow affinity, is it from network perspective or from application/computation= perspective? #33

·    &nbs= p;    How to effective= ly compute paths? Shall we put CPUs into account? #32

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

·    &nbs= p;    It can only move= the services around as fast as it can update the routing plane. which come= s back to the point about service discovery (waiting for convergence/distri= bution as opposed to just updating the SD server) #24

·    &nbs= p;    Whether the inte= rests of the organization deploying the application and the organization pr= oviding the network connectivity are aligned. Google doesn't worry about th= is 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 ass= uming stakeholder division between service and network provider.

·    &nbs= p;    It seems impossi= ble to satisfy that requirement simultaneously with the latency requirement= . #15

·    &nbs= p;    It wasn't clear = that how hard of a requirement session persistence is. #13

o    A session usuall= y creates ephemeral state. If execution changes from one (e.g., virtualized= ) service instance to another, state/context needs transfer to another. Suc= h required transfer of state/context makes it desirable to have session persistence (or instance affinity) as t= he default, removing the need for explicit context transfer, while also sup= porting an explicit state/context transfer (e.g., when metrics change signi= ficantly).

·    &nbs= p;    Should it sel= ect UPF based on the application? Steering is done per user? or per applica= tion? #9

·    &nbs= p;    This seems to as= sume conventional non-distributed applications just running at the edge. wh= at 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.

·    &nbs= p;    Relation to 3= GPP UPF #6

·    &nbs= p;    Relation to A= LTO #5

·    &nbs= p;    Do the mobility = issues and associated protocols are also in scope? There are scenarios wher= e routing alone would not be sufficient. #4

·    &nbs= p;    What is the posi= tion in the edge location regarding to UPF? #3

·    &nbs= p;    Is there some so= rt of authorization model so that an edge can indicate whether or not it wi= ll provide compute services? #2

·    &nbs= p;    What is CNC a= nd the relationship with CAN #1=

<= span style=3D"color:black"> 

Meas= urement of the Computing Resources (to be addressed by draft-du-computing-r= esource-representation):

·    &nbs= p;    It is hard to us= e existing work to measure the computation, but we can optimize the latency= through the performance monitoring. We have performance/measurement matrix= over there. #34

·    &nbs= p;    Clarifications o= n the computing resource, its requirements and characteristics would be hel= pful. #27

·    &nbs= p;    Each application= may have a different definition of "resources" these then have t= o be boiled down into a single topology Network Aware Computing (NAC! :) do= es scale #14

·&n= bsp;        Is computing res= ource measurable? #10

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

·         Why compute reso= urce is different with other resources? #8

·          

Load= Balance based solutions:=

·    &nbs= p;    The point is tha= t we need a standardized LB protocol #18

·    &nbs= p;    The LB as part o= f the application itself is superior (part of the distributed application i= tself is to obtain and keep updating the "best" unicast location = to use). #22

·    &nbs= p;    If there is anyt= hing missing from current lbs that would prevent their use as-is? other tha= n there is for market reasons no interop standard between different lbs? #1= 2

·    &nbs= p;    For the load bal= ance, should it learn the network’s status? #11

·    &nbs= p;     

Dync= ast based Solution issues:

·    &nbs= p;    For Dyncast, whe= n the time is short, is it possible for the router to decide the routing? I= t is too fast. #31

·    &nbs= p;    Is dyncast propo= sed to encapsulate? #29

·    &nbs= p;    Will CAN dyncast= impact each and every router? How to avoid loops? #28

·    &nbs= p;    What's the assum= ed scale of a D-router? 10 ^ 6 sessions? 100^ 8? What's the assumed update = rate? !Gb? 1Tb? #26

 =

 =

 =

 =

--_000_CO1PR13MB4920AA315AAF739492A37E4685819CO1PR13MB4920namp_--