RFC 7933
Adaptive Video Streaming over Information-Centric Networking (ICN)
Title block 💖
Okay bestie, let's get into it ✨ This is RFC 7933, titled Adaptive Video Streaming over Information-Centric Networking (ICN) 🎀. It was published in August 2016 🌸 as an Informational document from the Internet Research Task Force (IRTF) 🔥. Informational means it's published just for, like, sharing knowledge 🧚. It is not an Internet Standards Track spec, so nobody is required to follow it 💅.
The editor is C. Westphal from Huawei 👑, and the other authors are S. Lederer, D. Posch, C. Timmerer (Alpen-Adria University Klagenfurt), A. Azgin, W. Liu (both Huawei), C. Mueller (BitMovin), A. Detti (University of Rome Tor Vergata), D. Corujo (Instituto de Telecomunicacoes Aveiro), J. Wang (City University of Hong Kong), M. Montpetit (MIT), and N. Murray (Athlone Institute of Technology) 🫶🌈. That's a whole squad!!! 😭
The ISSN is 2070-1721 🦋. This document does not obsolete any earlier RFCs and does not update any either, so it's a fresh start, no drama 💜.
Abstract ✨
Okay so this doc thinks about what happens to video delivery if the whole underlying network architecture switches from today's Internet to an Information-Centric Networking (ICN) architecture 🌸. Because most future traffic is expected to be video 🎀, it looks at how today's video streaming mechanisms could be modified 💅.
It covers a bunch of big topics 🔥. The first is evolving Dynamic Adaptive Streaming over HTTP (DASH) so it works over ICN and uses the recent ISO/IEC Moving Picture Experts Group (MPEG) standard 🦋. Then there's layered encoding over ICN 🧚, distinct video requirements for Peer-to-Peer (P2P) mechanisms 💜, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN 🍓, and tighter requirements because of the delay constraints added by Internet Protocol Television (IPTV) ⭐. It also talks about managing digital rights in ICN 👑.
Finally, the doc doesn't just look at how existing mechanisms get affected by ICN. It also lists some research issues for designing ICN-specific video streaming mechanisms from scratch 🌈✨.
Status of This Memo 🎀
This is not an Internet Standards Track spec 💅. It's published for informational purposes 🌸.
It's a product of the IRTF 🔥, which publishes results of Internet-related research and development. Those results might not be suitable for deployment, so keep that in mind 🙈. This RFC represents the consensus of the Information-Centric Networking Research Group of the IRTF 🫶. Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841 💀.
For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7933 🦋.
Copyright Notice 💜
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, bestie, because they describe your rights and restrictions with respect to this document 📜✨.
Table of Contents 🧚
Here's the full outline, verbatim:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Case Scenarios for ICN and Video Streaming . . . . . . . 5
4. Video Download . . . . . . . . . . . . . . . . . . . . . . . 6
5. Video Streaming and ICN . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction to Client-Driven Streaming and DASH . . . . 7
5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . . 8
5.3. Interactions of Video Streaming with ICN . . . . . . . . 8
5.3.1. Interactions of DASH with ICN . . . . . . . . . . . . 8
5.3.2. Interaction of ICN with Layered Encoding . . . . . . 10
5.4. Possible Integration of Video Streaming and ICN
Architecture . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. DASH over CCN . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Testbed, Open-Source Tools, and Dataset . . . . . . . 13
6. P2P Video Distribution and ICN . . . . . . . . . . . . . . . 14
6.1. Introduction to PPSP . . . . . . . . . . . . . . . . . . 14
6.2. PPSP over ICN: Deployment Concepts . . . . . . . . . . . 16
6.2.1. PPSP Short Background . . . . . . . . . . . . . . . . 16
6.2.2. From PPSP Messages to ICN Named-Data . . . . . . . . 16
6.2.3. Support of PPSP Interaction through a Pull-Based ICN
API . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Abstract Layering for PPSP over ICN . . . . . . . . . 18
6.2.5. PPSP Interaction with the ICN Routing Plane . . . . . 19
6.2.6. ICN Deployment for PPSP . . . . . . . . . . . . . . . 19
6.3. Impact of MPEG-DASH Coding Schemes . . . . . . . . . . . 20
7. IPTV and ICN . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. IPTV Challenges . . . . . . . . . . . . . . . . . . . . . 21
7.2. ICN Benefits for IPTV Delivery . . . . . . . . . . . . . 22
8. Digital Rights Management in ICN . . . . . . . . . . . . . . 24
8.1. Broadcast Encryption for DRM in ICN . . . . . . . . . . . 24
8.2. AAA-Based DRM for ICN Networks . . . . . . . . . . . . . 27
8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. Implementation . . . . . . . . . . . . . . . . . . . 28
9. Future Steps for Video in ICN . . . . . . . . . . . . . . . . 28
9.1. Large-Scale Live Events . . . . . . . . . . . . . . . . . 29
9.2. Video Conferencing and Real-Time Communications . . . . . 29
9.3. Store-and-Forward Optimized Rate Adaptation . . . . . . 29
9.4. Heterogeneous Wireless Environment Dynamics . . . . . . 30
9.5. Network Coding for Video Distribution in ICN . . . . . . 32
9.6. Synchronization Issues for Video Distribution in ICN . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 391. Introduction 🌸
The unprecedented growth of video traffic has triggered a rethinking of how content is distributed 🔥. This is happening both at the level of the underlying Internet architecture and at the level of the streaming mechanisms used to deliver video objects 💖.
Okay so the IRTF ICNRG research group was chartered to study new architectures centered upon information 🧚. The main contributor to Internet traffic (and information dissemination) is video, and that's expected to stay the same in the near future 📺. If ICN is going to become prominent, it's going to have to support video streaming efficiently 💅✨.
So there are two separate directions to talk about 🦋:
Can the current video streaming mechanisms be leveraged and adapted to an ICN architecture? Can (and should) new, ICN-specific video streaming mechanisms be designed to fully take advantage of the new abstractions exposed by the ICN architecture?
This document focuses on the first question 💜. It's trying to define the use cases for video streaming and some requirements 🎀. It also zooms in on a few scenarios (namely Netflix-like video streaming, P2P video sharing, and IPTV) and identifies how existing protocols can be adapted to an ICN architecture 🍓. While doing that, it also points out the main issues with these protocols in this ICN context ⭐.
Other works have looked at specific aspects of dynamic adaptive streaming in ICN, like [Lederer13b] [Lederer13a] [Grandl13] [Detti12] 👑. This document is informed by those works, plus others 🌈.
Here's the plan: first, a quick overview of existing solutions for the selected scenarios 🧚. Then we examine how those existing mechanisms interact with the ICN architecture, and list some of the interactions any video streaming mechanism will have to consider 💅. Finally, we flag some areas for future research 🔥✨.
2. Conventions Used in This Document 💖
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively 🫶.
Part 1 of 11. More parts coming, so stay tuned, bestie 🎀💜
3. Use Case Scenarios for ICN and Video Streaming ✨
okay so for the ICN-specific stuff, we're sending you to the other research group docs, like [RFC7476] 📚. For our purposes, "ICN" means an architecture where content gets retrieved by name, with no binding of that content to a specific network location. ngl that's the whole vibe 🦋
Live and on-demand content both come with timing requirements for delivery 🎬. Real-time use cases (like audio-video conferencing [Jacobson09a] or game streaming) are even more demanding, so they have stricter timing requirements 😭. Long startup delays, buffering, and poor video quality should be avoided so the viewer gets a better Quality of Experience (QoE) ✨. For a definition of QoE in the context of video distribution, check out [LeCallet13]. The working definition goes like this:
Quality of Experience (QoE) is the degree of delight or annoyance of the user of an application or service. It results from the fulfillment of his or her expectations with respect to the utility and/or enjoyment of the application or service in the light of the user's personality and current state.
Of course, these requirements are heavily shaped by routing decisions and caching 🧚. Those are central parts of ICN, so they have to be considered when you stream video over these infrastructures. It's giving "everything is connected" 💅
Since there's a whole range of requirements, we decided it'd be useful to narrow things down to four scenarios (more can be added later) 🌸:
- a video download architecture similar to that of Apple iTunes, where the whole file is being downloaded to the client and can be replayed there multiple times 🍓;
- a video streaming architecture for playing back movies, which is relevant for the naming and caching aspects of ICN as well as the interaction with the rate adaptation mechanism necessary to deliver the best QoE to the end user 🎀;
- a P2P architecture for sharing videos, which introduces more stringent routing requirements in terms of locating copies of the content as the location of the peers evolves and peers join and leave the swarm they use to exchange video chunks (for P2P definitions and taxonomy, please refer to RFC 5694; and 🦋
- IPTV, which introduces requirements for multicasting and adds stronger delay constraints 📺.
Other scenarios, like video conferencing and real-time video communications, are in scope but not explicitly discussed here 🙈. Mass-media events, like a huge crowd at a live event, also add new requirements that'll get included in later versions 👑.
The current state-of-the-art protocols in an IP context can be modified for the ICN architecture 💖. Here's how the rest of the doc is laid out: Section 4 discusses video download; Section 5 briefly describes DASH [ISO-DASH] and Layered Encoding (Modification Detection Code (MDC), Scalable Video Coding (SVC)); Section 6 focuses on P2P and PPSP; Section 7 highlights the requirements of IPTV; Section 8 describes the issues of DRM; and Section 9 lists some research issues to be solved for ICN-specific video delivery mechanisms 🔥.
Video-conferencing and real-time-video communications will be covered in more detail in future works 🌈. Mass distribution of content at live, large-scale events (stadiums, concert halls, etc.) has no clearly adopted existing protocol yet, so it's another topic for further research ⭐.
4. Video Download
Video download, meaning fetching a video file from a server or a cache down to the user's local storage, is a natural application of ICN 🫶. It should be supported natively without requiring any specific considerations.
This is supported right now by a host of protocols (say, Secure Copy (SCP), FTP, or over HTTP) 💅. Those would need to be replaced by new ICN-specific protocols to retrieve content in ICNs 🔄.
However, current mechanisms are built on top of existing transport protocols 🙃. Some ICN proposals (Context-Centric Network (CCN) or Named Data Networking (NDN), for instance) try to leverage the work done on those transport protocols 🧠. One proposal is to use the TCP congestion window (and the associated Adaptive Increase, Multiplicative Decrease (AIMD)) to decide how many object requests ("Interests" in CCN/NDN terminology) should be in flight at any point in time 🎯.
Here's the lowkey big thing 👀: ICN intrinsically supports different transport mechanisms, which could achieve better performance than TCP, because they subsume TCP as a special case 🚀. For instance, you could imagine a link-by-link transport coupled with caching. This is enabled by the ICN architecture and would make point-to-point download of video files easier ✨.
5. Video Streaming and ICN
5.1. Introduction to Client-Driven Streaming and DASH
Media streaming over HTTP, and in turn streaming over TCP, is everywhere on today's Internet 🌍. Content providers like Netflix, Hulu, and Vudu don't deploy their own streaming equipment. They use the existing Internet infrastructure as it is and simply deploy their own services Over The Top (OTT) 📺. This approach works surprisingly well with no special help from the underlying network, thanks to efficient video compression, Content Delivery Networks (CDNs), and adaptive video players 💖.
Earlier video streaming research mostly recommended the User Datagram Protocol (UDP) combined with the Real-time Transport Protocol (RTP) 🕰️. It assumed you couldn't move multimedia data smoothly over TCP, because of its throughput variations and large retransmission delays 😬. That view has changed a lot today 🙌. HTTP streaming, especially its simplest form, progressive download, has become super popular over the past few years because it has some major benefits compared to RTP streaming 🍿. Because HTTP is used consistently for this method, the existing Internet infrastructure of proxies, caches, and CDNs can be used too 🧚.
Originally, this architecture was designed for best-effort delivery of files, not real-time transport of multimedia data 🤭. Still, real-time streaming over HTTP can take advantage of this architecture, while RTP couldn't leverage any of those components 💅. Another perk of HTTP is that the media stream could easily pass firewalls or Network Address Translation (NAT) gateways, which was definitely a key to the success of HTTP streaming 🔑. However, HTTP streaming is not the holy grail 🏆 of streaming, since it also has some drawbacks compared to RTP. In an ICN-based video streaming architecture, these aspects also have to be considered 🫠.
The basic concept of DASH [ISO-DASH] is to use segments of media content, which can be encoded at different resolutions, bit rates, etc., as so-called representations 🎞️. These segments are served by conventional HTTP web servers and can be addressed via HTTP GET requests from the client 📥. So the streaming system is pull-based and the entire streaming logic lives on the client, which makes it scalable and lets the media stream adapt to the client's capabilities 👑✨.
On top of that, the content can be distributed using conventional CDNs and their HTTP infrastructure, which also scales very well 📈. To specify the relationship between the content's media segments and the associated bit rate, resolution, and timeline, the Media Presentation Description (MPD) is used 🗂️. It's an XML document 🧾. The MPD refers to the available media segments using HTTP URLs, which the client can use to retrieve them 🔗.
5.2. Layered Encoding
Another approach to video streaming is layered encoding 🍰. Scalable video coding splits the video stream into different layers: a base layer that can be decoded to provide the lowest bit rate for the specific stream, and enhancement layers that can be transmitted separately if network conditions allow 🌤️. The higher layers offer higher resolutions and better video quality, while the layered approach allows adaptation to network conditions 🎚️. This is used in an MPEG-4 scalable profile or H.263+ 🧩. H264SVC is available but not much deployed 😅. JPEG2000 has a wavelet transform approach for layered encoding but hasn't been deployed much either 🥲. It's not clear if the layered approach is fine-grained enough for rate control 🤔.
5.3. Interactions of Video Streaming with ICN
5.3.1. Interactions of DASH with ICN ✨
Okay so DASH (especially) was designed with a goal that's basically the same as most ICN proposals 💖. The client is the one doing the asking, and it asks for items by name. In this case the items are chunks of a video stream 🎀.
ICN and MPEG-DASH [ISO-DASH] have a bunch of things in common 👯♀️:
- the client-initiated pull approach;
- the content being dealt with in pieces (or chunks);
- the support of efficient replication and distribution of content pieces within the network;
- the scalable, session-free nature of the exchange between the client and the server at the streaming layer: the client is free to request any chunk from any location; and
- the support for potentially multiple source locations.
For that last one 🌈, DASH can list multiple source URLs in a manifest, and ICN doesn't care where a copy comes from. We're not saying that current video streaming mechanisms try to pull the content from multiple sources at the same time 🙈. That's a potential benefit of ICN, but the current approaches mentioned in this document don't consider it yet.
ICN is a promising candidate for the Future Internet (FI) architecture, so it's really useful to check how well it works with multimedia streaming standards like MPEG-DASH 🔥. In this context, the purpose of this section is to show how ICN could be used instead of HTTP in MPEG-DASH.
BUT, there are some issues that pop up when you use a dynamic rate adaptation mechanism in an ICN architecture 😭. (Some of these are about caching and aren't necessarily unique to ICN, fr.)
- Naming of the data in DASH doesn't necessarily follow the ICN convention of any of the ICN proposals 🙃. Several chunks of the same video stream might currently go by different names that, for instance, don't share a common prefix. There's a need to harmonize the naming of the chunks in DASH with the naming conventions of ICN. The naming convention of using a filename/time/encoding format could, for instance, be made compatible with the convention of CCN.
- Chunks can be retrieved from any server, but the rate adaptation mechanism tries to estimate the available network bandwidth so it can pick the right playback rate and keep the playback buffer at the right level 📊. So there's a need to either include some location semantics in the data chunks so the throughput to a specific location can be properly assessed, or to design a different mechanism to evaluate the available network bandwidth.
- The typical issue of access control and accounting shows up here, because chunks can be cached in the network outside of the administrative control of the content publisher 💸. The owner of the video stream might require that access to these data chunks be accounted for, billed, or monitored.
- Dynamic streaming multiplies the representations of a given video stream, which makes caching way less effective 🥲. To get a hit for a chunk in the cache, it has to be for the same format and encoding values. Otherwise, to get the same hit rate as a stream using a single encoding, the cache size would have to be scaled up to hold all the possible representations.
- Caching introduces oscillatory dynamics, because it can change the estimate of the available bandwidth between the end user and the repository the chunks come from 🎢. For instance, if an edge cache holds a low resolution representation near the user, the user will get those low resolution chunks, see good performance, and then request higher resolution chunks. If those are hosted on a server with poor performance, the client has to switch back to the low representation. This oscillation may be detrimental to the perceived QoE of the user.
- The ICN transport mechanism needs to be compatible to some extent with DASH 🚂. Take CCN as an example: the rate at which Interests are issued should be such that the chunks received in return arrive fast enough and with the proper encoding to keep the playback buffer above some threshold.
- Multiple network interfaces can be used in ICN, which enables a seamless handover between them 📱. For the combo with DASH, an intelligent strategy focused on traffic load-balancing between the available links may be necessary. This would increase the effective media throughput of DASH by leveraging the combined available bandwidth of all links. However, it could potentially lead to high variations of the media throughput.
- DASH doesn't define how the MPD is retrieved, so this is compatible with CCN 🙌. However, the current profiles defined within MPEG-DASH require the MPD to contain HTTP URLs (including HTTP and HTTPS URI schemes) to identify segments. To enable a more integrated approach like the one described in this document, an additional profile for DASH over CCN has to be defined, one that lets ICN/CCN-based URIs identify and request the media segments.
We describe in Section 5.4 a potential implementation of a dynamic adaptive video stream over ICN, based upon DASH and CCN [Jacobson09b] 🦋.
5.3.2. Interaction of ICN with Layered Encoding
Okay, now for layered video streaming 🧚. These are the issues that matter most to an ICN architecture:
- Caching of the multiple layers 🍓. Caching priority should go to the base layer, and there should be a caching policy that decides when to cache enhancement layers.
- Synchronization of multiple content streams 🎬, because the layers may come from different sources in the network. For example, the base layer might be cached locally while the enhancement layers are stored in the origin server. Video and audio-video streams must be synchronized, and this covers both intra-layer synchronization (for the layers of the same video or audio stream) and inter-stream synchronization (see Section 9 for other synchronization aspects to be included in the "Future Steps for Video in ICN").
- Naming of the different layers 🏷️. When the client requests an object, the request can be satisfied with the base layer alone or aggregated with enhancement layers. Should one request be enough to provide different streams? In a CCN architecture, for instance, this would violate a "one Interest, one Data packet" principle, so the client would need to specify each layer it wants to receive. In a Pub/Sub architecture, the Rendezvous Point would have to decide which layers (or which pointer to which layer's location) to return 👑.
5.4. Possible Integration of Video Streaming and ICN Architecture ✨
5.4.1. DASH over CCN
okay bestie, DASH is all about adaptive streaming 🎀 so each piece of content can come in different qualities, formats, languages, etc., to handle the whole diversity of today's networks and devices 💅 Since that's a huge requirement for Future Internet proposals like CCN, putting the two together feels obvious ✨ DASH lives at the application layer and CCN lives at the network layer, so they can be combined super efficiently to get the advantages of both and maybe kill some existing disadvantages 🦋 CCN isn't built on classic host-to-host connections, so you can pull content from different origin nodes and over different network links in parallel. That counts as an intrinsic error resilience feature with respect to the network 🫶 This is a major win for adaptive multimedia streaming in mobile environments, since most mobile devices have multiple network links like 3G and Wi-Fi 📱 CCN gives you this out of the box, which is so good for DASH-based services 🔥 So yes, adaptive video streaming that handles both bandwidth changes and network link changes is totally possible. Basically, CCN makes the network link call, and DASH sits on top of CCN adapting the video to whatever bandwidth is available 👑
There are two ways to integrate DASH and CCN, no cap 💜 The first is a proxy service acting as a broker between HTTP and CCN, as proposed in [Detti12]. The second is the DASH client implementing a native CCN interface. The proxy version turns an HTTP request into a matching Interest packet, and turns the Data packet back into an HTTP response, including reliable transport as offered by TCP. Honestly this might be a good compromise for running CCN in a managed network and supporting legacy devices 🌸 Since that proxy is already described in [Detti12], this document focuses on a more integrated approach that aims to fully exploit the potential of a CCN DASH client 😭 That means we describe a native CCN interface within the DASH client, which uses a CCN naming scheme (CCN URIs) to denote segments in the MPD. In this setup, only the network access component on the client has to be modified, and the segment URIs within the MPD have to be updated to follow the CCN naming scheme. Iconic, honestly 🧚
First, the DASH client retrieves the MPD, which contains the CCN URIs of the content representations, including the media segments 📜 The naming scheme for the segments may reflect intrinsic CCN features like versioning and segmentation support. Segmentation support is already compulsory for multimedia streaming in CCN, so DASH-based streaming over CCN can also use it. The CCN versioning can be used in a further step to signal different representations of the DASH-based content, which allows an implicit adaptation of the requested content to the client's bandwidth conditions 💖 The Interest packet already carries the desired characteristics of a segment (such as bit rate, resolution, etc.) within the content name, or potentially within parameters defined as extra types in the packet formats. Also, if the bandwidth conditions of the corresponding interfaces or routing paths allow it, DASH media segments could be aggregated automatically by the CCN nodes. That cuts down the number of Interest packets needed to request the content. However, these approaches need further research, specifically in terms of the additional intelligence and processing power needed at the CCN nodes 🤓
After requesting the MPD, the DASH client starts requesting particular segments 🎬 So CCN Interest packets are generated by the CCN access component and forwarded to the available interfaces. Inside the CCN, these Interest packets get the benefit of efficient interest aggregation for, e.g., popular content, plus the implicit multicast support 🌈 Finally, the Interest packets are satisfied by the matching Data packets carrying the video segment data, which are stored on the origin server or on any CCN node, respectively. The more popular the content gets, the more it spreads across the network, which means lower transmission delays and reduced bandwidth requirements for origin servers and content providers, respectively ⭐
Now the not-so-pretty part 🙈 With the heavy use of in-network caching, new drawbacks show up, because the streaming logic lives at the client. Clients aren't aware of each other, the network infrastructure, or the cache states. Things also get messy when multiple clients compete for a bottleneck, and when caching influences that bandwidth competition. As mentioned above, clients request individual portions of the content based on available bandwidth, which is calculated using throughput estimations. This uncontrolled distribution of content messes with the adaptation process of adaptive streaming clients. The impact of this falsified throughput estimation could be tremendous, and it can lead to a wrong adaptation decision that affects the QoE at the client, as shown in [Mueller12] 💀 In ICN, the client doesn't know which source the requested content is actually served from, or how many origin servers for the content are available, because that's transparent and depends on the name-based routing. So the adaptation logic of the adaptive streaming client might not notice when ICN routing switches to a different origin server, or when the content starts coming through a different link or interface. Most adaptation algorithms rely on bandwidth measurements and related heuristics, so those decisions are no longer valid after an origin server (or link) change. They can cause playback interruptions and, consequently, stalling 😩 ICN also supports the use of multiple interfaces. A seamless handover between these interfaces (and between different sources for the content) comes with changes in performance. That can happen when switching between fixed and wireless, 3G/4G and Wi-Fi networks, or different types of servers (say with or without Shared Secret Data (SSD) or hardware acceleration), and so on 🦋
Given these ICN characteristics, adaptation algorithms that rely only on bandwidth measurements are no longer appropriate, since each segment could be transferred from a different ICN node or interface, all with different bandwidth conditions. So adaptation algorithms that take these intrinsic ICN characteristics into account are preferred over algorithms based on bandwidth measurements alone 🧠
5.4.2. Testbed, Open-Source Tools, and Dataset
For the evaluations of DASH over CCN, a testbed with open-source tools and datasets is provided in [ITEC-DASH] 🎀 It has two client-player implementations: (i) a libdash extension for DASH over CCN, and (ii) a VLC plugin implementing DASH over CCN. Both implementations are based on the CCNx implementation 💅
The general architecture of libdash is organized into modules, so the library implements an MPD parser and an extensible connection manager ✨ The library provides object-oriented interfaces for these modules to access the MPD and the downloadable segments. These components were extended to support DASH over CCN, and they live in a separate development branch of the GitHub project, available at <http://www.github.com/bitmovin/libdash>. libdash comes with a fully featured DASH player with a QT-based front end, which shows off how to use libdash and gives you a scientific evaluation platform 🧚 If you'd rather go another way, patches for the DASH plugin of the VLC player are also provided. You can apply these patches to the latest source code checkout of VLC to get a DASH-over-CCN-enabled VLC player 🍓
Finally, there's a DASH-over-CCN dataset provided as a CCNx repository 🎬 It includes 15 different quality representation of the well-known Big Buck Bunny Movie, ranging from 100 kbps to 4500 kbps. The content is split into segments of two seconds and is described by an associated MPD using the naming scheme presented in Section 5.1. You can download this repository from [ITEC-DASH], and it's also available through a publicly accessible CCNx node. Associated routing commands for the CCNx namespaces of the content come with scripts shipped alongside the dataset, so it can be used as a public testbed 🌈
6. P2P Video Distribution and ICN ✨
Peer-to-Peer distribution is another way of distributing content (and video in particular) that ICNs need to support 🫶 Now we'll see how an existing protocol, such as PPSP, can be modified to work in an ICN environment 👑
6.1. Introduction to PPSP 🎀
okay so bestie, P2P Video Streaming (P2PVS) is literally the move when you want to redistribute live media over the Internet 📺✨. The proposed P2PVS solutions can be roughly sorted into two classes:
- Push/Tree-based 🌳
- Pull/Mesh-based 🕸️
So the Push/Tree-based solution builds an overlay network among Peers that has a tree shape [Castro03]. 🌳 Using a progressive encoding (for example, Multiple Description Coding or H.264 Scalable Video Coding), multiple trees could be set up to support video rate adaptation. 💖 On each tree, an enhancement stream is sent. The more streams you receive, the higher the video quality gets 😭🔥. A peer controls its video rate by either fetching or not fetching the streams delivered over the distribution trees. It's giving control, honestly 💅.
The Pull/Mesh-based solution is inspired by the BitTorrent file sharing mechanism 🧚. A tracker collects information about the state of the swarm (that is, the set of participating peers). 👑 A peer forms a mesh overlay network with a subset of peers and exchanges data with them. A peer announces what data items it has, and requests missing data items that are announced by connected peers. 🫶 In the case of live streaming, the data set only includes a recent window of data items published by the source. Also, in this case, a progressive encoding can be used for video rate adaptation 🌈.
Pull/Mesh-based P2PVS solutions are the more promising candidate for ICN deployment, since most of the ICN approach provides a pull-based API [Jacobson09b] [Detti11] [Chai11] [NETINF] 🦋. Plus, Pull/Mesh-based P2PVS is more robust than the Push/Tree-based one [Magharei07], and the PPSP working group [IETF-PPSP] is also proposing a Pull/Mesh-based solution. Main character energy, no cap 👑💜.
+------------------------------------------------+
| |
| +--------------------------------+ |
| | Tracker | |
| +--------------------------------+ |
| | ^ ^ |
|Tracker | | Tracker |Tracker |
|Protocol| | Protocol |Protocol |
| | | | |
| V | | |
| +---------+ Peer +---------+ |
| | Peer |<----------->| Peer | |
| +---------+ Protocol +---------+ |
| | ^ |
| | |Peer |
| | |Protocol |
| V | |
| +---------------+ |
| | Peer | |
| +---------------+ |
| |
+------------------------------------------------+
Figure 1: PPSP System Architecture [RFC6972]Okay, so Figure 1 shows the PPSP architecture from [RFC6972] 🧩. PEERs announce and share video chunks, and a TRACKER keeps a list of PEERs taking part in a specific audio-video channel or in the distribution of a streaming file 📋. The TRACKER functionality may be centralized in a server or distributed over the PEERs, which is lowkey so flexible 🙈. PPSP standardizes the peer and Tracker Protocols, and those can run directly over UDP or TCP 🚀.
This document discusses some preliminary concepts about deploying PPSP on top of an ICN that exposes a pull-based API, while also considering the impact of the MPEG-DASH streaming format 🎬✨.
6.2. PPSP over ICN: Deployment Concepts 🍓
6.2.1. PPSP Short Background 📚
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is defined in [Bakker15], and the Peer-to-Peer Streaming Tracker Protocol (PPSP-TP) is defined in [RFC7846] 💜.
Some of the operations carried out by the Tracker Protocol are the following. When a peer wants to join the streaming session, it contacts the tracker (CONNECT message) and gets a PEER_ID plus a list of PEER_IDs (and IP addresses) of other peers participating in the SWARM that the tracker has picked out for the requesting peer. This may be only a subset of all the peers in the SWARM 🫧. Besides this join operation, a peer may contact the tracker to ask for a renewed list of participating peers (FIND message), or to periodically update its status to the tracker (STAT_REPORT message), and so on 🔄.
Some of the operations carried out by the Peer Protocol include the following. Using the list of peers delivered by the tracker, a peer establishes a session with them (HANDSHAKE message). A peer periodically announces to its neighboring peers which chunks it has available for download (HAVE message). Using these announcements, a peer requests missing chunks from neighboring peers (REQUEST messages), and those chunks get sent back to it (DATA message) 🎁💅.
6.2.2. From PPSP Messages to ICN Named-Data 🏷️
An ICN provides users with data items exposed by names. The bundle name and data item is usually referred to as "named-data", "named-content", etc. ✨ To transfer PPSP messages through an ICN, the messages should be wrapped as named-data items, and receivers should request them by name 🎀.
A PPSP entity receives messages from peers and/or a tracker. Some operations require gathering the messages generated by another specific host (peer or tracker). For instance, if Peer A wants to learn about video chunks available from Peer B, Peer A SHALL fetch the PPSP HAVE messages specifically generated by Peer B. Wait, let me be precise here: the original says "shall", so I'll keep the exact wording: Peer A shall fetch the PPSP HAVE messages specifically generated by Peer B. We call these kinds of named-data "located-named-data" since they should be gathered from a specific location (e.g., Peer B) 📍🦋.
For other PPSP operations, like fetching a DATA message (aka a video chunk), it doesn't matter which endpoint generated the data, as long as a peer gets the requested content. We refer to this information with the generic term "named-data" 🧁.
The naming scheme differentiates named-data and located-named-data items. For named-data, the naming scheme only includes a content identifier (e.g., the name of the video chunk), without any prefix identifying who provides the content. For instance, a DATA message containing the video chunk "#1" may be named "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier of the streaming session, "chunk" is a keyword, and chunkID is the chunk identifier (e.g., an integer number) 🌸.
For located-named-data, the naming scheme includes a location-prefix, which uniquely identifies the host generating the data item. This prefix may be the PEER_ID if the host was a peer, or a tracker identifier if the host was the tracker. For instance, a HAVE message generated by Peer B may be named "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, PEER_ID_B is the identifier of Peer B, and HAVE is a keyword 🫶.
6.2.3. Support of PPSP Interaction through a Pull-Based ICN API 🌈
The PPSP procedures are based on both pull and push interactions. For instance, distributing chunk availability can be classified as push-based, since a peer sends "unsolicited" information (HAVE message) to neighboring peers. On the flip side, the procedure used to receive video chunks can be classified as pull-based, since it is supported by a request/response interaction (REQUEST and DATA messages) 🔥.
As we said, we're talking about an ICN architecture that provides a pull-based API. So, the mapping of the PPSP pull-based procedure is pretty simple. For instance, using the CCN architecture [Jacobson09b], a PPSP DATA message may be carried by a CCN DATA message, and a REQUEST message can be transferred by a CCN Interest 🧚♀️.
The support of push-based PPSP operations, though, may be trickier. We need an adaptation functionality that carries out a push-based operation using the underlying pull-based service primitives 🛠️. For instance, one possible approach is to use the request/response (that is, Interest/Data) four-way handshakes proposed in [Jacobson09a]. Another possibility is that receivers periodically send out request messages for the named-data that neighbors will push, and when it's available, the sender inserts the pushed data within a response message 💌.
6.2.4. Abstract Layering for PPSP over ICN 🍰
+-----------------------------------+
| Application |
+-----------------------------------+
| PPSP (TCP/IP) |
+-----------------------------------+
| ICN - PPSP Adaptation Layer (AL) |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 2: Mediator ApproachFigure 2 gives a possible abstract layering for PPSP over ICN. The Adaptation Layer acts as a mediator (proxy) between legacy PPSP entities based on TCP/IP and the ICN architecture. In fact, the role of the mediator is to use ICN to transfer PPSP legacy messages 🧸.
This approach makes it possible to simply reuse TCP/IP P2P applications whose software also includes PPSP functionality 💜. This "all-in-one" development approach may be pretty common, since the PPSP application interface is not going to be specified. Plus, if the operating system provides libraries that expose a PPSP API, those will initially be based on an underlying TCP/IP API. In this case too, the mediator approach would make it easy to reuse both the PPSP libraries and the Application on top of an ICN 🙌.
+-----------------------------------+
| Application |
+-----------------------------------+
| ICN-PPSP |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 3: Clean-Slate ApproachFigure 3 sketches a clean-slate layering approach, in which the application directly includes or interacts with a PPSP version based on ICN. It's likely such a PPSP_ICN integration could yield simpler development, also because it does not require implementing a TCP/IP to ICN translation like the Mediator approach does. However, the clean-slate approach requires developing the application (in case of embedded PPSP functionality) or the PPSP library from scratch, without exploiting what might already exist for TCP/IP 😤.
Overall, the Mediator approach may be considered the first step of a migration path towards ICN-native PPSP applications 🦋✨.
6.2.5. PPSP Interaction with the ICN Routing Plane ✨
okay so picture this 💖 a user (peer) asks for content through the ICN API, and the ICN just sends it back 🦋 where it comes from is the ICN's problem. it could be the closest peer that has the named-data item, an in-network cache, etc. 🫶 the where do I grab it from part is handled by an underlying ICN routing plane, which sets up the ICN forwarding tables (e.g., CCN FIB [Jacobson09b]). main character energy for the routing plane, honestly 👑
a cross-layer interaction between the ICN routing plane and PPSP may be required to support a PPSP session 🔥 the ICN shall forward request messages (e.g., CCN Interest) towards the proper peer that can handle them. depending on the layering approach, this cross-layer chat is controlled either by the Adaptation Layer or by the ICN-PPSP 🧚 for example, if Peer A gets a HAVE message saying Peer B has the video chunk named ccnx:/swarmID/chunk/chunkID, then Peer A should insert into its ICN forwarding table an entry for the prefix ccnx:/swarmID/chunk/chunkID, whose next hop locator (e.g., IP address) is the network address of Peer B [Detti13]. the vibes are immaculate 💅
6.2.6. ICN Deployment for PPSP
okay this part is the big where does this live question 🌸 the ICN functionality that supports a PPSP session may be "isolated" or "integrated" with one from a public ICN.
in the isolated case, a PPSP session is supported by an instance of an ICN (e.g., deployed on top of IP) whose functionalities only operate on the limited set of nodes participating in the swarm, i.e., peers and the tracker. this is giving the same energy as current P2P apps, which usually form an overlay network among their peers, while the intermediate public IP routers just don't do any P2P stuff 🙈
in the integrated case, the nodes of a public ICN may be involved in the forwarding and in-network caching procedures. the swarm can benefit from in-network caches, which means less uplink traffic on peers and less inter-domain traffic too 🍓 these are the distinctive perks of running PPSP over a public ICN rather than over TCP/IP. ngl, those perks aren't likely to show up in the isolated deployment 😭
BUT. the possible interaction between PPSP and the routing layer of a public ICN may be dramatic, both in terms of an explosion of the forwarding tables and in terms of security 💀 this really only hits ICN architectures where name resolution (i.e., name to next hop) happens en route, like the CCN architecture.
for example, with CCN, to fetch a named-data item offered by Peer A, the on-path public ICN entities have to route the request messages towards Peer A. so the forwarding tables of public ICN nodes may end up with lots of entries, e.g., one entry per video chunk 🫠 and those entries are hard to aggregate, since peers may only have sparse parts of a big piece of content, and the names share the same prefix (e.g., ccnx:/swarmID).
another option is to wrap all PPSP messages into a located-named-data. then the forwarding tables only need the PEER_ID prefixes (e.g., ccnx:/swarmID/peer/PEER_ID), so the number of entries drops from the number of chunks to the number of peers ✨ the catch: the ICN mechanisms now see the same video chunk offered by different peers as different content, so you lose the caching and multicasting ICN benefits 😤
either way, routing entries have to get updated based on which named-data items are available on peers or on which peers are present. and in a P2P session those events change super fast, which could hamper convergence of the routing plane 🌪️ finally, since peers affect the ICN forwarding tables of public nodes, this opens some obvious security issues 🚨
6.3. Impact of MPEG-DASH Coding Schemes
okay so video rate adaptation is amazing for viewers, but it can seriously weaken P2P cooperation and in-network caching 🎀 how bad it gets depends on the kind of video coding the MPEG-DASH stream uses.
with MPEG AVC encoding, the same video chunk is encoded independently at each rate, and the output is a different file for each rate 🧁 say a video is encoded at three rates, R1, R2, and R3. for each segment S, you get three separate files: S.R1, S.R2, and S.R3, and none of them depend on each other. to fetch a segment coded at R2 kbps, a peer shall request the specific file S.R2. the video client's receiver-driven algorithms usually handle the job of estimating the best coding rate 🎯
the independence between files for different rates, plus the mix of peer bandwidths, can really reduce peer interaction, the effectiveness of in-network caching (in the integrated deployment case), and therefore how well PPSP can offload the video server (i.e., a seeder peer) 😩 for instance, Peer A might pick rate R1 while Peer B picks R2. that stops Peer A from fetching chunks from Peer B, because Peer B only has chunks coded at a rate Peer A doesn't need. one fix is a common distributed rate selection algorithm that forces peers to pick the same coding rate [Detti13]. but honestly, that may not be feasible when there are lots of peers 🙃
now the SVC encoding (Annex G extension of the H.264/MPEG-4 Advanced Video Coding (AVC) video compression standard) is the glow-up 🦋 it should make rate adaptation possible without reducing peer collaborations or in-network caching effectiveness. for a single video chunk, an SVC encoder produces different files for the different rates (roughly "layers"), and these files are progressively related to each other. starting from a base layer that gives the minimum rate encoding, the next rates are encoded as an "enhancement layer" of the previous one 🧱 say the video has three rates: R1 (base layer), R2 (enhancement layer n.1), and R3 (enhancement layer n.2). then for each DASH segment, you have three files: S.R1, S.R2, and S.R3. the file S.R1 is the segment at the minimum rate (base layer). the file S.R2 enhances S.R1, so S.R1 and S.R2 can be combined to get a segment at rate R2. to get a segment at rate R2, a peer shall fetch both S.R1 and S.R2 🫶
this progressive dependence is the magic, because it makes peer cooperation possible even when peers' players have independently picked different rates. for example, if Peer A selected R1, the S.R1 files it downloaded are also useful to a Peer B that selected R2, and vice versa 👑 no cap, this is the whole point.
7. IPTV and ICN ✨
7.1. IPTV Challenges
okay so IPTV is all about delivering quality content over the Internet, and it comes with strict quality requirements 💜 we're talking a perceived latency of less than 500 ms, and a packet loss rate that's multiple orders of magnitude lower than the loss rates you see in the most common access networks (see [ATIS-IIF]). here are the major challenges for delivering the IPTV service 📺
channel change latency is a major concern for IPTV 😭 perceived latency during a channel change should be less than 500 ms. over IP infrastructure, there are a few ways to try and hit that:
- i. receive fast unicast streams from a dedicated server (most effective, but not resource efficient);
- ii. connect to other peers in the network (efficiency depends on peer support; effective and resource efficient if also supported with a dedicated server); and
- iii. connect to multiple multicast sessions at once (effective, but not resource efficient, and depends on how accurate the prediction model tracking user activity is).
the second big challenge is error recovery 🔥 typical IPTV service requirements say the mean time between artifacts should be about 2 hours (see [ATIS-IIF]). that suggests the perceived loss rate should be less than or equal to 10^-7. current IP-based solutions rely on these proactive and reactive recovery techniques:
- i. joining the Forward Error Correction (FEC) multicast stream that matches the perceived packet loss rate (not efficient, since the recovery strength is chosen based on worst-case loss scenarios);
- ii. making unicast recovery requests to dedicated servers (requires active support from the service provider); and
- iii. probing peers to acquire repair packets (finding matching peers and getting them to cooperate is another challenge) 🧚
7.2. ICN Benefits for IPTV Delivery 🎀
okay so ICN is honestly a dream for IPTV delivery 😭✨ it inherently supports multicast, and it lets you bounce back quickly from packet losses thanks to in-network caching. peer support shows up too, in the form of in-network caches that usually act as the middleman between two peers, so people get earlier access to IPTV content 💖
BUT (big but 💀) delivering IPTV over ICNs brings brand new challenges. here are some of the big ones:
- Messaging overhead: ICN is pull-based and runs on a very specific balance between requests and responses. a user has to make a request for every single Data packet 🙈 with IPTV rates up to (and likely above) 15 Mbps, there's a lot of upstream traffic just to bring those streams in. the more streams there are (including the same session at different quality levels and in other formats), the more the routers have to carry 😩 even if most requests get aggregated at the core, the routers close to the edge (where user requests differ the most) take a big overhead hit just processing them. users feel it too, since uplink usage multiplies with every session a user requests (for example, to minimize the impact of bandwidth fluctuations) 🫠
- Cache control: IPTV content expires at a rapid rate, with a likely expiry threshold of 1 s, so we need ways to flush it out effectively so it doesn't degrade other cached content, using carefully chosen naming conventions 🧹 but fast recovery and quick access to sessions (for current or new users) mean the timing of those expirations has to adapt to network load and user demand ✨ and we still need quick access to earlier content whenever it's needed, like when someone uses the rewind feature. in-network caches won't help much in those cases, because keeping that content around takes too much overhead 💅
- Access accuracy: users need up-to-date session data at the moment they make a request, because they join a session indirectly, unlike IP multicast. session info is critical for cutting buffering delays and startup latency 🍓 without it, and without any active cooperation from intermediate routers, stale data can seriously undermine content delivery 💀 also, finding a cache doesn't automatically mean you've joined a session, since the look-ahead latency for the initial content access point may have a shorter lifetime than originally intended. for example, if the user who started the indirect multicast leaves early, the requests from the remaining users have to experience an additional latency of one RTT as they travel toward the content source. and if startup latency is chosen based on how close you are to the intermediate router, going to the content source in-session can lead to undesired pauses 😬
it's worth noting that IPTV includes more than just multicast 📺 lots of implementations have "trick plays" (fast forward, pause, rewind) that often transform a multicast session into multiple unicast sessions. in that context, ICN is a win, because caching offers an implicit multicast without tight synchronization constraints between two different users 🦋 one user can rewind and start playing forward again by drawing from a nearby cache of content another user recently viewed. in a strict multicast session, it'd be way harder for one user to lag behind 🌸
8. Digital Rights Management in ICN ✨
this section discusses why DRM functionality is needed for multimedia streaming over ICN 🔐 it focuses on two possible approaches: modifying Authentication, Authorization, and Accounting (AAA) to support DRM in ICN, and using Broadcast Encryption.
it's assumed that ICN will be used heavily for digital content dissemination, so DRM for digital content distribution is vital to consider 💜 in today's Internet, there are two predominant classes of business models for on-demand video streaming.
the first model is based on advertising revenues. Non-copyright-protected content (usually User-Generated Content (UGC)) is offered at no charge by large infrastructure providers like Google (YouTube), and the infrastructure is financed by splicing advertisements into the content. here DRM considerations may not be required, since UGC producers may only strive for the maximum possible dissemination 🌈 some UGC producers are mainly interested in sharing content with their families, friends, colleges, or others, and have no intention of making a profit 🫶
the second class of business model requires DRM, because these entities are primarily profit oriented 💰 large on-demand streaming platforms (e.g., Netflix) are built on subscriptions, so consumers may have to pay a monthly fee to get access to copyright-protected content like TV series, movies, or music. this model may be ad supported and free to the consumer, like YouTube Channels or Spotify, but the creator of the content still expects some remuneration for their work 👑 from the perspective of the service providers and the copyright owners, only clients that pay the fee (explicitly or implicitly through ad placement) should be able to access and consume the content 🔥
anyway, the challenge is to find an efficient and scalable way of access control to digital content distributed in ICNs 🧚
8.1. Broadcast Encryption for DRM in ICN
Okay bestie, this section is about Broadcast Encryption (BE) as a solid base for DRM in ICN 💅 The big win is that BE plays nicely with network-inherent caching, and we're gonna highlight that 🫶
In ICN, Data packets can be cached inside the network, and literally any network participant can ask for a copy 👀 That makes access control for ICN-distributed content super hard 😭 A naive fix is to encrypt the data for each consumer with a distinct key. That keeps everyone except the intended consumers from decrypting, but it's not very ICN-core, because it kills the caching perks. Even when multiple consumers want the same content, each one gets different data 💀
A better (but still not enough) idea is one key for all consumers. Caching stays happy 🦋 The catch is that if one consumer illegally distributes the key, the whole system is broken and anyone in the network can read the data 🙈 Changing the key after that doesn't really help, since the provider can't figure out who the illegal distributor was, so nothing stops that person from sharing the new key too. Then there's the subscription problem: subscriptions expire, and those people have to lose access. For a provider with millions of daily consumers (Netflix, for example), that could mean a ton of expiring subscriptions every day. Publishing a new key each time would mean re-encrypting the whole audio-visual collection, which takes an unreasonable amount of computing power just to do 😩
A possible solution is BE [Fiat94] as proposed in [Posch13]. From here on, this section only looks at BE as an enabler for DRM in the use case of ICN video streaming. This subsection keeps going with how BE works and how it can be used for an access control scheme in ICN content distribution 🎀
BE actually has a misleading name 🙃 You'd expect a specific encryption scheme, but it belongs to the family of key management schemes. Those are responsible for generating, exchanging, storing, and replacing cryptographic keys. The most interesting characteristics of BE schemes are:
- BE schemes typically use a global trusted entity called the Licensing Agent (LA), which is responsible for spreading a set of pre-generated secrets among all participants. Each participant gets a distinct subset of secrets assigned from the LA.
- The participants can agree on a common session key, which is chosen by the LA. The LA broadcasts an encrypted message that includes the key. Participants with a valid set of secrets can derive the session key from this message.
- The number of participants in the system can change dynamically. Entities may join or leave the communication group at any time. If a new entity joins, the LA passes on a valid set of secrets to that entity. If an entity leaves (or is forced to leave), the LA revokes the entity's subset of keys, which means it can't derive the correct session key anymore when the LA distributes a new key 🚪
- Traitors (entities that reveal their secrets) can be traced and excluded from ongoing communication. The algorithms and preconditions to identify a traitor vary between concrete BE schemes 🕵️♀️
This list already shows why BE is a great fit for controlling access to data distributed via ICN 🔥 BE allows a single session key for confidential data transmission between a dynamically changing subset of network participants. ICN caches can be utilized, since the data is encrypted with only one key that all legitimate clients know. Plus, traitors can be identified and removed from the system 👑 The re-encryption issue still exists, because the LA will eventually update the session key when a participant needs to be excluded. However, that downside can be eased in some ways if the following points are considered:
- Session key updates can be delayed until a set of compromised secrets has been gathered. Secrets may become compromised for two reasons: first, a traitor could have illegally revealed the secret; second, the subscription of an entity expired. Delayed revocation temporarily lets some illegitimate entities consume content. However, this shouldn't be a severe problem in home entertainment scenarios 🍿 Updating the session key at regular (not too short) intervals is a good trade-off. The longer the interval lasts, the fewer computational resources are needed for content re-encryption, and the better the cache utilization in the ICN will be. To evict old data from ICN caches that were encrypted with the prior session key, the publisher could indicate a lifetime for transmitted packets ⏳
- Content can be re-encrypted dynamically at request time. This means untapped content isn't re-encrypted if it isn't requested during two session key updates, so no resources get wasted 🌸 Also, if the updates are triggered during non-peak times, the maximum amount of resources needed at any one moment can be lowered effectively, since peak times usually see more diverse content requested 📉
- The amount of required computational resources can vary a lot over time, so it would be super beneficial for any streaming provider to use cloud-based services that scale resources up to the current needs. If there's a shortage of computation time or bandwidth, the cloud service could scale up to cover it ☁️
Figure 4 shows the potential usage of BE in a multimedia delivery framework that builds on ICN infrastructure and uses the concept of dynamic adaptive streaming, e.g., DASH. BE would sit on top to give an efficient and scalable way of controlling access to the multimedia content 🧚
+--------Multimedia Delivery Framework--------+
| |
| Technologies Properties |
| +----------------+ +----------------+ |
| | Broadcast |<--->| Controlled | |
| | Encryption | | Access | |
| +----------------+ +----------------+ |
| |Dynamic Adaptive|<--->| Multimedia | |
| | Streaming | | Adaptation | |
| +----------------+ +----------------+ |
| | ICN |<--->| Cacheable | |
| | Infrastructure | | Data Chunks | |
| +----------------+ +----------------+ |
+---------------------------------------------+
Figure 4: A Potential Multimedia Framework Using BE8.2. AAA-Based DRM for ICN Networks
8.2.1. Overview
Lately a fresh approach to DRM has come along that links DRM to the usual network management operations, which means linking DRM to AAA services 🔗 ICN gives us an architecture where content is requested by name and can be served from anywhere 🌍 In DRM, the content provider (the origin of the content) lets the destination (the end-user account) use the content. The content provider and the content storage/cache are at two different entities in ITU Carrier Code (ICC). For traditional DRM, only source and destination count, not the intermediate storage 🙅♀️ This proposed solution lets the caching provider get involved in DRM policies using well-known AAA mechanisms ✨ It's important to note that this solution is compatible with the BE proposal from earlier in this document. BE proposes a technology, while this solution is more operational 🎀
8.2.2. Implementation
With the proposed AAA-based DRM, when content is requested by name from a specific destination, the request can link back to both the content provider and the caching provider via traditional AAA mechanisms, and trigger the appropriate DRM policy no matter where the content is stored 🧠 Here, caching, DRM, and AAA stay independent entities, but they can work together through ICN mechanisms 🫶 The proposed solution extends traditional DRM done by the content provider so it's jointly done by the content provider and the network/caching provider 💜
The solution is based on the concept of a "token" 🎟️ The content provider authenticates the end user and issues an encrypted token that authenticates the named-content ID or IDs the user can access. The token is shared with the network provider and used as the interface to the AAA protocols. At this point, all content access is under the control of the network provider and the ICN. The controllers and switches can manage content requests and handle mobility 🔄 The content can be accessed from anywhere as long as the token remains valid or the content is available in the network. In this scheme, the content provider doesn't have to be contacted every time a named-content item is requested. That reduces the load on the content provider's network and creates a DRM mechanism that fits way better with the distributed caching and Peer-to-Peer storage characteristics of ICN networks 🥰 Specifically, the content requested by name can be served from anywhere, under the only condition that the storage/cache can verify that the token is valid for content access 🔐
The solution is also fully customizable to both content and network provider needs, since tokens can be issued based on user accounts, location, and hardware (Media Access Control (MAC) address, for example), which links it naturally to legacy authentication mechanisms 💖 Plus, since both content and network providers are involved in DRM policies, pollution attacks and other illegal requests for the content can be detected more easily 🕵️♀️ The proposed AAA-based DRM is currently under full development 🚧
9. Future Steps for Video in ICN
The explosion of online video services, along with their increased consumption on mobile wireless terminals, makes the challenges of ICN mechanisms that leverage Video Adaptation even more intense 📱💥 The following sections present a series of research items derived from these challenges, introducing next steps for the subject 🔭
9.1. Large-Scale Live Events
Distributing content, video especially, using local communications at large-scale events (like a sporting event in a stadium, a concert, or a large demonstration) is an active area of investigation and a potential use case where ICN would provide significant benefits 🏟️🎶
These use cases involve locating content that's generated on the fly, which needs discovery mechanisms in addition to sharing mechanisms. The scalability of the distribution becomes important as well 📈✨
9.2. Video Conferencing and Real-Time Communications 🎀
okay so current video conferencing protocols already exist, and this document learned a lot from them 💅 to figure out the key research questions. real-time comms add timing constraints on top of everything above, both for delay and for synchronization ⏱️ so it's a whole different vibe 😭
an Access Router (AR) and a Virtual Router (VR), plus immersive multimedia experiences in general, are clearly still an area to investigate ✨ because they mash together multiple streams from multiple users into one coherent whole 🌈 this raises multisource, multidestination multimedia stream issues, and ICN may be able to handle these more naturally than IP, which is inherently unicast 🦋
9.3. Store-and-Forward Optimized Rate Adaptation 💖
one of the perks of ICN is that the network can insert caching in the middle of a data transfer 🧚 this can cut overall bandwidth demand by caching content for future reuse, and it also opens up more chances to optimize video streams 🔥
let's run a scenario: a client is connected via an ICN network to a server. say the client is wirelessly connected to a node with caching capability, and that node connects through a WAN to the server 🛜 on top of that, the capacity of each link (both the wireless and the WAN logical links) changes over time ⭐
if rate adaptation happens end-to-end, like in current mechanisms such as DASH, then the maximum rate the client can get is the minimum bandwidth across each link 😬
for example, during Time Period 1 the wireless capacity is 1 and the wired capacity is 2, and during Time Period 2 the wireless capacity is 2 (thanks to some hotspot) and the wired capacity is 1 (thanks to some congestion in the network) 🍓 then the best end-to-end rate is 1 in each period. sad but true 🥲
BUT, if the cache pre-fetches 2 units of data during Time Period 1, then during Time Period 2 there's 1 unit sitting at the cache and another unit that can be streamed from the server 🙌 so the rate you can hit is 2 units. the average bandwidth goes from 1 to 1.5 over the two periods. iconic glow-up 👑
this straw-man example shows a) the benefit of ICN for boosting network throughput and b) that special rate adaptation mechanisms need to be designed to take advantage of this gain ✨ end-to-end rate adaptation simply can't use cache availability 💀 the authors of [Rainer16] showed that buffer-based adaptation mechanisms can be one way to handle this challenge 🫶 since buffer-based adaptation doesn't estimate available bandwidth (it only looks at the video buffer fill state), bandwidth fluctuations caused by cache hits never show up in the measurements 🌸 so they can't mess with adaptation decisions, like causing frequent representation switching 🙈
9.4. Heterogeneous Wireless Environment Dynamics 🌈
okay the online services that mobile devices access keep growing nonstop 📱 so operators have been deploying lots of overlapping wireless access technologies. in the same area, user terminals can be in range of different cellular, Wi-Fi, or even Worldwide Interoperability for Microwave Access (WiMAX) networks 🛰️ and with the Internet of Things coming in (think surveillance cameras feeding video footage 📹), you can add even more short-range options, like Bluetooth or ZigBee 🦋
to take advantage of all these connectivity options, user terminals are getting different wireless access interfaces 🎀 so devices can pick whichever access type suits them best based on criteria like available bandwidth, battery consumption, link conditions for their user profile, or even access to different content 💅 all of this shapes the QoE the end user actually feels, which matters a LOT for video 😭✨
but here's the catch: mobile users on wireless tech are in a super dynamic setting. the best link right now might not last, or might not stay that way while the user is moving 🏃♀️💨 this has been studied a lot in recently finished projects like FP7 MEDIEVAL [MEDIEVAL], where link events about wireless conditions and available alternative connection points got combined with video requirements and traffic optimization to make a joint network and mobile terminal mobility management decision 🧠 specifically, [Fu13] sent link information about wireless signal deterioration to a mobility management controller in the network 📡 that input got combined with user profile info and the current video service requirements, and used to trigger decreasing or increasing scalable video layers (adjusting the video to match the link conditions) 🎬 and the video could also be adjusted later when a new, better connectivity option shows up 🚀
so for Video Adaptation, ICN mechanisms can lean on their built-in multiple source support and go beyond just monitoring the current link 🫶 that means they can use different connectivity possibilities (like different "interfaces") 🔌 also, info from the mobile terminal's view of its network link, plus info from the network itself (like load, policies, and more) can be combined in a joint optimization so content gets forwarded to users over the best available connectivity option 💜 (for example, using management capabilities that ICN's intrinsic mechanisms support, as in [Corujo12]) 🍭
and honestly? ICN base mechanisms could enable brand new deployment scenarios too, like prepping the network for mass requests from people at a big multimedia event (a concert or a sports game 🎤🏟️). video could then be adapted dynamically based on content, user and network requirements, and operation capabilities 🌟
making this happen needs more research, and the main points are:
- how to develop a generic video services (and obviously content) interface that lets their requirements (and characteristics) get defined and mapped onto the network's current capabilities 💖
- how to define a scalable mechanism that lets either the video application on the terminal or some kind of network management entity adapt the video content dynamically 🔥
- how to build the research items above using ICN's intrinsic mechanisms (that is, the naming and strategy layers) 🧚
- how to use intelligent pre-caching of content to prevent stalls and poor-quality phases, which hurt the user's QoE 🥹 this matters especially in mobile environments, which have severe bandwidth changes and connection outages, as shown in [Crabtree13] 📉
- how to take advantage of multipath opportunities across heterogeneous wireless interfaces 🦋
9.5. Network Coding for Video Distribution in ICN 🧶
an interesting research area for combining heterogeneous sources is network coding [Montpetit13b] 🧩 network coding lets multiple sources combine asynchronously, because each one sends information that isn't duplicated by the others but can still be combined to rebuild the video stream 💫
but this creates ICN issues around defining the right rate adaptation for the video stream, securing the encoded data, caching the encoded data, the timeliness of the encoded data, and the overhead of the network coding operations (both in network resources and in added buffering delay), and more 😵💫
network coding has shown promise for reducing buffering events in unicast, multicast, and P2P settings 🎉 [Medard12] looks at strategies that use network coding to boost QoE for multimedia communications 💖 network coding can be applied across multiple streams, but it can also work within a single stream as the equivalent of a composable erasure code 🌸 so yeah, there's clearly a need for more investigation of network coding in ICN, and it could potentially become a topic of activity in the research group 🫶
9.6. Synchronization Issues for Video Distribution in ICN ⏰
ICN decouples fetching video chunks from where they live 🧠 so an audio chunk might come from one network element (cache, storage, or server), a video chunk from another, and yet another chunk (say, the next one, or another layer of the same video stream) from a third element 🎭 this creates disparity in retrieval times and locations for the different parts of a video stream that need to play at the same (or almost the same) time 😳 synchronizing that delivery and playback might need specific synchronization tools for video delivery in ICN 🔧
other synchronization aspects include:
- within a single stream, like the consecutive chunks of one stream or the multiple layers of a layered scheme when the sources and transport layers may be different 🍰
- re-ordering the packets of a stream spread across multiple sources at the video client, or making sure multiple chunks from multiple sources arrive within an acceptable time window ⏳
- multiple streams, like the audio and video components of a video stream, which can come from independent sources 🎧
- multiple streams from multiple sources to multiple destinations, like mass distribution of live events 📺 for example, live video streams or video conferencing need some level of synchronization so that everyone watching sees the same events at the same time 👯♀️✨
some of these issues were addressed in [Montpetit13a] in the context of social video consumption 🍿 network coding, combined with traffic engineering, is considered a potential solution for synchronization issues 💜 other approaches specific to ICN could be considered too 🌈
traffic engineering in ICN [Su14] [Chanda13] may be required to properly synchronize multiple streams 🚦
10. Security Considerations 🔐
this is informational 🫶 there are no specific security considerations outside of those mentioned in the text 💅
11. Conclusions ✨
okay so bestie, here's the big picture 🦋 this doc puts adaptive video streaming on ICN on the map, flags the problems that pop up, and then drops CCN + DASH as the fix 👑 Both DASH and CCN already vibe together: the content comes in different versions, and both handle it as segments. So pairing them is lowkey a no-brainer 💅
Adaptive streaming over CCN gets a whole buffet of perks: efficient caching 🍓, intrinsic multicast support, routing based on named-data URIs 🧚, intrinsic multilink and multisource support, and more. It's giving "everything you'd want, built right in" 💖
Now the mobile side, which is where it gets extra iconic 📱✨ Using CCN with DASH on mobile devices has real advantages over what we're doing today, especially for devices with multiple network interfaces 🌈 Pulling data over several links in parallel is a huge win for adaptive multimedia streaming. The client can hop between the available links depending on their bandwidth capabilities, and the DASH client doesn't even have to know it's happening 🫶 Main character energy, no cap 😭🔥
12. References 💜
12.1. Normative References 🎀
Okay, here are the normative ones, bestie. These are the receipts 🧾💅
[Rainer16] Rainer, B., Posch, D., and H. Hellwagner, "Investigating
the Performance of Pull-based Dynamic Adaptive Streaming
in NDN", IEEE Journal on Selected Areas in Communications
(J-SAC): Special Issue on Video Distribution over Future
Internet, Volume 34, Number 8,
DOI 10.1109/JSAC.2016.2577365, August 2016.
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements
of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972,
DOI 10.17487/RFC6972, July 2013,
<http://www.rfc-editor.org/info/rfc6972>.12.2. Informative References 🦋
And these are the informative ones 🌸 Super worth a read if you're obsessed with the deep dive 🤓✨
[ATIS-IIF] "ATIS: IIF, IPTV Interoperability Forum", 2015,
<http://www.atis.org/iif/deliv.asp>.
[Bakker15] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-
Peer Streaming Peer Protocol (PPSPP)", RFC 7574,
DOI 10.17487/RFC7574, July 2015,
<http://www.rfc-editor.org/info/rfc7574>.
[Castro03] Castro, M., Druschel, P., Kermarrec, A., Nandi, A., and A.
Rowstron, "SplitStream: High-Bandwidth Multicast in
Cooperative Environments", Proceedings of the 19th ACM
Symposium on Operating Systems Principles (SOSP '03),
DOI 10.1145/945445.945474, October 2003.
[Chai11] Chai, W., Wang, N., Psaras, I., Pavlou, G., Wang, C.,
de Blas, G., Ramon-Salguero, F., Liang, L., Spirou, S.,
Blefari-Melazzi, N., Beben, A., and E. Hadjioannou,
"CURLING: Content-Ubiquitous Resolution and Delivery
Infrastructure for Next Generation Services", IEEE
Communications Magazine, Volume 49, Issue 3,
DOI 10.1109/MCOM.2011.5723808, March 2011.
[Chanda13] Chanda, A., Westphal, C., and D. Raychaudhuri, "Content
Based Traffic Engineering in Software Defined Information
Centric Networks", 2013 IEEE Conference on Computer
Communications Workshops (INFOCOM WKSHPS),
DOI 10.1109/INFCOMW.2013.6970717, April 2013.
[Corujo12] Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar,
"A Named Data Networking Flexible Framework for Management
Communications", IEEE Communications Magazine, Volume 50,
Issue 12, DOI 10.1109/MCOM.2012.6384449, December 2012.
[Crabtree13]
Crabtree, B., Stevens, T., Allan, B., Lederer, S., Posch,
D., Mueller, C., and C. Timmerer, "Video Adaptation in
Limited/Zero Network Coverage", CCNxCon 2013, Palo Alto
Research Center (PARC), September 2013.
[Detti11] Detti, A., Blefari-Melazzi, N., Salsano, S., and M.
Pomposini, "CONET: A Content Centric Inter-Networking
Architecture", Proceedings of the ACM SIGCOMM Workshop on
Information-Centric Networking,
DOI 10.1145/2018584.2018598, August 2011.
[Detti12] Detti, A., Pomposini, M., Blefari-Melazzi, N., Salsano,
S., and A. Bragagnini, "Offloading cellular networks with
Information-Centric Networking: the case of video
streaming", 2013 IEEE 14th International Symposium on A
World of Wireless, Mobile and Multimedia Networks
(WoWMoM), DOI 10.1109/WoWMoM.2012.6263734, June 2012.
[Detti13] Detti, A., Ricci, B., and N. Blefari-Melazzi, "Peer-To-
Peer Live Adaptive Video Streaming for Information Centric
Cellular Networks", 2013 IEEE 24th Annual International
Symposium on Personal, Indoor, and Mobile Radio
Communications (PIMRC), DOI 10.1109/PIMRC.2013.6666771,
September 2013.
[Fiat94] Fiat, A. and M. Naor, "Broadcast Encryption", Advances in
Cryptology - CRYPTO '93 Proceedings, Lecture Notes in
Computer Science, Volume 773, pp. 480-491, 1994.
[Fu13] Fu, B., Kunzmann, G., Wetterwald, M., Corujo, D., and R.
Costa, "QoE-aware traffic management for mobile video
delivery", 2013 IEEE International Conference on
Communications Workshops (ICC),
DOI 10.1109/ICCW.2013.6649314, June 2013.
[Grandl13] Grandl, R., Su, K., and C. Westphal, "On the Interaction
of Adaptive Video Streaming with Content-Centric
Networks", 2013 IEEE International Conference on
Multimedia and Expo (ICME), DOI 10.1109/ICME.2013.6607500,
July 2013.
[IETF-PPSP]
IETF, "Peer to Peer Streaming Protocol (ppsp)",
<https://datatracker.ietf.org/wg/ppsp/>.
[ISO-DASH] ISO, "Information technology -- Dynamic adaptive streaming
over HTTP (DASH) -- Part 1: Media presentation description
and segment formats", ISO/IEC 23009-1:2014, May 2014.
[ITEC-DASH]
"ITEC - Dynamic Adaptive Streaming over HTTP", DASH
Research at the Institute of Information
Technology, Multimedia Communication Group, Alpen-Adria
Universitaet Klagenfurt, <http://dash.itec.aau.at>.
[Jacobson09a]
Jacobson, V., Smetters, D., Briggs, N., Plass, M.,
Stewart, P., Thornton, J., and R. Braynard, "VoCCN: Voice-
over Content-Centric Networks", Proceedings of the 2009
Workshop on Re-architecting the Internet,
DOI 10.1145/1658978.1658980, December 2009.
[Jacobson09b]
Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Briggs, N., and R. Braynard, "Networking Named Content",
Proceedings of the 5th International Conference on
Emerging Networking Experiments and Technologies (CoNEXT),
DOI 10.1145/1658939.1658941, December 2009.
[LeCallet13]
Le Callet, P., Moeller, S., and A. Perkis, "Qualinet White
Paper on Definitions of Quality of Experience", European
Network on Quality of Experience in Multimedia Systems and
Services, COST Action IC 1003, Version 1.2, March 2013.
[Lederer13a]
Lederer, S., Liu, Y., Geurts, J., Point, J., Lederer, S.,
Mueller, C., Rainer, B., Timmerer, C., and H. Hellwagner,
"Dynamic Adaptive Streaming over CCN: A Caching and
Overhead Analysis", 2013 IEEE International Conference on
Communication (ICC), DOI 10.1109/ICC.2013.6655116, June
2013.
[Lederer13b]
Lederer, S., Mueller, C., Rainer, B., Timmerer, C., and H.
Hellwagner, "An Experimental Analysis of Dynamic Adaptive
Streaming over HTTP in Content Centric Networks", 2013
IEEE International Conference on Multimedia and Expo
(ICME), DOI 10.1109/ICME.2013.6607500, July 2013.
[Magharei07]
Magharei, N., Rejaie, R., and Y. Guo, "Mesh or Multiple-
Tree: A Comparative Study of Live P2P Streaming
Approaches", IEEE INFOCOM 2007 - 26th IEEE International
Conference on Computer Communications,
DOI 10.1109/INFCOM.2007.168, May 2007.
[Medard12] Medard, M., Kim, M., Parandeh-Gheibi, M., Zeng, W., and M.
Montpetit, "Quality of Experience for Multimedia
Communications: Network Coding Strategies", Laboratory of
Electronics, Massachusetts Institute of Technology, March
2012.
[MEDIEVAL] "MEDIEVAL: MultiMEDia transport for mobIlE Video
AppLications", 2010, <http://www.ict-medieval.eu>.
[Montpetit13a]
Montpetit, M., Holtzman, H., Chakrabarti, K., and M.
Matijasevic, "Social video consumption: Synchronized
viewing experiences across devices and networks", 2013
IEEE International Conference on Communications Workshops
(ICC), pp. 286-290, DOI 10.1109/ICCW.2013.6649245, 2013.
[Montpetit13b]
Montpetit, M., Westphal, C., and D. Trossen, "Network
Coding Meets Information-Centric Networking: An
Architectural Case for Information Dispersion Through
Native Network Coding", Proceedings of the 1st ACM
Workshop on Emerging Name-Oriented Mobile Networking
Design-Architecture, Algorithms, and Applications,
DOI 10.1145/2248361.2248370, June 2013.
[Mueller12]
Mueller, C., Lederer, S., and C. Timmerer, "A Proxy Effect
Analysis and Fair Adaptation Algorithm for Multiple
Competing Dynamic Adaptive Streaming over HTTP Clients",
2012 IEEE Visual Communications and Image Processing
(VCIP), DOI 10.1109/VCIP.2012.6410799, November 2012.
[NETINF] "NetInf: Network of Information", <http://www.netinf.org>.
[Posch13] Posch, D., Hellwagner, H., and P. Schartner, "On-Demand
Video Streaming based on Dynamic Adaptive Encrypted
Content Chunks", Proceedings of the 8th International
Workshop on Secure Network Protocols (NPSec '13),
DOI 10.1109/ICNP.2013.6733673, October 2013.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<http://www.rfc-editor.org/info/rfc7476>.
[RFC7846] Cruz, R., Nunes, M., Xia, J., Huang, R., Ed., Taveira, J.,
and D. Lingli, "Peer-to-Peer Streaming Tracker Protocol
(PPSTP)", RFC 7846, DOI 10.17487/RFC7846, May 2016,
<http://www.rfc-editor.org/info/rfc7846>.
[Su14] Su, K. and C. Westphal, "On the Benefit of Information
Centric Networks for Traffic Engineering", 2014 IEEE
International Conference on Communications (ICC),
DOI 10.1109/ICC.2014.6883810, June 2014.Acknowledgments ✨
okay bestie, big thank yous 🫶 this work got support from the European Community through the SocialSensor project (FP7-ICT-287975) 💖, and it was partly done in the Lakeside Labs research cluster at AAU 🌸. SocialSensor gets its research funding from the European Community's Seventh Framework Programme 💅. Part of this work also happened in the FP7/NICT EU-JAPAN GreenICN project, which lives at http://www.greenicn.org 🌈.
ngl, the legal-ish bit is important: the European Commission is not responsible for what's in this document 🙈. Everything here is provided "as is," with no guarantee or warranty that it's fit for any particular purpose. Whoever uses the information does so at their own sole risk and liability 💀 so read that part before you build anything with it 😭
Authors' Addresses 🦋
Here's the squad, with where to find them 🧚
Cedric Westphal (editor) 👑 Huawei Email: Cedric.Westphal@huawei.com
Stefan Lederer 🌸 Alpen-Adria University Klagenfurt Email: stefan.lederer@itec.aau.at
Daniel Posch 🍓 Alpen-Adria University Klagenfurt Email: daniel.posch@itec.aau.at
Christian Timmerer 💜 Alpen-Adria University Klagenfurt Email: christian.timmerer@itec.aau.at
Aytac Azgin ✨ Huawei Email: aytac.azgin@huawei.com
Will (Shucheng) Liu 🎀 Huawei Email: liushucheng@huawei.com
Christopher Mueller 🦋 BitMovin Email: christopher.mueller@bitmovin.net
Andrea Detti 🌈 University of Rome Tor Vergata Email: andrea.detti@uniroma2.it
Daniel Corujo 🫶 Instituto de Telecomunicacoes Aveiro Email: dcorujo@av.it.pt
Jianping Wang 💅 City University of Hong Kong Email: jianwang@cityu.edu.hk
Marie-Jose Montpetit ⭐ MIT Email: marie@mjmontpetit.com
Niall Murray 🔥 Athlone Institute of Technology Email: nmurray@research.ait.ie
📦 where this page comes from
- ietf: rfc7933 2016-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms