Network Overlay Impacts to Streaming Video

Internet-Draft	NOISV	July 2026
Deen & Mishra	Expires 7 January 2027	[Page]

Abstract

This document examines the operational impacts on streaming video applications resulting from network policy changes introduced by network overlays. Such overlays may alter IP address assignment, transport protocols, routing behavior, or DNS resolution. These changes can, in turn, affect critical aspects of content delivery, including latency, CDN cache selection, delivery path optimization, traffic classification, and content access controls.¶

4. Internet Privacy Enhancements

The IETF’s efforts to strengthen Internet privacy and mitigate pervasive monitoring, as described in [RFC7258], have driven a series of architectural and protocol-level developments. The initial focus was on encrypting network data flows, most commonly through the wider adoption of Transport Layer Security (TLS). Over time, these efforts have expanded to include changes at the policy and design level, such as modifying routing paths, selecting privacy-preserving DNS resolvers, and introducing encrypted transport protocols, to better obscure and isolate user traffic from observation within the underlying network infrastructure.¶

[RFC7258] identifies pervasive monitoring as an attack on privacy, while [RFC7624] outlines potential technical and operational responses to mitigate its impact. The development of the QUIC transport protocol, defined in [RFC9000], exemplifies the application of these principles. QUIC integrates confidentiality, integrity, and authentication into the transport layer itself, ensuring that user data and most protocol metadata remain encrypted by default.¶

Collectively, these privacy-enhancing measures have reshaped how networks and applications interact. However, they also introduce new considerations for operational visibility, traffic management, and performance optimization, which are particularly relevant to streaming video applications.¶

4.1. Network Overlays

The IETF’s privacy-enhancement efforts in response to [RFC7258] have driven a range of architectural and policy design choices, including the adoption of “always-on” encryption, as exemplified by QUIC [RFC9000]. While many such developments have minimal impact on video streaming, some introduce new behaviors that can be described as creating network overlays, which are logical networks that operate on top of the underlying native network but apply different routing, transport, or policy decisions than either the native network or the streaming application would independently choose.¶

Network overlays that alter policies or paths in ways not directly visible, selectable, or detectable by the streaming application or platform can have significant operational effects. These overlays may silently modify network properties, such as source IP addresses, DNS resolver choices, or routing behavior, without the knowledge of the streaming service or end user. Such hidden policy changes can inadvertently disrupt the assumptions underlying adaptive streaming architectures, content delivery path optimization, or CDN selection mechanisms.¶

When a network overlay modifies connection properties in ways that differ from application expectations, the result can be mismatched assumptions between the application and the actual transport environment. This disconnect may cause degraded performance, misclassification of network paths, or unexpected latency and throughput characteristics, all of which affect streaming quality and operational predictability.¶

Protocols such as MASQUE [RFC9484] and services built on it such as Apple's iCloud Private Relay illustrate privacy-enhancing network overlays that deliberately alter connection policies relative to the open Internet. While beneficial for user privacy, such mechanisms can also obscure the visibility and control that streaming services rely on for consistent content delivery and Quality of Experience (QoE) management.¶

4.2. Transparency and Connection Policy

What matters when considering network overlay impact on streaming is not the technology or protocol used, but whether the alternative network connection policies applied are transparent or hidden from the connection endpoints.¶

Prior to network overlays, connection policy changes tended to be transparent to the application-server connection. Changes made to the connection were visible to one or both sides, enabling the connection endpoints to have awareness of the policies applied.¶

The issue this document focuses on is where alternative network connection policies are non-transparent to the connection endpoints, particularly the application. The application is the party architecturally designated to make decisions about network connection properties and policies, and non-transparent overlays remove that ability without any indication to the application that this has occurred.¶

This distinction means that even classic connection policy approaches such as Layer 2 VPNs fall within this document's problem statement if they operate non-transparently to the connection endpoints, and particularly to the application.¶

Network overlays also affect end-to-end connection autonomy. When an application opens a connection, it does so based on server-published endpoint information, obtained via DNS or direct IP addressing. Network overlays silently intercept that connection, rerouting or readdressing it and making new path choices without the client being involved. Neither the application nor the server has signaled consent to this interception, and neither endpoint receives any indication that the path or addressing has changed. This silent substitution of routing decisions is distinct from what a traditional VPN does, where the application is aware that its traffic is traversing an overlay and the network operator has explicitly configured that behavior.¶

Historically, the issues discussed in this document have not been a major concern for typical VPN deployments, largely because VPNs have not been a pervasive way to stream video. Many VPNs have not offered throughput or consistency comparable to a direct Internet path, and many video platforms block or degrade service to detected VPN connections due to their common use in bypassing geofiltering restrictions.¶

Where a distinction is useful operationally, it is not the technology or protocol used but the deployment pattern in common use. Traditional and newer overlay deployments have tended to differ along the following lines.¶

4.2.1. Transparent connection policy approaches:

(1) are generally detectable by the application and the network operator.¶
(2) typically work at the network layer of a device, so a wide range, if not all, of the device's transports and protocols flow through the overlay.¶
(3) typically provide exception options allowing traffic to be excluded based on criteria such as application, destination IP address, or application protocol.¶

4.2.2. Non-transparent connection policy approaches:

(1) are often undetectable by video applications or the streaming platform while in use.¶
(2) often apply only to specific application transports, such as HTTP/2 over TCP or HTTP/3 over QUIC, while leaving other transports on the same device, such as TCP+TLS, unaffected.¶
(3) often apply only to HTTP connections, without support for ICMP, non-HTTP DNS, NTP, or the other non-HTTP-based tools used for network measurement, problem determination, and network management.¶
(4) do not expose to applications any means of discovering what policy changes the overlay applies to their network connections.¶
(5) do not expose mechanisms or APIs for applications to interact with the overlay, such as getting or setting options.¶

These are patterns of observed deployment behavior, not categories defined by protocol specification. What determines whether a connection policy mechanism falls within the scope of this document is whether it operates non-transparently to the connection endpoints, not the protocol or technology it uses.¶

Even where a network overlay operates transparently to the connection endpoints, the operational impacts described in this document, including protocol changes, tunneling effects, and path alterations, remain significant considerations for streaming video deployments.¶

4.2.3. Emerging Operational Issues with Network Overlay Policy Changes

Streaming video applications and content delivery platforms are increasingly encountering operational challenges associated with network overlays. These challenges arise when overlays introduce policy changes that are unexpected, inconsistently applied, or difficult or impossible for the streaming platform to detect or adapt to in real time. While the specific impacts vary depending on the overlay’s design and implementation, several common classes of operational issues have been observed across deployments. These include mismatches in routing and cache selection, unexpected transport-layer behavior, and inconsistencies in latency or throughput reporting that affect Quality of Experience (QoE) monitoring and optimization.¶

4.3. Policy Changes

Changes to network policies introduced by overlays can alter the expected behavior of streaming applications in several ways.¶

For example, an overlay that modifies encryption policies, such as transforming HTTP URLs in manifests into HTTPS connections, can disrupt architectures that rely on the network’s ability to identify or classify video flows. In such cases, the visibility of traffic used for caching, optimization, or QoS treatment may be reduced or lost entirely.¶

Similarly, overlays that alter routing policies can interfere with the Content Delivery Network (CDN) cache selection logic used by streaming platforms. A change in routing path may cause the application to connect to a more distant cache, resulting in higher latency, lower throughput, and degraded video quality, even when a closer cache would otherwise have been selected.¶

An example of a routing policy change is illustrated in Figure 1, showing how a network overlay can apply a routing policy that diverges from that of the underlying base network, resulting in a modified traffic path and different delivery characteristics.¶

 R  = router
                  <--- non-overlay traffic path --->
 device -- R ---- R ------------- R ------------- R ---- R -- dest-node
            \                                           /
             \                                         /
              \                                       /
               R -- R -- ingest -- egress -- R ------+
                     <--- overlay traffic path --->

 Figure 1:  Network Overlay routing selects traffic via an alternate path

4.3.1. Partitioning

Network Overlay policy changes often include the use of alternate routing policies, as a core element of their design involves tunneling connections through different network paths to enhance user privacy and reduce tracking. This architectural concept, partitioning, is further discussed in the IAB document Partitioning as an Architecture for Privacy. By isolating traffic and obscuring its correlation with the underlying native network, partitioning helps defend against pervasive monitoring and traffic analysis.¶

While effective for privacy protection, these routing partitions can also alter network visibility and path selection in ways that affect streaming video performance, such as cache selection accuracy, latency, and adaptive bitrate (ABR) responsiveness.¶

4.3.2. Protocol Policy Changes

Network overlays have been observed to alter application and transport protocols from those originally selected by the streaming application. In some cases, privacy-enhancing or optimization mechanisms automatically translate connections, for example converting HTTP/2 over TCP into HTTP/3 over QUIC, or upgrading HTTP/2 sessions to HTTPS with TLS encryption. Such conversions are typically performed to enforce stronger privacy, security, or efficiency policies, but they may occur without visibility or control by the streaming application.¶

A key operational impact arises when protocol substitution changes the network characteristics perceived by the video application. A video application may perform a preliminary fetch to measure network conditions before selecting an appropriate bitrate for content delivery. If the application’s test probe uses HTTP/2 over TCP but the subsequent content request is silently converted by the overlay to HTTP/3 over QUIC, the measured results no longer reflect the actual transport path. This mismatch can lead to inaccurate bandwidth estimation, causing the adaptive bitrate (ABR) algorithm to select non-optimal streaming parameters and degrade user experience.¶

4.3.3. Encryption Policy

Changes to the encryption policy applied to video streams, whether by adding encryption where it was not originally used or by removing or terminating encryption where it was expected, can introduce significant operational challenges for streaming applications and delivery networks.¶

In some cases, network overlays or privacy-enhancing systems may automatically enforce encryption, converting plaintext HTTP video traffic into HTTPS or encapsulating transport flows within encrypted tunnels. While this improves confidentiality, it can also obscure traffic classification and disable optimizations that rely on visibility into flow metadata, such as CDN cache selection, adaptive bitrate tuning, or Quality-of-Service (QoS) marking.¶

Conversely, if encryption is removed or terminated prematurely, such as through a proxy that decrypts and re-encrypts video traffic, it can violate end-to-end security assumptions made by the application or CDN, potentially exposing content or user data to unauthorized inspection.¶

In both cases, mismatched encryption policies between the streaming application, CDN, and the underlying network can lead to reduced performance, incorrect cache usage, or inconsistent delivery behavior.¶

4.3.3.1. Forced Encryption Upgrade

Enforcing encryption upgrades, for example converting unencrypted HTTP/2 traffic into HTTP/2 over TLS (HTTPS), can disrupt streaming workflows that rely on the network’s ability to inspect or classify content as part of the delivery process. When network visibility into streaming flows is removed, content-aware optimizations such as CDN cache selection, multicast distribution, or traffic prioritization may fail to function as designed. As a result, video traffic may be misclassified as generic encrypted data, leading to incorrect policy enforcement or suboptimal delivery behavior.¶

This issue is particularly significant in mobile and multicast-based environments, where network-assisted detection of video streams is often required to achieve efficient bandwidth utilization and maintain quality of experience. In such cases, forced encryption upgrades may prevent the network from applying appropriate delivery optimizations, resulting in degraded performance or increased operational complexity.¶

4.3.3.2. Forced Encryption Downgrade

Conversely, removal or termination of encryption originally applied by a streaming platform can introduce serious operational and security concerns. In many streaming architectures, transport-level encryption, such as HTTPS or QUIC, is not only used to ensure confidentiality but also forms an integral part of the content protection and integrity assurance mechanisms.¶

When an intermediate network overlay or proxy terminates TLS sessions or otherwise downgrades an encrypted connection to plaintext, it can invalidate end-to-end trust assumptions between the client, CDN, and content provider. Such behavior may expose sensitive metadata, enable unauthorized content inspection or modification, and violate Digital Rights Management (DRM).¶

In effect, a forced encryption downgrade undermines both security and operational reliability, leading to potential playback failures, content delivery errors, or loss of user trust.¶

4.3.4. Address Policy Changes

Network overlays that modify IP addressing policies, such as converting IPv4 to IPv6, IPv6 to IPv4, or reassigning source IP addresses, can introduce a range of operational challenges for streaming platforms, particularly when these changes occur unexpectedly or are invisible to the application. Such address changes can disrupt routing decisions, CDN cache selection, and traffic localization processes that depend on stable endpoint addresses. They also complicate diagnostic and troubleshooting efforts, as engineers analyzing logs, performing test probes, or correlating session data may inadvertently use incorrect or outdated IP information.¶

A related issue arises when the source IP address observed by the streaming platform differs from that seen by the client application or device. Because many streaming architectures use IP-based session binding, such as platform authentication gateways that associate user or device authorization with a specific IP address, unannounced address translation can result in service access failures, login rejections, or denied content delivery. For example, when an overlay reassigns or masks the client’s IP address, the streaming platform may interpret this as a new or unauthorized connection, even though the client session remains active. This mismatch can lead to intermittent playback interruptions, degraded user experience, or increased operational complexity for both service providers and network operators.¶

4.3.5. DNS Policy Changes

Network overlays that modify DNS resolver settings or redirect DNS queries can have significant implications for Content Delivery Networks (CDNs) that rely on DNS-based load balancing for cache selection and traffic localization.¶

Many CDN architectures determine the best cache for a client by observing the source IP address of the DNS resolver making the request. When an overlay substitutes or masks the resolver, either intentionally or as part of privacy-enhancing policies, the CDN may incorrectly infer the client’s location, resulting in non-optimal cache selection, increased latency, or reduced video quality.¶

4.3.5.1. EDNS0

The EDNS(0) (Extension Mechanisms for DNS, [RFC6891]) extension was introduced to allow resolvers to include additional client subnet information in DNS queries, improving CDN cache selection accuracy. If a network overlay redirects DNS queries to a resolver that does not support EDNS(0) or deliberately strips this information, the CDN loses critical context for determining the most appropriate edge cache. This can lead to the selection of a distant or overloaded cache, negatively impacting video startup time, buffering, and overall user experience.¶

4.3.6. Log Data Changes

Accurate and consistent logging is essential for diagnosing streaming performance and operational issues. Network overlays that alter connection properties, such as DNS resolvers, IP addresses, or transport protocols, can cause log entries to differ between the client device and the streaming platform. When such discrepancies occur, engineers attempting to correlate logs for troubleshooting may misinterpret session behavior or fail to identify the true source of a problem. Unexpected or misleading log data therefore undermines both problem determination and root-cause analysis, complicating operational monitoring and incident response workflows.¶

4.3.7. Geo Location & Identification

Network overlays that alter the apparent source location of user devices can interfere with streaming platforms’ ability to accurately determine geospatial attributes such as country, region, or network domain.¶

Many CDNs and content providers rely on IP address based geolocation to enforce regional content licensing, apply local regulations, or select nearby caches for optimal performance. When an overlay substitutes or masks the client’s IP address, presenting it as originating from a different region or outside of known geolocation mappings, the platform may be unable to correctly associate the user with their actual location.¶

This can result in users being denied access to region-restricted content that they would otherwise be authorized to view, or being directed to distant CDN caches, causing degraded video quality and higher latency.¶

In addition, such location ambiguity complicates analytics, fraud detection, and rights management processes that depend on consistent geographic identifiers.¶

4.3.8. CDN Interconnection Troubleshooting

In CDN interconnection scenarios, when two CDN domains collaborate to localize a point of failure, they typically begin by identifying the delivery path and selecting observation points along that path to take diagnostic measurements. Through iterative testing, they narrow down the problem domain to isolate the failure’s location.¶

However, when network overlays alter routing behavior, this process becomes unreliable. CDNs depend on their request routing information to determine where along the delivery path measurements should be taken. The presence of an overlay that reroutes or tunnels traffic means that the expected observation point no longer lies on the actual traffic path. As a result, the flow cannot be observed where the CDN expects it to be, making fault localization and coordination between interconnecting CDNs significantly more difficult.¶

4.3.9. Routing Changes

Routing changes introduced by network overlays can alter the expected path between video applications and the infrastructure services they rely on. Such changes may cause a wide range of operational problems, including degraded performance, inconsistent latency, or failures in CDN cache selection and session persistence.¶

When routing behavior differs from what the video platform or application expects, content delivery optimizations such as proximity-based cache selection, adaptive bitrate decisions, and transport-layer congestion management can become ineffective. These effects can be difficult to detect, as the overlay’s routing policy is often not visible to the streaming application or operators monitoring network performance.¶

4.3.9.1. End to End Problem Discovery

A common issue in video delivery is locating where along the delivery path the video transport is encountering problems. Such problems are often more complex than a connection not working at all and instead involve identifying bottlenecks, lost packets, and congestion issues. When routing changes from what is expected or visible to support tools, it becomes an operational trouble spot for users and platform support to locate and determine the source of the problems.¶

4.3.9.2. CDN Edge Cache Selection due to Routing

A significant and often overlooked problem is the addition of network latency compared to edge CDN caches or access network peering connections. Routing changes that cause traffic to bypass edge CDN caches and instead reach less optimal caches are illustrated in the figure below.¶

 R  = router
           <--- non-overlay traffic path --->
 device -- R ---- R ---- Edge CDN Cache
            \
             \
              \
               R --- R -- ingest -- R --- R -- egress -- R ------R ---- Less Optimal CDN Cache
                     <--- overlay traffic path --->

 Figure:  Routing Changes altering CDN Cache selection

4.3.9.3. Performance and Problem Determination

Network overlays often interfere with the tools used in performance and problem determination. This is due to either the tools and protocols not being able to traverse the alternative route tunnel, impacting a service's ability to diagnose connection and performance problems, or the network overlay itself not supporting or carrying the tool's functions.¶

4.3.9.4. Impact of Changing Network Routing and Other Policies

The problem for streaming applications occurs when the underlying network properties and policies change from what the streaming application expects, especially when such changes are hidden or not visible to the application.¶

While the open Internet is a dynamic environment, changes to basic network behavior and policies that deviate unexpectedly from what the streaming application expects disrupt the optimized streaming delivery architecture for the end-user device. Changes to network policies such as routing, source IP address assignment, and DNS resolver choice influence this behavior.¶

Having a reliable understanding of the delivery path is essential for streaming operators. The introduction of network overlays, particularly those designed to be undetectable by the applications using them, has introduced new technical challenges for streaming operators, network operators, and their viewers.¶

The core problem occurs when changes to network policies are made without notification or visibility to applications and without clear methods for probing or testing the changed behaviors. The affected behaviors include increased latency, changes to the IP address seen by either the application or the streaming service, changes to DNS resolvers and the results they return, and changes to application transports such as adding or removing encryption. All of these have been observed in production streaming platforms.¶

4.3.10. Unintended Content Blocking

A strongly undesirable side-effect of network policy changes is the blocking of content to the viewer. This may affect primary content URLs, or possibly advertising fetched from a second URL alongside the main video content. Such blocking can be due to policy changes altering device IP addresses, or routing changes that conflict with enforced traffic routing policies.¶

Such blocking may be connected to restrictions built upon data feeds used for geofiltering and georestrictions, for example restrictions that block delivery to networks identified as commercial data centers or CDN service network addresses. Essentially, this is running afoul of configurations used to combat security threats that expect streaming viewers to be on home or mobile networks, not in commercial data centers or CDN content networks. This is more likely to occur in network overlays that shift egress traffic to commercial or CDN address blocks.¶

This is a particularly difficult problem to diagnose as it may appear inconsistently from one streaming session to another. Small changes in URLs in manifests from one session to another are especially problematic on streaming platforms that use multi-CDN delivery, where different delivery and security protection policies from different CDN operators may be encountered.¶