IETF Logo Mail Archive

Re: [Dyncast] edge capability feedback

Barry Greene <bgreene@senki.org> Thu, 11 March 2021 03:33 UTC

Return-Path: <bgreene@senki.org>
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 5737F3A0ABE for <dyncast@ietfa.amsl.com>; Wed, 10 Mar 2021 19:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 pvOZ6YVPWbub for <dyncast@ietfa.amsl.com>; Wed, 10 Mar 2021 19:33:56 -0800 (PST)
Received: from smtp86.ord1c.emailsrvr.com (smtp86.ord1c.emailsrvr.com [108.166.43.86]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255923A0AB8 for <dyncast@ietf.org>; Wed, 10 Mar 2021 19:33:56 -0800 (PST)
X-Auth-ID: bgreene@senki.org
Received: by smtp27.relay.ord1c.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id BDEDF4012D; Wed, 10 Mar 2021 22:33:53 -0500 (EST)
From: Barry Greene <bgreene@senki.org>
Message-Id: <9A6BA68B-3916-413E-BD29-62D4096DF1D3@senki.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_A80E35E3-AC06-4F77-BF92-EB655632C250"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 10 Mar 2021 21:33:49 -0600
In-Reply-To: <20210311102435132657878@chinamobile.com>
Cc: Michael McBride <michael.mcbride@futurewei.com>, dyncast <dyncast@ietf.org>
To: =?utf-8?B?5YiY6bmP?= <liupengyjy@chinamobile.com>
References: <20210311102435132657878@chinamobile.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-Classification-ID: 6ed6b9d0-3a80-4264-a960-4779c704146c-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/1Ykvyw22EGZ3K25H3RQbFzuyxWQ>
Subject: Re: [Dyncast] edge capability feedback
X-BeenThere: dyncast@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Thu, 11 Mar 2021 03:33:57 -0000


> On Mar 10, 2021, at 8:24 PM, 刘鹏 <liupengyjy@chinamobile.com> wrote:
> 
> The edge node could inform it's status to the D-routers based on the metric, such as CPU load or other metrics for the specific instance if defined in the furture, then the D-router could choose a suitable edge considering both network and computing or other specific status. We have some experimental verification and functional implementation.

Have you done the due diligence in past work in this area?

What you described above sounds like the signaling in the DOTS work (shifting load based on DDoS).

It is also should similar to Cisco Distributed Direct Routing Protocol (1997ish), TIDP/TMP (early 2000s), and some other network oriented shifting of edge loads.

What would be helpful is a review of all the past efforts (go back to the ‘90s) and review what worked and what did not work.

v2.8.7 | Report a Bug | By Email