[T2TRG] edge computing breakout session notes
"Dirk Kutscher" <ietf@dkutscher.net> Wed, 19 April 2017 08:11 UTC
Return-Path: <ietf@dkutscher.net>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25AA13155A for <t2trg@ietfa.amsl.com>; Wed, 19 Apr 2017 01:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] 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 BjuWYNY_EbYd for <t2trg@ietfa.amsl.com>; Wed, 19 Apr 2017 01:11:20 -0700 (PDT)
Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F547131560 for <T2TRG@irtf.org>; Wed, 19 Apr 2017 01:11:19 -0700 (PDT)
Received: from [192.168.44.151] ([82.113.121.34]) by mrelayeu.kundenserver.de (mreue101 [212.227.15.183]) with ESMTPSA (Nemesis) id 0MPp3a-1cvmdC1mcc-004yT4 for <T2TRG@irtf.org>; Wed, 19 Apr 2017 10:11:17 +0200
From: Dirk Kutscher <ietf@dkutscher.net>
To: T2TRG@irtf.org
Date: Wed, 19 Apr 2017 10:11:08 +0200
Message-ID: <AD6616AD-FFD9-46F7-9A4B-B03C95734AE4@dkutscher.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_MailMate_4732FA89-38EF-410E-A47A-A25C1A6D93D0_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
X-Provags-ID: V03:K0:zWzIYSEOZnukzlisFWQ4rVvLVPsHf//a+DjVKQxkMqc8p3XFkmG kOv2YxJU8lOULVYGcIkf3BFs5bqEz+hYRManAQVA4NLP8re/ghOCQFy7d5inKG8Cowas6UY u+4/9f6SdBaxb+xGGYzl7cFKOqGvoacjfsQ0UmGelvlBOwykO9uwaXnPxlzrFevmV/JBXPx ncrcU8qAeQBR+Z0TvAWfA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Vd8Tc10YkHw=:6aB/pkvo8HNmm1sXB0L/XP xqc8hmR8jpjdD0hrY0my+V3vEr7/V5WDV60+KdomLtWi/JZF9At6uEQddI30w0YHggwR4Wus+ ih3l94gPGl418MyoJzGaHjiNEa7CZxvHrAq+Qjzm3igbDzeib3ns8Tq423wN/NwAEg8LzqAp8 uy5C++IN0vOeE0Sc1YNPAwjqYHjvLk5SwKOa9Z08I5R3E0jVg6KzxCnjPk8+V5TEaJzO7ko9s hheceC4I/URigM9s953fsNeRxcVGfjGMclgi6jjdazBuDX8MU1jIXVKO5xXtxuLPYzfPIvkaE Bm46Wzf9dEypcDRdmd7gprLOOjji59NP0zEQFy2eSqg7KwtfpK15ca6k62yZO1wARZinKMIKV FDysNlOrS8jPPnLVnNDneCIhGHy9buxBzww1O/Ep6KFl/fVLkEOup0zSZ4+ig0T3ITfP0wj/6 94d/acKQLDdST0viOYfr3o1Sh0xIWrkC0zPFDKYEUI04V4E3QmyNmjoK3xZmtJ/JKo625DQXK 2oVhRh3xu5JfpA9K/B8oF9wp8DqQYwccnY9le06jLrRMt2uy4jLXQ0ho0DbnSvq/kMIWt0JBa xMxo0u8jOSj1UKj0dUf67rH9xiLeQfkv3U+ahNgGqWLjsHJUAewn2BUT53e0CcjupYttrwECL NxhvLiKiELq7XMjPC9Ouu9BToCxeEODOAOMki2eoue2PJAuI1GX5DVXGfxpyuKApJb8j+/Jfu mWG9EnYpJtWG7J3q
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/dVW26uacvjASmbABcz22C9r3RRU>
Subject: [T2TRG] edge computing breakout session notes
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IRTF Thing-to-Thing \(T2T\) Research-Group-in-creation" <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Apr 2017 08:11:26 -0000
Hi all, Eve and I managed to write up the notes from the edge computing breakout session at T2TRG@IETF98. Thanks to everyone who participated. Unfortunately, we don’t have your names, but let us know if you want your name to be added. Also, please let us know in case you have any suggestions for modification etc. I am also attaching a slightly nicer formatted PDF version… Thanks, Dirk T2TRG Edge Computing Break Out Discussion at IETF-98 ==================================================== Dirk Kutscher and Eve Schooler (on behalf of breakout session team at T2TRG meeting) We discussed three main topics: 1) Motivation for Edge Computing, 2) Terminology, and 3) Research Questions. The Motivation for Edge Computing ================================= IoT deployments generate an increasing amount of data at the network edge, which reverses today’s dominant data flow direction compared to how the network was designed and provisioned. Data is no longer primarily sent downstream (i.e., from the cloud to the edge), but increasingly is generated at the network edge, then processed and/or consumed locally, before possibly being transmitted upstream in the direction toward the cloud, to other Internet hosts, including cloud-based consumers. Much of the data is generated by applications with requirements unmet by the current cloud infrastructure: support for high data volume, time sensitivity, trust sensitivity, intermittent (dis)connectivity, and the need for energy efficiency and reduced costs. As a result, cloud functionality (compute, storage, networking, control, etc.) is migrating to be more proximate to the data, leading to what is referred to as “edge computing” or “edge clouds”. With the expected high data volume and limited uplink bandwidth to the Internet, it may not be possible to transmit data in its original format, particularly streaming data, which is generated continuously. In these scenarios, local processing (e.g., filtering, compression, transcoding, aggregation, analytics, etc.) may be required to enable meaningful data and connectivity management. Such filtering and aggregation could be seen as an application-independent edge computing capability in a data-oriented IoT approach. Moreover, certain IoT deployments, for example factory automation, may exhibit strong time sensitivity and/or trust sensitivity with respect to data communication and processing. For example, the back-end cloud might simply be” too far away” (i.e., the roundtrip time is too long) for the timing constraints of the control loop for certain industrial IoT applications. Furthermore, it may not be desirable nor legal to transmit and process data remotely because of data privacy policies. For instance, in the healthcare industry and in manufacturing scenarios that are sensitive to the leakage of intellectual property, the data may be too sensitive for it to leave the local premises. In such cases, local data processing and analytics at the edge are required. Depending on the nature of the interaction between the IoT edge cloud and the properties of access networks, keeping data and processing local also helps with energy efficiency and cost reduction. Finally, there are usages where the connectivity to the cloud is prohibitively expensive (e.g., satellite communications for an oil rig or an airplane), rendering the network effectively disconnected. Still other use cases, where device mobility, radio interference, or energy conservation render the network only intermittently connected. Additionally there are IoT deployments that require autonomy and as such cannot rely on Internet connectivity at all. Thus Edge computing would be necessary when the cloud is inaccessible. Terminology =========== We raised many questions, discussed relevant terms, and posed ideas. * What is the edge? * What is the edge a boundary between? For example, the edge might differ in definition for the Telcos versus other service providers * Moving from edge computing to fog computing (a multi-tiered cloud of clouds) creates additional edges * Edge computing is a first step toward re-imagining the data center * Edge computing moves cloud computing functionality closer to the edges of the network and closer to the Things that comprise that edge * Compute, storage, networking, control, actuation - all will be distributed beyond the confines of a back-end cloud * What will the data center look like as it moves out of the back-end cloud and closer to the edge? * Edge dynamics supports (mobile) edge computing * How dynamically can edges be created? * How dynamically would we like or need to distribute computation, storage, etc.? * Edge computing is more than computation on a gateway * Edge computing is often equated with the first-hop gateway in the direction from Things to the cloud * Edge computing however also could be viewed as the ensemble of resources that are willing to logically defined as an “edge cloud” * Not limited to specific platforms and execution environments Research Questions ============ We discussed the following research questions: * Programming models * How would people develop applications that can leverage edge computing? * What distributed constructs require support? * How to steward, curate, route, cache, process, migrate, archive the edge device data? * Networking and operations * Compute function description * Compute function discovery * Assembly of individual functions into larger blocks, applications & services * Orchestration of edge computing systems * Managed vs. unmanaged edge computing * Isolation * How would individual tenants and compute functions be isolated in a decentralized cloud environment? * What would be granularity levels for edge compute functions? * Containers * Step functions * Stateless functions * Named Function Networking as in ICN * Multi-X * Multi-application, multi-user, multi-tenancy * Edge Computing in multi domain networks Discussion ======= Finally, we discussed the following additional topics and ideas: * Difference between Edge Computing and Data Center Computing * Would edge computing rely on completely new abstractions and mechanisms or would it be compatible with existing data center distributed computing platforms? * As in, would edge computing re-use existing cloud service provider APIs? * Usability of Edge Computing * With increased levels of dynamics, scalability, and group data sharing, how to extend existing eco-system components (e.g., data/meta-data registries) to support? * How to make distributed system interfaces intuitive and consistent? * From “Pet” to “Cattle model” * In the presence of ubiquitous, cheap IoT deployments, how carefully should/can Edge Computing deployments be crafted? * What would be security and availability implications? * “Rackscale for Edge Computing” * Will there be established models for disaggregating network, storage, compute for the edge? * Will Edge computing rely on similar automation and operations support functions (infrastructure management, telemetry)? * Will Edge computing rely on standards for software-defined networking to dynamically configure and reconfigure resource pools? * Networking Edge Computing * What would be appropriate communication models to support Edge Computing? * How will Edge Computing affect existing protocols? * If edge computing and cloud computing represent two ends of an evolving cloud computing spectrum, how to seamlessly evolve edge computing to fog computing? * Will there be a difference between intra-cloud and inter-cloud communication in Edge/Fog computing? * Will different technologies be needed to support upstream vs downstream data flows? * Might Information-Centric concepts be helpful (cf. Named Function Networking)? Since ICNs already combine routing with native caching in the network, could they be extended to support processing for data in-flight as well (e.g., at the aggregation points in the reverse data flow paths)?
- [T2TRG] edge computing breakout session notes Dirk Kutscher