IETF Logo Mail Archive

Re: [Dyncast] CAN BoF issues and the next steps

"liupengyjy@chinamobile.com" <liupengyjy@chinamobile.com> Wed, 13 April 2022 10:18 UTC

Return-Path: <liupengyjy@chinamobile.com>
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 DCA6B3A1BD0 for <dyncast@ietfa.amsl.com>; Wed, 13 Apr 2022 03:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNzHs48Abyb5 for <dyncast@ietfa.amsl.com>; Wed, 13 Apr 2022 03:18:20 -0700 (PDT)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5737D3A1BCE for <dyncast@ietf.org>; Wed, 13 Apr 2022 03:18:20 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[172.16.121.89]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee26256a368274-8c47e; Wed, 13 Apr 2022 18:18:16 +0800 (CST)
X-RM-TRANSID: 2ee26256a368274-8c47e
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from CMCC-LP (unknown[10.2.53.71]) by rmsmtp-syy-appsvrnew05-12026 (RichMail) with SMTP id 2efa6256a3676c6-3e82e; Wed, 13 Apr 2022 18:18:16 +0800 (CST)
X-RM-TRANSID: 2efa6256a3676c6-3e82e
Date: Wed, 13 Apr 2022 18:22:28 +0800
From: "liupengyjy@chinamobile.com" <liupengyjy@chinamobile.com>
To: Tony Li <tony.li@tony.li>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn>, dyncast <dyncast@ietf.org>, 'Luigi IANNONE' <luigi.iannone=40huawei.com@dmarc.ietf.org>
References: <2022041114360459722023@chinamobile.com>, <29752325-4d93-271d-a0f1-e874575dca9b@joelhalpern.com>, <2022041122304706741797@chinamobile.com>, <5c189bc0-0569-e2f9-54b3-1bb41335ae21@joelhalpern.com>, <008f01d84e13$8b5db8f0$a2192ad0$@tsinghua.org.cn>, <d8fd1f2624b743698ed7b9ba390299f3@huawei.com>, <00ed01d84ee1$859b5f70$90d21e50$@tsinghua.org.cn>, <de849853-e073-5b61-dab8-b5a3dc33ed71@joelhalpern.com>, <00ee01d84ee2$7b852b50$728f81f0$@tsinghua.org.cn>, <E0FB105F-CF94-420F-B601-EE5C036E616D@tony.li>, <20220413115929730791134@chinamobile.com>, <547FE283-6CDC-4C0C-B052-3C009D7BE75A@tony.li>
X-Priority: 3
X-GUID: D5931D97-4607-4404-A102-A85E421915BC
X-Has-Attach: no
X-Mailer: Foxmail 7.2.21.453[cn]
Mime-Version: 1.0
Message-ID: <202204131822284615656@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart534121472103_=----"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/aYOlKiKtMUjl0owZjXFvJ921vKQ>
Subject: Re: [Dyncast] CAN BoF issues and the next steps
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.29
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, 13 Apr 2022 10:18:27 -0000

Hi Tony,

Thanks, may not minimizing but compared to be a better choice for some use cases which also depends on the requirements. 

We will add more analysis in the drafts of next version.

Regards,
Peng


liupengyjy@chinamobile.com
 
From: Tony Li
Date: 2022-04-13 14:19
To: liupengyjy
CC: Aijun Wang; dyncast; Luigi IANNONE
Subject: Re: [Dyncast] CAN BoF issues and the next steps

Hi Peng,


The method of UE to pick the instance from the broker is simple but thought to cause more messages and latency compared to the in-path solution, and need the broker to learn all the network status. 


If minimizing messaging and latency are design requirements, then that needs to be justified somehow.

Tony

v2.23.0 | Report a Bug | By Email