Network Overlay Impacts to Streaming Video
draft-ietf-mops-network-overlay-impacts-04
| Document | Type | Active Internet-Draft (mops WG) | |
|---|---|---|---|
| Authors | Glenn Deen , Sanjay Mishra | ||
| Last updated | 2026-07-06 | ||
| Replaces | draft-deen-mops-network-overlay-impacts | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Associated WG milestones |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-mops-network-overlay-impacts-04
Media OPerationS G. Deen
Internet-Draft Comcast-NBCUniversal
Intended status: Informational S. Mishra
Expires: 7 January 2027 Verizon
6 July 2026
Network Overlay Impacts to Streaming Video
draft-ietf-mops-network-overlay-impacts-04
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.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at https://ietf-wg-
mops.github.io/draft-ietf-mops-network-overlay-impacts/draft-ietf--
mops-network-overlay-impacts.html. Status information for this
document may be found at https://datatracker.ietf.org/doc/draft-ietf-
mops-network-overlay-impacts/.
Discussion of this document takes place on the Media OPerationS
Working Group mailing list (mailto:mops@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/mops/. Subscribe at
https://www.ietf.org/mailman/listinfo/mops/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-mops/draft-ietf-mops-network-overlay-
impacts.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Deen & Mishra Expires 7 January 2027 [Page 1]
Internet-Draft NOISV July 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 7 January 2027.
Copyright Notice
Copyright (c) 2026 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Streaming Applications: Optimized for Scaling and Latency . . 3
3. Network Overlays: Privacy Enhancements and Operational
Features . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Internet Privacy Enhancements . . . . . . . . . . . . . . . . 5
4.1. Network Overlays . . . . . . . . . . . . . . . . . . . . 5
4.2. Transparency and Connection Policy . . . . . . . . . . . 6
4.2.1. Transparent connection policy approaches: . . . . . . 7
4.2.2. Non-transparent connection policy approaches: . . . . 7
4.2.3. Emerging Operational Issues with Network Overlay Policy
Changes . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Policy Changes . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Partitioning . . . . . . . . . . . . . . . . . . . . 9
4.3.2. Protocol Policy Changes . . . . . . . . . . . . . . . 10
4.3.3. Encryption Policy . . . . . . . . . . . . . . . . . . 10
4.3.4. Address Policy Changes . . . . . . . . . . . . . . . 12
4.3.5. DNS Policy Changes . . . . . . . . . . . . . . . . . 12
4.3.6. Log Data Changes . . . . . . . . . . . . . . . . . . 13
4.3.7. Geo Location & Identification . . . . . . . . . . . . 13
4.3.8. CDN Interconnection Troubleshooting . . . . . . . . . 14
4.3.9. Routing Changes . . . . . . . . . . . . . . . . . . . 14
4.3.10. Unintended Content Blocking . . . . . . . . . . . . . 16
5. Policy Changes Hidden from Applications . . . . . . . . . . . 16
6. Making It Easy (for Users) by Working Under the Covers . . . 17
7. Streaming Video . . . . . . . . . . . . . . . . . . . . . . . 17
Deen & Mishra Expires 7 January 2027 [Page 2]
Internet-Draft NOISV July 2026
7.1. Advances in Streaming Video Architecture . . . . . . . . 18
8. Middleboxes and Learning from the Past . . . . . . . . . . . 19
9. Conventions and Definitions . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction
This document explores the unintended operational impacts of network
overlays, such as VPNs and MASQUE-based tunnels, on highly scalable
Internet streaming applications. Because these streaming
architectures are optimized for specific network environments,
overlay-enforced policy changes can degrade performance. This
analysis serves as a foundational exploration to guide future work
regarding potential mitigations and design improvements.
The authors acknowledge the inherent friction between maximizing
Internet transport privacy and maintaining the operational efficiency
of data-intensive applications. Integrating these competing
operational requirements into architectural designs is a complex
task.
The purpose of this document is to establish a clear problem
statement regarding these operational impacts. It documents the
negative externalities observed by streaming platforms when privacy-
enhancing overlays or unexpected network policy changes disrupt the
delivery path. This analysis aims to provide application developers,
platform architects, network operators, and protocol designers with a
shared framework for understanding how overlay mechanisms impact
deterministic video delivery. Accounting for these operational
realities is vital for future protocol design; however, defining
specific mitigations is out of scope for this document and is left to
future work.
2. Streaming Applications: Optimized for Scaling and Latency
Internet video streaming has become a global utility for billions of
viewers, evolving by necessity into a highly optimized operational
ecosystem. This ecosystem delivers live sports, entertainment,
linear television, user-generated content (UGC), and breaking news to
any Internet-connected device across heterogeneous networks,
including high-bandwidth fixed lines, mobile, and Wi-Fi.
Consequently, streaming dominates Internet traffic as documented in
[RFC9317].
Deen & Mishra Expires 7 January 2027 [Page 3]
Internet-Draft NOISV July 2026
These sessions require sustained, data-intensive throughput. For
example, a single hour of high-definition (HD) video utilizes
continuous flows of 0.5–8.0 Mbps (totaling approximately 0.2–3.6 GB),
while 4K video demands 4.0–20.0 Mbps (totaling approximately 1.8–9.0
GB).
To support this volume, the video streaming ecosystem relies on
sophisticated network and data management methodologies. This
includes the IETF’s Content Delivery Network Interconnection (CDNI)
frameworks for tiered CDN topologies and downstream CDN selection/
orchestration. Each streaming platform carefully architects its
delivery pipeline around deterministic network policies, predictable
routing, and explicit path signaling. This optimization is critical
to meet scaling demands regarding simultaneous viewer concurrency,
aggregate data volume, and the ultra-low latency thresholds required
for interactive and live sports viewing. The foundations of this
application ecosystem are discussed in [RFC9317], though the
technology has continued to evolve significantly since its
publication.
Regardless of content type, the successful delivery of data at this
scale requires a well-understood, end-to-end application and
networking architecture. The workflow behaves predictably and
consistently according to the design assumptions of the video
streaming architects.
3. Network Overlays: Privacy Enhancements and Operational Features
Enhancing Internet user privacy has been a core focus of the IETF
following the publication of [RFC7258], which established pervasive
surveillance as a technical attack. [RFC7624] further detailed these
technical threats and outlined high-level mitigation approaches.
Since then, IETF working groups have systematically addressed these
vectors, producing new standards with native privacy protections.
Protocols like QUIC [RFC9000] exemplify this shift, embedding always-
on transport encryption and wire-image obfuscation directly into the
protocol design.
Concurrently, application-layer and transport-layer network
overlays—such as Virtual Private Networks (VPNs) and MASQUE-based
tunnels—have emerged as easily deployable mechanisms to shield user
traffic from network intermediaries. However, as consumer operating
systems, browsers, and applications increasingly integrate these
privacy-enhancing overlays, they introduce architectural changes to
the underlying network behavior.
Deen & Mishra Expires 7 January 2027 [Page 4]
Internet-Draft NOISV July 2026
These overlays frequently obfuscate client IP geolocation, alter path
MTU characteristics, disrupt standard anycast routing, inject
transport-layer jitter, or mask flow identifiers. Such changes
directly interfere with or undermine the traffic engineering,
localized edge-caching, load balancing, and low-latency optimizations
that streaming platforms rely upon.
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.
Deen & Mishra Expires 7 January 2027 [Page 5]
Internet-Draft NOISV July 2026
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 (https://www.apple.com/privacy/docs/
iCloud_Private_Relay_Overview_Dec2021.PDF) 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.
Deen & Mishra Expires 7 January 2027 [Page 6]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 7]
Internet-Draft NOISV July 2026
* (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.
Deen & Mishra Expires 7 January 2027 [Page 8]
Internet-Draft NOISV July 2026
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 (https://datatracker.ietf.org/doc/
draft-iab-privacy-partitioning/). 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.
Deen & Mishra Expires 7 January 2027 [Page 9]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 10]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 11]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 12]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 13]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 14]
Internet-Draft NOISV July 2026
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.
Deen & Mishra Expires 7 January 2027 [Page 15]
Internet-Draft NOISV July 2026
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.
5. Policy Changes Hidden from Applications
One of the central recurring issues with streaming applications
running on devices or networks with changed policies due to network
overlays is that the changes are often hidden from the applications.
Applications often find it difficult or even impossible to detect
when network policy changes will be active and what they are
changing. For example, a device may have a designated default DNS
resolver but a different resolver may be selected depending on how
the streaming application queries DNS.
Deen & Mishra Expires 7 January 2027 [Page 16]
Internet-Draft NOISV July 2026
Likewise, a streaming application might find that one application
transport protocol such as HTTP has one set of routing policies
applied to it while a different transport such as HTTPS has a
different set of routing policies applied.
Streaming applications that cannot determine the expected behavior
are prevented from making good content source decisions and from
providing reliable feedback and logs when problems are encountered.
6. Making It Easy (for Users) by Working Under the Covers
Historically, incorporating privacy features into consumer-facing
products has been complex. This challenge arises from the need to
address a wide range of use cases while also offering users easy
access to advanced privacy frameworks and taxonomies. Many attempts
have been made and very few have found success with end users.
Perhaps learning from the lessons of offering too many options, the
recent trend in privacy enhancements has steered toward either a very
simple "Privacy On or Off" switch or in other cases automatically
enabling or upgrading to enhance privacy. Apple's iCloud Private
Relay can be easily turned on with a single settings switch, while
privacy features such as Encrypted DNS over HTTP and upgrades from
HTTP to HTTPS connections have seen several deployments that
automatically enable them for users when possible.
Keeping with the motto of "Keep It Simple", users are generally not
provided with granular Network Overlay controls permitting them to
select what applications or network connections the Network Overlay
policies apply to.
Adhering to the "Keep It Simple" approach, the application itself has
very little connection to privacy-enhancing Network Overlays.
Applications generally do not have a means to detect when networking
policy changes are active. Applications generally do not have a
means to access policy change settings or to interact to change them.
7. Streaming Video
Streaming Video, while just one of the many different Internet
applications, stands out from other uses in several significant ways
that merit consideration when understanding and addressing the
impacts caused by particular privacy-enhancing design and service
offering choices.
Streaming video operates at a scale that is hard to imagine.
Streaming is served globally to more than 2 billion users daily and
continues to grow.
Deen & Mishra Expires 7 January 2027 [Page 17]
Internet-Draft NOISV July 2026
The content types delivered through streaming have evolved from pre-
recorded low-resolution, low-bitrate, latency-tolerant video-on-
demand movies, live or pre-recorded TV shows, and user generated
videos delivered by pioneering streaming platforms to now including
low-latency 4K and 8K live sports events, while also evolving pre-
recorded content to high-bitrate 4K and 8K cinema quality and High
Dynamic Range (HDR) lighting.
The expectations of streaming video viewers have also significantly
evolved from the days of watching a movie in a PC browser. Viewers
expect to watch on any device they want, ranging from low-end
streaming sticks that plug into a USB port to 4K and HDR capable
laptops, 4K and 8K HDR TV screens, gaming consoles, and smartphones.
Viewers also expect the same great viewing experience whether at home
on high-speed wired Internet, high-speed WiFi, mobile cellular 5G, or
even satellite Internet connections.
To meet the growth to billions of users, expanded content types and
quality expectations, and any-device anywhere over any network
expectations, the streaming video technology infrastructure has had
to evolve significantly. This work is being done in the IETF and in
the Streaming Video Technology Alliance (SVTA)
(https://www.svta.org/), and in a number of other technical and
industry groups.
The growth of streaming video has contributed enormously to the
growth of the Internet. Internet connections at hundreds of megabits
and gigabit speeds today exist because of the needs of video
streaming, and the ongoing work on low-latency networking and ultra-
low-latency video delivery are both driven by streaming video.
7.1. Advances in Streaming Video Architecture
Internet streaming has greatly matured and diversified from its early
days of viewers watching pre-recorded standard definition 480p movies
on wired PCs connected via high-latency, low-bandwidth DSL or early
DOCSIS modems.
Streaming has grown to the extent that it has become a daily video
source for billions of viewers worldwide and has expanded from pre-
recorded movies to encompass every type of video content imaginable.
This growth to billions of viewers and the addition of latency-
sensitive content and new connectivity options including WiFi,
cellular, and satellite, in addition to high-speed DOCSIS and fiber,
defines the world streaming platforms now serve.
With this large user base and its usage patterns, streaming platforms
face significant technical challenges in meeting viewer expectations:
Deen & Mishra Expires 7 January 2027 [Page 18]
Internet-Draft NOISV July 2026
* (1) Delivery scales that commonly range from hundreds of thousands
to many millions of simultaneous viewers, with billions of daily
global views.
* (2) Low latency demands from live sports, live events, and live
streamed content.
* (3) Content resolutions that have jumped from SD 480p to 4K
(3840x2160) and 8K (7680x4320), with bitrate requirements of
10-24+ Mbps for 4K and 40 Mbps under extreme compression or
150-300 Mbps for high quality cinema-grade 8K.
* (4) Devices with very diverse capabilities, from low-cost
streaming sticks to Smart TVs, tablets, phones, and game consoles.
* (5) A broad range of connectivity choices including WiFi, gigabit-
speed low-latency DOCSIS, fiber, satellite, and 5G cellular
networks.
* (6) Application transport protocols including MPEG DASH, HLS,
HTTP/2 over TCP, HTTP/3 over QUIC, WebRTC, Media over QUIC (MoQ),
and specialty transports such as SRT and HESP.
To meet these challenges, streaming platforms have significantly
invested in developing delivery architectures built on detailed
understanding of each element in the content delivery pathway, from
content capture all the way through to the viewer's screen.
Streaming applications are part of an end-to-end architecture
optimized around achieving the best experience including low latency
video delivery to viewing devices. The open Internet can be
unpredictable with temporary issues like packet loss, congestion, and
other conditions. However, streaming architecture is designed to
handle these momentary problems as effectively as possible, often
through dynamic adaptive approaches designed into streaming protocols
and platform components.
8. Middleboxes and Learning from the Past
The IETF has discussed this situation in the past. More than 20
years ago, in 2002, Middleboxes: Taxonomy and Issues [RFC3234] was
published, capturing the issues with middleboxes in the network and
the effects of hidden changes occurring on the network between the
sender and receiver.
Deen & Mishra Expires 7 January 2027 [Page 19]
Internet-Draft NOISV July 2026
9. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
10. Security Considerations
TODO Security
11. IANA Considerations
This document has no IANA actions.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
<https://www.rfc-editor.org/rfc/rfc3234>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/rfc/rfc6891>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/rfc/rfc7258>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/rfc/rfc7624>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Deen & Mishra Expires 7 January 2027 [Page 20]
Internet-Draft NOISV July 2026
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9317] Holland, J., Begen, A., and S. Dawkins, "Operational
Considerations for Streaming Media", RFC 9317,
DOI 10.17487/RFC9317, October 2022,
<https://www.rfc-editor.org/rfc/rfc9317>.
[RFC9484] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A.,
Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP",
RFC 9484, DOI 10.17487/RFC9484, October 2023,
<https://www.rfc-editor.org/rfc/rfc9484>.
Acknowledgments
The authors would like to acknowledge the contributions from the
Streaming Video Technology Alliance (SVTA) based on their work
studying the impacts of network overlays on streaming platforms. The
contributions from Brian Paxton on observed overlay behavior and
comments from Jay Robertson have been very helpful. The authors are
also grateful to Leonard Giuliano, Emile Stephan, and Kyle Rose for
their reviews and contributions to this document.
Authors' Addresses
Glenn Deen
Comcast-NBCUniversal
Email: glenn_deen@comcast.com
Sanjay Mishra
Verizon
Email: sanjay.mishra@verizon.com
Deen & Mishra Expires 7 January 2027 [Page 21]