Internet DRAFT - draft-cw-multiverse-icn
draft-cw-multiverse-icn
Network Working Group C. Westphal
Internet-Draft Futurewei
Intended status: Informational 10 July 2023
Expires: 11 January 2024
Multiverse and ICN: Use cases and challenges
draft-cw-multiverse-icn-00
Abstract
This document considers some use cases and issues for ICN support of
Metaverse-type applications.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Westphal Expires 11 January 2024 [Page 1]
Internet-Draft Multiverse-ICN July 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3
3. Metaverse Definition and Use Cases . . . . . . . . . . . . . 3
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ICN Challenges . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Metaverse Objects . . . . . . . . . . . . . . . . . . . . 6
4.2. Centralization . . . . . . . . . . . . . . . . . . . . . 7
4.3. Interoperability . . . . . . . . . . . . . . . . . . . . 7
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Informative References (TBD) . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The experience of a virtual world, simulated online, with
interactions with other people distributed over the real, physical
world, is close to being supported by networking technologies in the
near future. It is widely believed 6G networks will support enough
bandwidth and short enough RTTs to enable such Metaverse
applications.
However, there are challenges to deploy this type of application at
scale, due to their distributed and shared nature. A Metaverse
application will combine the properties of several existing
applications: the rendering of a virtual world on a display (either a
screen or a head-mounted display) draws similarity from streaming a
video (albeit with additional requirements); the interactions between
the users are related to social media as well as to video-
conferencing.
While the Metaverse application has different requirements from
social media, video streaming or video-conferencing, it inherits some
of their properties. In a Metaverse, two people can isolate in a
room and draw on a board to recreate a Zoom call with avatars. And
indeed, this type of collaboration is one of the potential use cases
brought forward by the Meta company. People would be connected with
their friends, and could grant access to their virtual world based
upon social connections. And a virtual world could be imagined that
recreates the design look and feel, the architecture of a movie, be
it that of a dark Gotham or the Paris of Amelie.
Westphal Expires 11 January 2024 [Page 2]
Internet-Draft Multiverse-ICN July 2023
Since applications such as video streaming, video conference, or
social media sharing have been considered as potential use cases for
ICN architecture, it seems natural to investigate if such
architecture would benefit the Metaverse use case.
This document attempts to define the framework for such an
investigation. This is similar to RFC7933 which considers the
interaction of ICN with adaptive video streaming.
2. Definitions and Acronyms
TBD
3. Metaverse Definition and Use Cases
First we need to define what we mean by "metaverse" and introduce
some taxonomy to help us refine the architectural requirements of
such an application.
3.1. Definition
We present here three definitions. We do not settle on one specific
definition, as it is not our scope to offer a definitive definition
of the metaverse, or to settle any debate about what is/what isn't a
metaverse. Rather we see in the different definitions a different
set of implications for the design of the application.
Defnition #1: “a 3D virtual shared world where all activities can be
carried out with the help of augmented and virtual reality services”
(Damar 2021)
Definition #2: “an integrated immersive ecosystem where the barriers
between the virtual and real worlds are seamless to users, allowing
the use of avatars and holograms to work, interact and socialize with
simulated shared experience” (Meta 2022)
Definition #3: “the next generation Internet that is always real-time
and mostly 3d, mostly interactive, mostly social and mostly
persistent” (John Ricobello)
Note that the first definition is an extension of an AR/VR framework;
the second definition includes an ecosystem, which assumes a set of
API to integrate multiple elements into the ecosystem; the last
definition views the metaverse as the replacement of the Internet,
that is a global scale application that supports an unlimited range
of applications and functions, with a requirement of persistence.
Westphal Expires 11 January 2024 [Page 3]
Internet-Draft Multiverse-ICN July 2023
3.2. Taxonomy
As with the definition of the metaverse, we can try to better define
what a metaverse is by way of a taxonomy that differentiates
according to different criteria. The dimensions that we consider are
listed below. This list is inspired by [dwivedi2022] but includes
additional dimension.
Environment: the environment can be realistic, unrealistic, fused;
the more realistic (or detailed) the more bandwidth is required;
conversely, some unrealistic environment can be generated and
rendered from some basic models that can be distributed ahead of
time. Part of the environment is also if it is generated anew or
permanent. In the latter case, it can be cached at the edge or on
the device.
Interface: the environment can be interacted with through an
interface that ranges from a simple phone screen to a 3D head-
mounted display (HMD), from a window into the virtual world into
an immersive experience; other physical methods to interface the
virtual environment (such as haptics) can be included as well.
Interaction: the level of interaction can be specific to the
virtual environment. It can be in one extreme a solitary
experience (such as playing game against a computer) and extend to
social networking, and/or work collaboration. The granularity of
the interaction also impacts the infrastructure requirements.
Security: it is paramount to protect the security and privacy of
the experience. This includes data security, privacy,
software/hardware/network security. Further, the granularity of
the security may include several layers, as for instance, only a
given set of participants can access a given shared metaverse; and
within this metaverse, only a subset can have access to objects or
rooms within.
Westphal Expires 11 January 2024 [Page 4]
Internet-Draft Multiverse-ICN July 2023
Centralization: this is not a characteristic of the metaverse
itself, rather a design choice on how to deploy such an
application over some infrastructure. However, this choice has an
impact on the infrastructure and needs to be considered.
Centralization of the metaverse, by hosting it on a specific set
of servers and have clients connect to these servers, facilitates
some aspects of the metaverse: for instance, it requires N
connections, where N is the number of users; it facilitate access
controls, as per the "security" item above. A fully distributed
architecture that is fully meshed would require N^2 (potentially
multicast) connections; further, these connections would need to
be time-synchronized. However, the latency of a direct path would
always be faster than a triangular routing through a server, and
therefore the interactions would be quicker.
This list may be modified with other important dimensions based upon
further discussion.
4. ICN Challenges
ICN Challenges for the Metaverse
ICN (cf [ahlgren2012survey] for a survey) is a novel network
architecture that considers objects as the organizationary principle
for the network infrastructure. Instead of connecting to a server,
ICN attempts to dissociate the objects from the server that could be
hosting them, and attempts to route requests for an object directly
to that object, rather than to a server that contains that object.
From the infrastructure perspective, a metaverse would be a
distributed system that shares content in real time on a massive
global scale, with some QoE requirements for the users, and in a
secure way with complex ownership/access privileges. This is exactly
the type of problem that ICN sets out to solve.
ICN has nice properties for fetching objects. In the case of
Adaptive Video streaming, where a video stream is decomposed into
chunks that correspond to a resolution and a time segment of the
original video, fetching these objects directly is attractive.
Popular videos will be distributed throughout the network, and
therefore, can be encountered before getting it from a high level
cache or an origin server.
RFC7933 considered the challenges of using ICN for video streaming
and immersive streaming applications. The objective of this document
is to similarly consider the impact of ICN on multiverse
applications, and conversely, the requirements of multiverse
applications on ICN architectures.
Westphal Expires 11 January 2024 [Page 5]
Internet-Draft Multiverse-ICN July 2023
Some of the points discussed in RFC7933 can be straightforwardly
mapped from video streaming to metaverse applications. For instance,
the interactions of video streaming and ICN maps to interactions of
metaverse applications on ICN; the integration of video streaming and
ICN similarly maps to a possible integration of metaverse application
with ICN. Encodings are also relevant in both contexts.
RFC7933 also discusses P2P video distribution, which could be map to
a distributed embodiment of the metaverse. IPTV inR RFC7933 brings
up issues of multipath and multicast transport. Finally, digital
rights management translate into how to manage access in the
metaverse.
We can list some of the research challenges for the Metaverse in ICN:
scalability; privacy/trust/security. Low-latency would be required
for such an interactive real-time application. As a corollory, high
precision transport layer could be an interesting challenge.
Machine learning could help with identifying behaviors within a
Metaverse to allow better operations (say by filtering out data that
is unlikely to be consumed, or by pre-fetching data that is likely to
be consumed; or by anticipating users' behavior).
One important question is the benefit overall of ICN for such an
application in terms of sustainability. Is an ICN-supported
Metaverse greener or more energy efficient than legacy applications?
Some other challenges are detailed a bit more in the following
subsections.
4.1. Metaverse Objects
Objects in the metaverse have different properties than for typical
ICN objects. Usually, as is the case in video streaming, an ICN
object is fetched as part of a group of objects. The application
layer then uses it as it chooses. A content owner provides keys for
the user to access/decrypt the data.
It sees the metaverse semantics impose other requirements on the
objects. In particular, the content ownership is more diffuse.
There are several layers into it, with different access rules.
For instance, in a virtual world, there is a provider of a virtual
world service, that would own objects pertaining to that virtual
world infrastructure; this world is populated by people/avatars and
objects that may want to control to whom they are visible; then they
can use/create/purchase/sell virtual objects, granting new set of
permissions to another layer of data.
Westphal Expires 11 January 2024 [Page 6]
Internet-Draft Multiverse-ICN July 2023
Permissions to view, use, operate, modify, take or remove a virtual
object becomes a more complex operation than just setting access
rights. Then meta-data should be associated with virtual objects to
keep track of events, accounting, transactions, etc, associated with
that virtual object.
Data pertaining to a virtual world could be collected into a FLIC
collection, or grouped together using some form of manifest (similar
to that used by DASH video streaming for instance). Other data
however would need to perform several level of access controls; how
to represent and organize such ownership levels, especially in a
distributed manner, seems like an interesting challenge for ICN.
4.2. Centralization
Centralization vs Distributed is one of the dimensions in the
taxonomy discussed above. If the metaverse is implemented as an
application overlay, then it can be easily centralized. However, if
the goal to to embed metaverse support into the network, then a
decentralized implementation may be necessary.
A hierarchical structure would be required to support the scale of
such application. This yields questions and challenges regarding
edge nodes running independently; or whether a part of the metaverse
can keep running if disconnected from a central authority.
ICN decouples objects from the origin server. This is a step towards
running a metaverse independently of a centralized server; however,
can the whole application be decoupled from an origin server? The
challenge would be to run Named Function Networking services for such
an application.
4.3. Interoperability
A metaverse should interoperate along multiple dimensions. John
Radoff lists as domains of interoperability: connectivity
(networking, communications); persistence (identity, ownership,
accounting, history); presentation (graphics models, physical
properties); meaning (metadata, semantics, ontologies); behavior
(rules, economies, consequences, power).
This documents focuses only on the lower layer, connectivity. One
key issue is to propose a common framework in ICN that would support
interoperability for communications.
Westphal Expires 11 January 2024 [Page 7]
Internet-Draft Multiverse-ICN July 2023
5. Conclusions
This document attempts to present some of the challenges of
supporting a Metaverse application within an ICN architecture. We
presented a taxonomy and listed some of the challenges. This is an
initial draft to initiate a discussion with the ICNRG.
6. IANA Considerations
This document does not have any IANA requests.
7. Security Considerations
No particular security considerations at this point.
8. Informative References (TBD)
[ahlgren2012survey]
Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D.,
and B. Ohlman, "A survey of information-centric
networking", IEEE Communications Magazine Vol.50 No.7,
2012.
[dwivedi2022]
al, Y. K. D. E., "Metaverse beyond the hype:
Multidisciplinary perspectives on emerging challenges,
opportunities, and agenda for research, practice and
policy", (Elsevier) International Journal of Information
Management Vol. 66, Oct 2022, 2022.
[RFC7933] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C.,
Azgin, A., Liu, W., Mueller, C., Detti, A., Corujo, D.,
Wang, J., Montpetit, M., and N. Murray, "Adaptive Video
Streaming over Information-Centric Networking (ICN)",
RFC 7933, DOI 10.17487/RFC7933, August 2016,
<https://www.rfc-editor.org/info/rfc7933>.
Author's Address
Cedric Westphal
Futurewei
Email: cedric.westphal@futurewei.com
Westphal Expires 11 January 2024 [Page 8]
