Re: [Dyncast] edge capability feedback

Dirk Trossen <dirk.trossen@huawei.com> Fri, 12 March 2021 07:59 UTC

Return-Path: <dirk.trossen@huawei.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 72A303A0E68 for <dyncast@ietfa.amsl.com>; Thu, 11 Mar 2021 23:59:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 nE0pKDmlF_tm for <dyncast@ietfa.amsl.com>; Thu, 11 Mar 2021 23:59:02 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5F73A0E60 for <dyncast@ietf.org>; Thu, 11 Mar 2021 23:59:01 -0800 (PST)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DxdMr4SbRz67xxg; Fri, 12 Mar 2021 15:52:56 +0800 (CST)
Received: from lhreml705-chm.china.huawei.com (10.201.108.54) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Fri, 12 Mar 2021 08:58:58 +0100
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml705-chm.china.huawei.com (10.201.108.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Fri, 12 Mar 2021 07:58:57 +0000
Received: from lhreml701-chm.china.huawei.com ([10.201.68.196]) by lhreml701-chm.china.huawei.com ([10.201.68.196]) with mapi id 15.01.2106.013; Fri, 12 Mar 2021 07:58:57 +0000
From: Dirk Trossen <dirk.trossen@huawei.com>
To: Carsten Bormann <cabo@tzi.org>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: dyncast <dyncast@ietf.org>
Thread-Topic: [Dyncast] edge capability feedback
Thread-Index: AQHXFh3mblcp9VvA7UuJxuHq54sAyap+InaAgAFpVLGAABbwgIAAP5WAgAAZU3A=
Date: Fri, 12 Mar 2021 07:58:57 +0000
Message-ID: <b5941a0414144d0ab958cb69b96c3786@huawei.com>
References: <20210311102435132657878@chinamobile.com> <9A6BA68B-3916-413E-BD29-62D4096DF1D3@senki.org> <00CCE76F-D3F8-49DD-8E11-29E7DBB956E1@huawei.com> <5EEEA7D8-D4E7-42AE-9D40-2DF6DF744567@chinamobile.com> <ea129e08-d5b2-5edb-a5ee-8362b12dc2b5@joelhalpern.com> <B930F50D-4A0C-4DAB-A3E5-0CD308CEB67F@tzi.org>
In-Reply-To: <B930F50D-4A0C-4DAB-A3E5-0CD308CEB67F@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.210.172.4]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dyncast/oKcDDT4rkYTlAHuuZdvlpAlGTSg>
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: Fri, 12 Mar 2021 07:59:03 -0000

Hi Carsten & Joel,

Please see inline.

Best,

Dirk

-----Original Message-----
From: Dyncast [mailto:dyncast-bounces@ietf.org] On Behalf Of Carsten Bormann
Sent: 12 March 2021 07:17
To: Joel M. Halpern <jmh@joelhalpern.com>
Cc: dyncast <dyncast@ietf.org>
Subject: Re: [Dyncast] edge capability feedback

On 12. Mar 2021, at 03:29, Joel M. Halpern <jmh@joelhalpern.com> wrote:
> 
> If the UE had a way to ask an informed server, there would be no need for the UE to have a "significant amount of new logics".
> And we would not have to worry about overloading routing with behavior and data that it does not need.  And we would naturally get the needed stickiness.

As far as I understand dyncast, I see the following two reasons for not simply falling back to an “ask a server” approach:

* Just-send.  See slide 35 on [1].  This assumes that saving that round-trip is a relevant consideration for some applications.  (It is hard to amortize the round-trip when progress (same slide) is needed; of course the client could proactively ask at the start of each new service period — but that creates a constant load.)

[DOT] this becomes even more of an issue if your periods are rather small, e.g., a few requests long, making the 'control load' a significant proportion of your overall efficiency. 
* The server may not know.  Even if the server is reached using anycast, it may not have a way to get input from the routing system that is knowledgeable about the specific network environment of the client.  This becomes relevant when the “last mile” provides choices and there is more than one edge server cluster close to the client.
[DOT] I may use a separate application-level server (the one 'who knows') pushing all metric information to that server who serves as a 'dispatcher' of sort, providing the D-BID to be used based on the latest information. But it comes back to the dynamicity issue above, also discussed in the Dyncast use case draft, leading to inefficiencies (possibly not meeting requirements of the applications). Complexity also arises since the 'one who knows' may not be well (enough) placed, requiring placement approaches for improving to support dynamicity. Again, the use case draft points this out.

It seems to me that dyncast has not previously been pursued mainly because there weren’t that many applications that could actually benefit from addressing these two considerations.  
[DOT] A healthy pushback, as in Joel's response, is often good. But you point at the main issue: behaviours may emerge (in the form of the applications you mention) that require an adjusted view on what routing should provide to them. That's why we've long evolved from the simple "send packet from source A to destination B" and have seen a plethora of input being used to make decisions, at least in parts of the network, here in Dyncast at the ingress point, i.e., the d-router. Adrian's presentation at the RTGWG yesterday pointed to an emerging discussion on this (and the draft discussing this at https://tools.ietf.org/html/draft-king-irtf-challenges-in-routing-01).

Grüße, Carsten

[1] https://github.com/dyncast/ietf110/blob/main/dyncast-ietf110-side-meeting-full-deck.pdf

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