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

Jens Finkhaeuser <jens@interpeer.io> Thu, 14 April 2022 08:04 UTC

Return-Path: <jens@interpeer.io>
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 ECFD73A0F0E for <dyncast@ietfa.amsl.com>; Thu, 14 Apr 2022 01:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=interpeer.io
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 9OqwRlqKDHOa for <dyncast@ietfa.amsl.com>; Thu, 14 Apr 2022 01:04:46 -0700 (PDT)
Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) (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 896653A0F04 for <dyncast@ietf.org>; Thu, 14 Apr 2022 01:04:46 -0700 (PDT)
Date: Thu, 14 Apr 2022 08:04:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=interpeer.io; s=protonmail; t=1649923483; bh=55AaT5Ln6drZgv7DAIv4Spo9nqEUc+6E50eD9O4Gwtw=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=EB7aNEoW9PTbkpfp8TbzzQ9qfDgy3pp+6BousljXBq877AvGelHpEYU6Bbf8hC6xd XpLxhwaili5YcXzlmVACj0DEBw/O1qwcfecaM5V0Gmo7jU9x0O6oywjOxTatCXWtcR P+WumF2zmjCwSkVl+M8PxT2tHptCUp5+zmSiIOu4=
To: "Joel M. Halpern" <jmh@joelhalpern.com>
From: Jens Finkhaeuser <jens@interpeer.io>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "dyncast@ietf.org" <dyncast@ietf.org>
Reply-To: Jens Finkhaeuser <jens@interpeer.io>
Message-ID: <-cMnlvrD41yA4jFLFnq05miZviasL1gTlFRQynruvhEEmy4EBvhLo5w5N3zgqgqZeDFiMjCaKb_XdyjO82eew53GwkOiMsVlPsIWOItDLj8=@interpeer.io>
In-Reply-To: <c5c8a8aa-d07b-e979-187f-c551a7d586c3@joelhalpern.com>
References: <2022041114360459722023@chinamobile.com> <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> <J9htmyzy6rQiH1ZLI5NDd-Pozrr3yS4uYbaHX46ugzsKJf941_zaQgYbQeJqrUSjQarb1Hg9oj7YOP-EpIhXe9XfxUu9Il4C8zeNBLmhP7E=@interpeer.io> <CO1PR13MB4920D3714A85DF4365B6B46285EC9@CO1PR13MB4920.namprd13.prod.outlook.com> <c5c8a8aa-d07b-e979-187f-c551a7d586c3@joelhalpern.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha512"; boundary="------ccc61de73b1cc734843076a82e1e96b1887cbfe5b001a26db352311d26f55ea4"; charset="utf-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/ngO3mRD275k8on0IDs1xrYE3AnE>
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: Thu, 14 Apr 2022 08:04:52 -0000

Hi,

Dirk and I have been separately discussing a use case in which UA moves, but service instances moving are in a way the same issue in reverse. See below.

------- Original Message -------
On Wednesday, April 13th, 2022 at 21:30, Joel M. Halpern <jmh@joelhalpern.com> wrote:


> 

> 

> With regard to the specific case of a UE / UA moving to a different cell
> tower or region, this is in fact one of the advantages of handling this
> at the application. Given that the ongoing application exchange has
> state at the server, you do NOT want to suddenly shift the client to a
> different server. As a setp one on mobility, you want to keep using the
> same server. Using the server unicast address from the UE / UA makes
> that work seemlessly.

The use case that I'm actively working on relates to drones, where changes in network attachment can happen at any time. At the same time, the service - in this case a ground control station steering the drone - may also need to move simply because the new network has a much better path to a different one (if we involve the use of private networks, this problem gets critical).

For regulatory reasons, the different networks may require the use of different radio technology, which may mean that the application needs to manage multiple radios. Our current approach here is to have an ingress router on the drone that manages radios and therefore network attachment and paths, which keeps the application agnostic of such changes. I think this approach would suit the CAN BoF work quite well; this ingress router can also make the optimal service choice from a compute perspective.

Merging this with the previous video use case I was mentioning, it may be that such an ingress router needs to be made aware of timeouts for each request, at which point returning responses is no longer of interest.

I understand that I'm considering solutions to specific use cases here, but as far as I understand, that's sort of the point for arriving at a generalized architecture, right?

Jens