Re: [icnrg] QuicR media delivery architecture

Dirk Trossen <dirk.trossen@huawei.com> Thu, 03 November 2022 08:12 UTC

Return-Path: <dirk.trossen@huawei.com>
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 73B17C14CF06 for <icnrg@ietfa.amsl.com>; Thu, 3 Nov 2022 01:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 zG9-nN-xPwL8 for <icnrg@ietfa.amsl.com>; Thu, 3 Nov 2022 01:12:49 -0700 (PDT)
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 E1DA0C14F739 for <icnrg@irtf.org>; Thu, 3 Nov 2022 01:12:48 -0700 (PDT)
Received: from frapeml500005.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4N2xJv6YP3z67Nc8; Thu, 3 Nov 2022 16:10:39 +0800 (CST)
Received: from lhrpeml500006.china.huawei.com (7.191.161.198) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 3 Nov 2022 09:12:45 +0100
Received: from lhrpeml500003.china.huawei.com (7.191.162.67) by lhrpeml500006.china.huawei.com (7.191.161.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Thu, 3 Nov 2022 08:12:45 +0000
Received: from lhrpeml500003.china.huawei.com ([7.191.162.67]) by lhrpeml500003.china.huawei.com ([7.191.162.67]) with mapi id 15.01.2375.031; Thu, 3 Nov 2022 08:12:45 +0000
From: Dirk Trossen <dirk.trossen@huawei.com>
To: Dirk Kutscher <ietf@dkutscher.net>, ICNRG <icnrg@irtf.org>
Thread-Topic: [icnrg] QuicR media delivery architecture
Thread-Index: AQHY70kvA9TBvtUlbkq9vw7WtgkAe64s13qA
Date: Thu, 03 Nov 2022 08:12:45 +0000
Message-ID: <f4b8d4d4b248406ebbcf36a1dec4be40@huawei.com>
References: <DDD40312-F9FD-494F-ABFA-EF059E17EA77@dkutscher.net>
In-Reply-To: <DDD40312-F9FD-494F-ABFA-EF059E17EA77@dkutscher.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.96.241]
Content-Type: multipart/alternative; boundary="_000_f4b8d4d4b248406ebbcf36a1dec4be40huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/pFSbyEkLtpfvtHunWxa1eFZ40_E>
Subject: Re: [icnrg] QuicR media delivery architecture
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: Thu, 03 Nov 2022 08:12:53 -0000

Hi Dirk,

Interesting contribution, also since it shows that ICN concepts (and the explicit reference to it) are making it more and more into IETF work.

In terms of provenance, it is difficult to pinpoint. Its pub/sub API links more to those ICN flavors having postulated such API, such as PSIRP/PURSUIT and even earlier the DONA work. But the relays are brokers (aka rendezvous in PSIRP/PURSUIT or rendezvous handler in DONA) and delivery topology in one, unlike those previous flavors, which separated control plane from data plane. So it is indeed something like a pub/sub API for CDNs, where the pub/sub is realized via the same CDN used for delivery and where the topic of the pub/sub constitute not just names but constraining selectors for the data.

Some lessons learned from ICN research is that the proposed design is an overlay, so scale is determined by the 'content' that the overlay will host. This is different from the scalability challenge of (at least early) ICN designs to scale the rendezvous system to Internet scale (with all the economic incentive problems that come with it, see some early PSIRP work on this in 2009 or so).

Hence, beyond the specific ICN angle, the work seems an almost natural extension of what CDNs do nowadays, just allowing for constraining the selection of what is being delivered. So kind of a new CDN interface. But the reference to ICN is indeed interesting and one can see this as recognizing the role that ICN played in popularizing such concepts.

Best,

Dirk

From: icnrg <icnrg-bounces@irtf.org> On Behalf Of Dirk Kutscher
Sent: 03 November 2022 06:57
To: ICNRG <icnrg@irtf.org>
Subject: [icnrg] QuicR media delivery architecture


Hello ICNRG,

in case you haven't seen Cullen Jennings' QuicR drafts:

Abstract:
This specification outlines the design for a media delivery protocol
over QUIC. It aims at supporting multiple application classes with
varying latency requirements including ultra low latency applications
such as interactive communication and gaming. It is based on a
publish/subscribe metaphor where entities publish and subscribe to
data that is sent through, and received from, relays in the cloud.
The information subscribed to is named such that this forms an
overlay information centric network. The relays allow for efficient
large scale deployments.

  *   https://datatracker.ietf.org/doc/draft-jennings-moq-quicr-arch/
  *   https://datatracker.ietf.org/doc/draft-jennings-moq-quicr-proto/

Looking forward to your thoughts...

Best regards,
Dirk

--

PGP fingerprint: 2D08387A195CD207853E1892278F4979A077CA8C