Re: [Mops] Some questions regarding draft Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure

Kyle Rose <krose@krose.org> Mon, 05 December 2022 14:06 UTC

Return-Path: <krose@krose.org>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B911CC14CEEA for <mops@ietfa.amsl.com>; Mon, 5 Dec 2022 06:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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=krose.org
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 s_DuSZ4aGytA for <mops@ietfa.amsl.com>; Mon, 5 Dec 2022 06:06:41 -0800 (PST)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972BEC14CE2A for <mops@ietf.org>; Mon, 5 Dec 2022 06:06:41 -0800 (PST)
Received: by mail-ej1-x62d.google.com with SMTP id n20so28111410ejh.0 for <mops@ietf.org>; Mon, 05 Dec 2022 06:06:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1b4qC6YfmZJsXmsICyjrPb+7loYpaTXxkEzmks9lCHE=; b=YqzUhU4hjh3/KeMDAOtSGgXWyJXJxkOsSk2z6L/1LtgflgSUtxF9g7FmHTSKrFW51K I15NklIhy2aDWil69Tqx8ApbZ84f6rX5SZjeCUYpyoynS2LYvbCHAnkz+0YyNogzXLUm Us0oZTaxeBy+pfFlWe1G7YNVlDipWKVtROnEE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1b4qC6YfmZJsXmsICyjrPb+7loYpaTXxkEzmks9lCHE=; b=foJducUkinJ+grJMmlIx4Z23CQKzatj3iCJirTqeVyS5TTB4ze/r/yJ1SPIxjiNbNL hNtW61m+V/ltzC3gZBfDQN4Yju17xeFOEur+OOr5nGVlghsocBbyFpbxJQCXIRBXt8JS 10jPVo8upvDTkETp6qjxS9A3PUwN1JK1sq8qivJ7gRLU8S43bKw3s9GeGLiPdD8/iejR QjLycGvo6dwQrRa6e1dh2Gt1YqyBm4ycb+/2dnMpWmuuyn0huctJdIFdCHwr5eutFOwG wfPj957Fkh1ERmVs99FfpcK6Vv2BHdUqZ+lcZuu8S6HXpX3ysK4UlJ9xVJ+jBokOX79D oOiA==
X-Gm-Message-State: ANoB5pkvcdrp/9/fOSpx1rA2Lq7HOqdFWQe2X+3jgtVNE0P/vT3qZGHT Q1an4NaFSBKN2T0vcx264CcZHP1tm7y2DpoxuAn+zA==
X-Google-Smtp-Source: AA0mqf7uW/z8Ym5jC386HkWOopPW0IIQJBPfY+unUoVRxAdRs9LVVo77GW9DWOOxTc+/CcyHMwYlvr0Z3YwUhvCfZ/A=
X-Received: by 2002:a17:906:2a9a:b0:7bb:e82a:83d with SMTP id l26-20020a1709062a9a00b007bbe82a083dmr42391749eje.612.1670249199603; Mon, 05 Dec 2022 06:06:39 -0800 (PST)
MIME-Version: 1.0
References: <DM4PR10MB6109F6CA3A6A4E1DAA385EDC97139@DM4PR10MB6109.namprd10.prod.outlook.com>
In-Reply-To: <DM4PR10MB6109F6CA3A6A4E1DAA385EDC97139@DM4PR10MB6109.namprd10.prod.outlook.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 05 Dec 2022 09:06:28 -0500
Message-ID: <CAJU8_nWrH+TPVKomqz+aw8oEA=8K-iJf_y2yBKmTOt4u5yV2Uw@mail.gmail.com>
To: Renan Krishna <Renan.Krishna@interdigital.com>
Cc: "mops@ietf.org" <mops@ietf.org>, "mops-chairs@ietf.org" <mops-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003ab14b05ef153223"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/cUJ1PxLk4N5AypdzfduodyBXJ1g>
Subject: Re: [Mops] Some questions regarding draft Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2022 14:06:45 -0000

Chair hat off...

On Mon, Nov 28, 2022 at 11:47 AM Renan Krishna <
Renan.Krishna@interdigital.com> wrote:

> Hi Everyone,
>
>
>
> Picking up the discussion from 115 about our draft titled "Media
> Operations Use Case for an Augmented Reality Application on Edge Computing
> Infrastructure", we are trying to identify issues in XR media delivery in
> an operational sense that would be within the scope of the MOPS WG and it
> would be great to get some pointers from the WG.
>
>
>
> 1) The first issue is - is offloading to the edge the only solution to
> deal with the problems of heat dissipation of the XR devices and their
> limited battery power as they run computationally intensive tasks in our
> use case?
>
>
>
>   *   Our draft focusses on leveraging the edge devices but we would
> welcome inputs from the WG that discuss other pertinent operational ways
> that could be solutions.
>

Just thinking from a first principles standpoint, it seems like the only
options for moving computing around are time- and space-shifting.

Space-shifting in this context means moving the computation off-device:
whether that needs to be at the edge (meaning, close to the endpoint) or
possibly somewhere more centralized depends entirely on the latency
requirement for what needs to be rendered, and thus runs into time-shifting.

Time-shifting in this context I would characterize in two ways: either
precomputation or accepting increased latency. Precomputation on-device is
likely to consume *more* energy, not less, by requiring the device to
compute information that might not get used, so unless you can precompute
only when the device is charging it's probably not a useful mechanism. That
leaves increased latency, which might save battery by precluding the need
to perform computation for elements that are visible only ephemerally. As
an example, think of spinning around quickly: do you really need detailed
information about everything in a 360° view? Probably not. Waiting until
the user will actually benefit from the rendering of annotation or other
rich information precludes the need to perform some computations entirely,
so in a real sense there is a tradeoff between acceptable latency and
energy use, even when all computation is performed on the device.

Kyle