[icnrg] Some comments on draft-aw-metaverse-icn

"David R. Oran" <daveoran@orandom.net> Wed, 02 August 2023 15:37 UTC

Return-Path: <daveoran@orandom.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF02AC15108F for <icnrg@ietfa.amsl.com>; Wed, 2 Aug 2023 08:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=crystalorb.net header.b="kkS90TvK"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=crystalorb.net header.b="apqoW0VR"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgmTQCoXJgzV for <icnrg@ietfa.amsl.com>; Wed, 2 Aug 2023 08:37:18 -0700 (PDT)
Received: from crystalorb.net (omega.crystalorb.net [IPv6:2600:3c01:e000:42e::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD4DC151B16 for <icnrg@irtf.org>; Wed, 2 Aug 2023 08:37:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crystalorb.net; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject :To:From:From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uzhOjH2XMnxa7+bldwfjnEvK6/IiVHved6rJ/sfca/g=; b=kkS90TvKZYy0O3s29nMl6BecXV FJ18XLl1ML4KST2m2t5MvIes6Kamwy0rwOQKXfOpiZLZEjvfp55yPFpNBHR0glgNmO0ZI5JnmYSZb Ie7DN8PxBtZRAHBO2fEj9rfm6bih2/7n6ct5Bim4dW5xqyVSQDOXoKiBs2J4RIdfX92M=;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=crystalorb.net; s=omegamail; h=Content-Type:MIME-Version:Message-ID:Date: Subject:To:From:From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uzhOjH2XMnxa7+bldwfjnEvK6/IiVHved6rJ/sfca/g=; b=apqoW0VRpdtFZr+4AvJjMfL79w XQ9zb8ybWMpTjoRhbvpgG6mF4IRFZ34FSPYqPkLiBo3tO8zs5I/KoVz8LYAQ==;
Received: from [2601:184:407f:80cf:1e8:914:48aa:3f5e] (helo=[192.168.15.242]) by crystalorb.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <daveoran@orandom.net>) id 1qRDrU-0062QW-97 for icnrg@irtf.org; Wed, 02 Aug 2023 08:34:08 -0700
From: "David R. Oran" <daveoran@orandom.net>
To: ICNRG <icnrg@irtf.org>
Date: Wed, 02 Aug 2023 11:37:15 -0400
X-Mailer: MailMate (1.14r5937)
Message-ID: <339C8384-BE44-48F8-B54F-270131DBD00F@orandom.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_A5AB9562-0E0B-4BEC-9401-47D53A883B49_="; micalg="sha-256"; protocol="application/pkcs7-signature"
X-SA-Exim-Connect-IP: 2601:184:407f:80cf:1e8:914:48aa:3f5e
X-SA-Exim-Mail-From: daveoran@orandom.net
X-SA-Exim-Scanned: No (on crystalorb.net); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/ULvNzeoEcsKOemOvy4aWSjhGG5M>
Subject: [icnrg] Some comments on draft-aw-metaverse-icn
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Aug 2023 15:37:23 -0000

</Chair hat>

First, thanks for posting this draft as it forms a good basis for guiding future work on the the touch points between ICN and the emerging Metaverse applications.

<Chair hat>

I’d like to strongly encourage the ICNRG participants/community to contribute to this work!

</Chair hat>

I have a few comments you might find helpful in moving this work forward:

- In the intro you say “replacement of the Internet, that is a global scale application…”. I question this assertion as the Internet is the interconnection fabric and protocols that enable the applications; it is not an application itself. It might be better to say something like “an evolution of the Internet to support compelling Metaverse applications”. Also, it isn’t clear what you mean here by “requirement of persistence”. Persistence of what?

- In the Taxonomy section, on “interface” I wonder why you don’t emphasize multi-modal, adaptable interfaces, especially when considering the needs of visually impaired individuals for example (though such considerations are probably not the focus of this work). in fact, it might be really helpful to pull apart the characteristics the Taxonomy that strongly influence the protocol architecture needed to support the applications as opposed to the design and user experience of the applications themselves.

- On Interaction, it’s important to ask about timescale in addition to scope (where by scope I mean personal, to moderate collaborative, to global social interaction). Some timescales are below the RTT achievable by any general multi-hop technology (e.g. head tracking, eye tracking, possibly hand tracking). Others are RTT constrained by propagation latency over even modest distances (e.g. multiple milliseconds to even a local base station on a cellular network). Still others are constrained by factors like audio and video lag to 100–200ms at best. Some are constrained by user QoE expectations (e.g. transaction delay), and yet others are explicitly non-interactive and intentionally time decoupled. All of these can exist simultaneously in a rich Metaverse applications and need to be teased apart when talking about how they affect choices of networking protocols and algorithms.

- On security also pull apart meta-data as needing protection even in the absence of the ability to participate.

- On centralization, please pull apart technical centralization from administrative centralization. Also:
	- It isn’t clear what kind of “connections” are intended here. Clearly there has to be some kind of per-user state maintained somewhere, and that state evolved robustly over time, but that doesn’t mean that there have to be “connections” at the transport layer or below.
	- You say “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 is patently false on the current Internet which routinely violates the triangle inequality.

- In challenges, while you talk about “complex ownership/access privileges” this is the time to bring up the management of trust.

- What is a “high precision transport layer”?

- The paragraph on ML is pretty lame, Let’s have a discussion on how to beef that up. In particular, there’s an interaction between *using* ML to optimize various aspects of the system at *multiple layers*, and where both training and inference operations happen. Particularly for processing input video (as opposed to streaming it out) the placement of the computations strongly affect what the feasible topologies and deployment options are. There are of course also strong interactions with security and privacy.

- Where you say “Data pertaining to a virtual world could be collected into a FLIC collection,” I’m doubtful as FLIC is too primitive satisfy more than linear atomic objects of various sizes and simple hierarchical collections thereof. OTOH I think a manifest structure is absolutely critical to making an ICN system employing primitive objects at the network layer practical.

- I don’t understand the statement “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.” One can easily ignore the rich topology of the Internet and build metaverse support into a network architecture that centralizes the entire control plane even if the data place is decentralized (need I mention SDN???)

- The sentences “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.” are intriguing and desperately need more explanation. I can think of many interpretations of this, and interesting implications to each one.

- The punchline in 4.3. that “This document focuses only on the lower layer, connectivity.” really needs to be in the introduction in oder to set expectations appropriately.

- Let’s get more use cases. The Moonshot stuff is great though.



On 1 Aug 2023, at 15:44, internet-drafts@ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>    Title           : Metaverse and ICN: Challenges and Use Cases
>    Authors         : Cedric Westphal
>                      Hitoshi Asaeda
>    Filename        : draft-aw-metaverse-icn-00.txt
>    Pages           : 10
>    Date            : 2023-08-01
>
> Abstract:
>    This document considers some challenges for ICN support of Metaverse-
>    type applications.  Also, one use case is presented to promote one of
>    our future visions.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-aw-metaverse-icn/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-aw-metaverse-icn-00
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
DaveO