REVIEW 5 major objections 4 minor 29 references
INDS: Incremental Named Data Streaming for Real-Time Point Cloud Video
T0 review · 5 major / 4 minor · reviewed 2026-08-15 · deepseek-v4-flash
Pith's one-line read INDS claims that naming octree point-cloud layers as cacheable chunks cuts end-to-end delay by up to 80% over DASH-style streaming.
desk verdict A legitimate systems contribution that maps octree point-cloud layers onto NDN names and backs it with a real MiniNDN prototype, but the headline gains over DASH are only as trustworthy as the under-specified baselines. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The load-bearing mechanism is a hierarchical name that binds the octree's dependency structure to ICN's named-data retrieval. A name such as /PointCloudService/DataSetID/TimeWindow_20240314T120000/GoF_0001/LastLayer/30 identifies one 30-frame Group-of-Frames, one spatial layer, and one sampling ratio; consumers send Interests (named requests) for exactly these names, and routers answer from cache, aggregate duplicate Interests, or forward toward the producer. The producer-side counterweight is uniform sampling of the octree's last level at 30%, 50%, 75%, and 100%, which converts available bandwidth into an explicit quality step and spreads residual points evenly in space so partial loss degrades gracefully. Together, the naming and sampling turn the octree's parent-child dependency into the same dependency the network enforces: you cannot retrieve a child layer before its parents, and you never retrieve more than you will render.
What would settle it
Run the same comparison with an independent implementation of DASH-PC and PCC-DASH that follows the original papers' adaptive-bitrate algorithms, segment durations, and TCP settings on the same 8i sequences and 0-1% packet-loss profile. If their delay stays below 45 ms at 10 Mbps or their throughput at 1% loss comes within a few percent of INDS's, the claimed 80% delay and 15-50% throughput advantages would not reproduce.
Extended reading notes
Core claim
The central claim is that the octree hierarchy of compressed point-cloud video can be used as the network's retrieval hierarchy. INDS names each reconstruction level as a first-class, cacheable object—service/dataset/time-window/Group-of-Frames/layer, with layer values such as TopLayer, LastLayer/30, enhanced30-50, enhanced50-75, and enhanced75-100—so a consumer requests the base 30% layer first and upgrades progressively. The producer stores only the highest-quality version and uniformly samples the octree's last level at 30%, 50%, 75%, and 100% to create graceful degradation steps; ICN routers cache each named chunk and aggregate duplicate requests, making loss recovery local to a small chunk rather than a full segment. In an emulated testbed with four 8i sequences at 10-80 Mbps and 0-1% packet loss, the paper reports that INDS holds average delay under about 40 ms at 10 Mbps while DASH-PC and PCC-DASH exceed 230 ms, keeps over 85% of throughput at 1% loss, and reaches 73-76% cache hits versus roughly 50% for the baselines. These results are offered as evidence that named, incremental layer retrieval is a scalable and cache-friendly foundation for real-time point cloud streaming.
Load-bearing premise
The reported performance gains assume the DASH-PC and PCC-DASH baselines built in the emulated testbed are faithful, fairly tuned implementations of those systems; if they were simplified stand-ins, the measured delay, throughput, and cache-hit advantages would be artifacts of the comparison rather than properties of INDS.
Editorial extensions
If this is right
- Bandwidth directly sets reconstruction quality: a 10 Mbps client gets a usable base-plus-30% cloud, while an 80 Mbps client accumulates all enhancement segments and reaches full fidelity.
- Named chunks become reusable across viewers: within a time window, multiple consumers asking for the same layer are served from cache, keeping cache hit rates in the 73-76% range even at 1% packet loss.
- Loss recovery is no longer a whole-segment event: a missing chunk is re-requested by name from the nearest cache, avoiding TCP's congestion-window collapse and explaining the reported sub-40 ms delay at 10 Mbps under loss.
- Producers shed storage and compute: a single full-quality version plus sampled last-level files replaces multi-version ladders and removes re-encoding from the streaming loop.
- Because INDS is overlay-oriented and its chunk names align with Media-over-QUIC objects, its delivery model can be adopted incrementally on QUIC-based infrastructure rather than requiring a clean-slate network.
Reading between the lines
- Editorial inference: the naming scheme is not octree-specific; the same time-window/GoF naming could wrap k-d tree or bounding-volume hierarchies, so INDS may generalize to other volumetric codecs that expose layered spatial detail.
- Editorial inference: the experiments use uniform 0-1% packet loss; real wireless channels produce bursty, correlated loss, and whether local chunk recovery still wins under such traces is a testable extension the paper does not run.
- Editorial inference: the cache-hit numbers come from ten consumers sharing a 30-frame window; a mixed-viewer workload spread across many windows would stress the temporal naming granularity and is the natural next stress test.
- Editorial inference: if MoQ is deployed, INDS suggests a concrete migration path—CDN caches store individual enhancement objects under MoQ namespaces, gaining layer-selective caching and multi-source retrieval without new transport protocols.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper proposes INDS, an ICN/NDN-based streaming framework for octree-compressed point cloud video. INDS uses a hierarchical naming scheme over time-windows and Groups-of-Frames, lets consumers fetch base and enhancement layers incrementally via Interest/Data exchanges, and relies on in-network caching to improve reuse and resilience. The authors implement a MiniNDN prototype with real NFD forwarders and evaluate it against DASH-PC and PCC-DASH at 10/50/80 Mbps with packet loss from 0% to 1%, reporting up to 80% lower delay, 15-50% higher throughput, and 20-30% higher cache hit rates. The paper also claims that INDS can be deployed as an overlay compatible with QUIC and future MoQ architectures, although no MoQ/QUIC implementation is presented.
Significance. If the quantitative results hold, INDS is a useful and timely contribution: it applies ICN's incremental retrieval and in-network caching to the hierarchical octree structure of point cloud video, a problem where coarse-grained DASH-style delivery is arguably a poor fit. The use of a real MiniNDN prototype with NFD forwarders and the public 8iVFB dataset is a strength, as is the concrete naming design with time windows and GoFs. However, the central quantitative claims currently rest on an under-specified comparison against DASH-PC and PCC-DASH. The baseline configuration, cache fairness, and statistical rigor all need substantial strengthening before the reported numbers can be taken as evidence for the system's advantages. The overlay/MoQ compatibility claim is also presented as a headline feature but is not validated by any implementation or experiment.
major comments (5)
- [Section 5.1, Figures 8-9] The DASH-PC and PCC-DASH baselines are described only as 'parallel TCP/IP-based topologies' with a three-tier CDN architecture and 'matched bandwidth profiles.' The ABR algorithms, MPD representation ladders, segment durations, HTTP/TCP parameters, cache sizes, and cache policies of the baselines are never specified. Because the abstract's headline gains (up to 80% lower delay, 15-50% higher throughput) are measured against these baselines, the comparison must be controlled. Without a full description or a code release of the baseline implementations, the reported improvements could be artifacts of a strawman configuration rather than properties of INDS. I ask that the authors either release the baseline code/configuration or provide complete, itemized settings and re-run the comparison.
- [Section 5.4, Figure 7] The cache-hit comparison is not apples-to-apples. For INDS, the paper states 'Caches employ a standard LRU policy (65,536 packets per node)', while DASH-PC and PCC-DASH are said to cache at 'frame-level granularity', but no cache size, byte budget, or eviction policy is reported for the TCP/IP-based caches. Hit rate depends directly on object granularity and request patterns, so a chunk-level ICN cache and a frame-level HTTP cache can produce very different hit rates even under identical workloads. To support the claimed 20-30% cache-hit advantage, the authors need equal cache capacities in bytes and matched workloads, with the baseline cache behavior described in detail.
- [Sections 4.1 and 4.2] Section 4.1 states that the producer 'only stores the highest-quality content and responds passively to Interests without re-encoding' and the contributions describe a 'single-version storage model.' Section 4.2 then describes uniform downsampling of LastLayer to 30%, 50%, and 75% retention, but it does not specify whether these layers are precomputed and stored or selected/generated on demand from the full layer. If they are precomputed, the single-version storage claim is inaccurate; if they are generated on the fly, the 'no re-encoding' claim requires a precise definition of what processing is allowed. This ambiguity affects a stated contribution and should be resolved.
- [Sections 1 and 6] The abstract and conclusion state that INDS 'can be deployed as an overlay, remaining compatible with QUIC-based transport infrastructure as well as future Media-over-QUIC (MoQ) architectures.' However, Section 1 explicitly says 'a full MoQ-based prototype is beyond the scope of this work' and describes the mapping to MoQ as only 'conceptually aligned.' No QUIC or MoQ implementation, protocol mapping, or measurement is provided. This is a load-bearing overclaim in the abstract. The authors should either implement and evaluate the overlay path or explicitly reframe the MoQ compatibility as a design conjecture rather than a demonstrated property.
- [Sections 5.5-5.6] The delay and throughput results in Figures 8 and 9 are reported as averages or point values, but the paper gives no number of experimental trials, no error bars, and no confidence intervals anywhere in Section 5. Since the prototype runs real NFD forwarders and real TCP stacks in emulated containers, run-to-run variability is expected. Claims such as 'maintaining average delay below 40 ms even under 1% packet loss' and 'up to 75% lower delay' are therefore not statistically substantiated. The authors should report repeated runs and dispersion measures for all headline metrics.
minor comments (4)
- [Section 4.1] There is a typo: 'NDS does not require re-encoding' should read 'INDS does not require re-encoding.'
- [Section 5.1] The maximum evaluated packet loss is 1%, yet Section 5.6 refers to 'heavy loss' and 'high-loss scenarios.' A 1% uniform random loss is a relatively mild network condition; the resilience claims should be re-scoped or evaluated at higher loss rates.
- [Section 5.2] The PSNR/SSIM evaluation in Section 5.2 is performed offline on the compressed point clouds and is not linked to the network experiments: it is unclear how the four enhancement levels map onto the actual Interest/Data exchanges measured in Sections 5.3-5.6. A sentence connecting these quality levels to the streaming evaluation would improve readability.
- [Section 5.5] The sentence 'We evaluate delays in the 20-50 ms range because prior work [9] has shown...' is confusing, since the experiments do not appear to target a delay range. The authors likely mean that the chosen evaluation contexts correspond to that latency regime; please rephrase.
Circularity Check
No circularity: INDS is an empirical systems evaluation with no fitted-parameter-as-prediction or self-citation load-bearing argument.
full rationale
INDS is a systems paper whose central claims are validated by prototype measurements, not by a derivation chain that could collapse into its own inputs. The proposed mechanism uses ICN naming and Interest/Data exchange to retrieve octree enhancement layers incrementally, and the reported delay, throughput, and cache-hit improvements are presented as experimental comparisons against DASH-PC and PCC-DASH in emulated topologies. There is no fitted parameter that is later renamed as a prediction, no uniqueness theorem invoked from the authors' prior work, and no ansatz smuggled in via citation. The only self-citations, references [1] and [27], are background material (an ICN survey and a networked-metaverse position paper) and are not load-bearing for any quantitative result. The evaluation is self-contained in the sense that the quality metrics (PSNR/SSIM), cache-hit rates, delays, and throughputs are measured against external baselines and a public dataset (8iVFB v2), not derived from the paper's own definitions. The underspecification of the DASH-style baselines noted in Section 5.1 is a legitimate experimental-fairness and reproducibility concern, but it is not circularity: an unfair baseline can make a result overstated without making it equivalent to its inputs. Since no circular step can be exhibited with a quote-and-reduction, the appropriate finding is no significant circularity, score 0.
Assumptions & free parameters
free parameters (1)
- Enhancement level retention ratios =
30%, 50%, 75%
assumptions (3)
- domain assumption NDN/ICN forwarders provide in-network caching and Interest aggregation as implemented in NFD
- domain assumption Consumers can decode point clouds reconstructed from a uniform 30-75% sample of the LastLayer
- domain assumption The 8iVFB dataset and the 10-consumer MiniNDN topology represent realistic point cloud streaming workloads
Cite this review
Pith. "Pith review of INDS: Incremental Named Data Streaming for Real-Time Point Cloud Video." pith.science (2026). https://pith.science/paper/UZGXOCEG
@misc{pith2026250813756,
author = {Pith},
title = {Pith review of: INDS: Incremental Named Data Streaming for Real-Time Point Cloud Video},
year = {2026},
howpublished = {\url{https://pith.science/paper/UZGXOCEG}},
note = {Machine review of arXiv:2508.13756}
}
read the original abstract
Real-time streaming of point cloud video, characterized by massive data volumes and high sensitivity to packet loss, remains a key challenge for immersive applications under dynamic network conditions. While connection-oriented protocols such as TCP and more modern alternatives like QUIC alleviate some transport-layer inefficiencies, including head-of-line blocking, they still retain a coarse-grained, segment-based delivery model and a centralized control loop that limit fine-grained adaptation and effective caching. We introduce INDS (Incremental Named Data Streaming), an adaptive streaming framework based on Information-Centric Networking (ICN) that rethinks delivery for hierarchical, layered media. INDS leverages the Octree structure of point cloud video and expressive content naming to support progressive, partial retrieval of enhancement layers based on consumer bandwidth and decoding capability. By combining time-windows with Group-of-Frames (GoF), INDS's naming scheme supports fine-grained in-network caching and facilitates efficient multi-user data reuse. INDS can be deployed as an overlay, remaining compatible with QUIC-based transport infrastructure as well as future Media-over-QUIC (MoQ) architectures, without requiring changes to underlying IP networks. Our prototype implementation shows up to 80% lower delay, 15-50% higher throughput, and 20-30% increased cache hit rates compared to state-of-the-art DASH-style systems. Together, these results establish INDS as a scalable, cache-friendly solution for real-time point cloud streaming under variable and lossy conditions, while its compatibility with MoQ overlays further positions it as a practical, forward-compatible architecture for emerging immersive media systems.
Figures
Figures from the paper (6 more)
Reference graph
Works this paper leans on
- [1]
-
[2]
Mike Bishop. 2022. RFC 9114: HTTP/3
work page 2022
-
[3]
Alexander Clemm, Maria Torres Vega, Hemanth Kumar Ravuri, Tim Wauters, and Filip De Turck. 2020. Toward truly immersive holographic-type communication: Challenges and solutions.IEEE Communications Magazine58, 1 (2020), 93–99
work page 2020
-
[4]
Eugene d’Eon, Bob Harrison, Taos Myers, and Philip A Chou. 2017. 8i voxelized full bodies-a voxelized point cloud dataset.ISO/IEC JTC1/SC29 Joint WG11/WG1 (MPEG/JPEG) input document WG11M40059/WG1M740067, 8 (2017), 11
2017
-
[5]
Chavoosh Ghasemi, Hamed Yousefi, and Beichuan Zhang. 2021. Internet-Scale Video Streaming over NDN.IEEE Network(Sept. 2021)
work page 2021
-
[6]
Bo Han, Yu Liu, and Feng Qian. 2020. ViVo: Visibility-aware mobile volumetric video streaming. InProceedings of the 26th annual international conference on mobile computing and networking. 1–13
work page 2020
-
[7]
Bing Han, Xiaofei Wang, Nakjung Choi, Ted Kwon, and Yanghee Choi. 2013. AMVS-NDN: Adaptive mobile video streaming and sharing in wireless named data networking. In2013 IEEE Conference on Computer Communications Work- shops (INFOCOM WKSHPS). IEEE, 375–380
work page 2013
-
[8]
Mohammad Hosseini and Christian Timmerer. 2018. Dynamic adaptive point cloud streaming. InProceedings of the 23rd Packet Video Workshop. 25–30
work page 2018
Show all 29 references
-
[9]
Luke Hsiao, Brooke Krajancich, Philip Levis, Gordon Wetzstein, and Keith Win- stein. 2022. Towards retina-quality VR video streaming: 15ms could save you 80% of your bandwidth.SIGCOMM Comput. Commun. Rev.52, 1 (March 2022), 10–19. doi:10.1145/3523230.3523233
2022
-
[10]
Kaiyuan Hu, Yongting Chen, Kaiying Han, Boyan Li, Haowen Yang, Yili Jin, Junhua Liu, and Fangxin Wang. 2025. LiveVV: Human-Centered Live Volumetric Video Streaming System.IEEE Internet of Things Journal(2025)
2025
-
[11]
Jana Iyengar, Martin Thomson, et al. 2021. QUIC: A UDP-based multiplexed and secure transport. InRFC 9000
2021
-
[12]
Van Jacobson, Diana K Smetters, James D Thornton, Michael F Plass, Nick Briggs, and Rebecca L Braynard. 2009. Networking named content. InProceedings of the 5th international conference on Emerging networking experiments and technologies. 1–12
2009
-
[13]
Cullen Jennings, Zaheduzzaman Sarker, and Jake Holland. 2023. Media Over QUIC Architecture. https://datatracker.ietf.org/doc/draft-ietf-moq-architecture/. IETF MoQ Working Group Draft
2023
-
[14]
Bob Lantz, Brandon Heller, and Nick McKeown. 2010. A network in a laptop: Rapid prototyping for software-defined networks. InProceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets). 1–6
2010
-
[15]
Kyungjin Lee, Juheon Yi, Youngki Lee, Sunghyun Choi, and Young Min Kim
-
[16]
Kai Lei, Shangru Zhong, Fangxing Zhu, Kuai Xu, and Haijun Zhang. 2018. An NDN IoT Content Distribution Model With Network Coding Enhanced Forward- ing Strategy for 5G.IEEE Transactions on Industrial Informatics(June 2018)
2018
-
[17]
Tejesh Marian, Yihan Yu, Alexander Afanasyev, and Beichuan Zhang. 2017. Mini- NDN: A Miniaturized NDN Emulator. InProceedings of the IEEE International Conference on Communications (ICC). IEEE, 1–7
2017
-
[18]
Jounsup Park, Philip A Chou, and Jenq-Neng Hwang. 2019. Rate-utility optimized streaming of volumetric media for augmented reality.IEEE Journal on Emerging and Selected Topics in Circuits and Systems9, 1 (2019), 149–162
2019
-
[19]
Benjamin Rainer, Daniel Posch, and Hermann Hellwagner. 2016. Investigating the Performance of Pull-Based Dynamic Adaptive Streaming in NDN.IEEE Journal on Selected Areas in Communications(Aug. 2016)
2016
-
[20]
Jonnahtan Saltarin, Eirina Bourtsoulatze, Nikolaos Thomos, and Torsten Braun
-
[21]
Ruwen Schnabel and Reinhard Klein. 2006. Octree-based Point-Cloud Compres- sion.PBG@ SIGGRAPH3, 3 (2006)
2006
-
[22]
Iraj Sodagar. 2011. The mpeg-dash standard for multimedia streaming over the internet.IEEE multimedia18, 4 (2011), 62–67
2011
-
[23]
Thomas Stockhammer. 2011. Dynamic adaptive streaming over HTTP– standards and design principles. InProceedings of the second annual ACM conference on Multimedia systems. 133–144
2011
-
[24]
Jeroen Van Der Hooft, Tim Wauters, Filip De Turck, Christian Timmerer, and Hermann Hellwagner. 2019. Towards 6dof http adaptive streaming through point cloud compression. InProceedings of the 27th ACM International Conference on Multimedia. 2405–2413
2019
-
[25]
Fan Wu, Wang Yang, Ju Ren, Feng Lyu, Xiaojie Ding, and Yaoxue Zhang. 2020. Adaptive Video Streaming Using Dynamic NDN Multicast in WLAN. InIEEE INFOCOM 2020 - IEEE Conference on Computer Communications Workshops (IN- FOCOM WKSHPS). IEEE, Toronto, ON, Canada
2020
-
[26]
Lixia Zhang, Alexander Afanasyev, Jeffrey Burke, Van Jacobson, KC Claffy, Patrick Crowley, Christos Papadopoulos, Lan Wang, and Beichuan Zhang. 2014. Named data networking.ACM SIGCOMM Computer Communication Review44, 3 (2014), 66–73
2014
-
[27]
Yulong Zhang, Dirk Kutscher, and Ying Cui. 2024. Networked metaverse systems: Foundations, gaps, research directions.IEEE Open Journal of the Communications Society(2024)
2024
-
[2017]
Adaptive Video Streaming With Network Coding Enabled Named Data Networking.IEEE Transactions on Multimedia(Oct. 2017)
2017
-
[2020]
InProceedings of the 26th Annual International Conference on Mobile Computing and Networking
GROOT: A real-time streaming system of high-fidelity volumetric videos. InProceedings of the 26th Annual International Conference on Mobile Computing and Networking. 1–14
Reviewed August 15, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.