P2P Hybrid Streaming

P2P hybrid streaming delivers video through the audience as well as through the CDN. It is also called peer-assisted delivery or hybrid CDN/P2P. Once a viewer's player holds a segment, the device can re-upload it to other viewers over WebRTC data channels. A single fetch from the edge server can then end up serving many viewers. It is not a replacement for the CDN, and it is not anonymous file sharing. The CDN edge seeds every segment and stays the fallback. The origin stays the source of truth. Manifest and licence requests never travel between peers. What you actually trade is CDN egress for the viewers' own upload capacity, plus a JavaScript control plane in the page.

Two different markets run the same mechanism. Confusing them is the usual mistake. Public streaming sites bolt a peer mesh onto a commercial CDN to cut an egress bill. Enterprises deploy it as an eCDN, so that a few thousand employees watching one town hall do not saturate the office internet link. Almost every published offload percentage comes from the second case. The payoff in both depends on many viewers wanting the same segments within seconds of each other. That makes this an event and live-crowd technique rather than a long-tail one.

How it works

The stream stays ordinary HLS or DASH over HTTP. The packaging does not change. A JavaScript player plugin and client SDK are added to the page. A hosted control plane joins viewers into a mesh, so this is not a serverless design. Microsoft documents its own implementation as four backend and client parts: a peering discovery service, a switchboard that creates the initial peer connections, a player plugin that intercepts video requests, and a client SDK that decides where each request goes (Microsoft eCDN technical overview). In order:

1. Transport. Peers move segments over WebRTC data channels. RFC 8831 specifies these as SCTP encapsulated in DTLS, carried over ICE/UDP. That encapsulation "provides a NAT traversal solution together with confidentiality, source authentication, and integrity-protected transfers" (RFC 8831, section 1). NAT traversal is the job of ICE, not of DTLS or UDP.
2. Peer discovery. When a viewer joins, "the discovery service sends the Client SDK a set of peers that it believes will benefit this particular viewer. Peers are selected based on network proximity, cache allocation, stream relevance, among other parameters" (Microsoft eCDN technical overview). CDNBye's engine additionally uses an IP database to "group up peers by ISP and regions" (CDNBye dashjs-p2p-engine).
3. Seeding. Nobody can share a segment that nobody has fetched. So the first viewer in a channel takes it over HTTP from the CDN and becomes the seed: "The first web peer will serve as a seed, if no one else in the same channel" (CDNBye). Later viewers take it from that seed, and from the peers that took it from them.
4. Per-request routing. The plugin intercepts each request the player makes. It forwards each request to the client SDK, "which decides, based on real-time measurements, whether to fetch the desired resource from the P2P network or from HTTP or from both concurrently" (Microsoft eCDN technical overview). Fetching from both at once is what stops a slow or missing peer from becoming a stall.
5. What never goes peer to peer. "The manifest requests, DRM license and encryption are always retrieved from the HTTP edge server in order to get the most current copy and to adhere to authorization mechanisms" (Microsoft eCDN technical overview). Only media segments cross the mesh.

Why it matters for a CDN

Egress is billed per gigabyte. A live event is the worst possible shape for that bill: tens of thousands of viewers ask for the same segment inside the same few seconds. Peer sharing attacks exactly that shape, because a peer is only worth something if it already holds the segment you are about to need. That probability rises with concurrency, not with audience size accumulated over time. Long-tail video on demand is different. Every viewer sits at a different position in a different asset. This yields almost no useful peers, so that traffic stays on the CDN.

Treat published offload figures with care, because most of them measure a different link. Microsoft states that "Microsoft eCDN forms a mesh network over the LAN, reducing the load by up to 98%" (Microsoft Teams eCDN). The Peer5 listing claims "offloading 80% to 99% of the bandwidth during large video events". It describes peers that "share content over the local office network" (Peer5 listing). Hive advertises "Reduce bandwidth by up to 99%" for the same corporate case (Hive eCDN). Those are savings on a saturated office ISP link, not on a commercial CDN bill. For public in-browser delivery, the figure in circulation is second-hand. An academic security study of peer-assisted delivery networks opens by noting that a PDN "is reported to offload up to 95% of bandwidth consumption for video streaming" (Stealthy Peers, arXiv 2212.02740). Read all of these as vendor ceilings under ideal concurrency. Then measure your own.

What CDNs do

The mesh is normally a separate overlay. A business buys it from a specialist and switches it on in front of an HTTP CDN. It is not normally a feature of the CDN's own edge. Microsoft lists its eCDN as designed to work with "HTTP-based CDNs: Akamai, Fastly, CloudFront, Cloudflare, Azure CDN, etc." alongside standard HTML5 players and DRM systems (Microsoft eCDN technical overview). This is the shape of the whole category: the CDN keeps serving HTTP and needs to know nothing about the mesh. The specialists include:

• Microsoft eCDN is built on Peer5. "Microsoft has acquired" Peer5 in August 2021, as "an electronic content-delivery network (eCDN)" (MediaPost, 10 August 2021). Microsoft eCDN "operates a WebRTC-based peer-to-peer (P2P) CDN that delivers HLS and MPEG-DASH video streams. No additional software / client plug-in or hardware is needed for the solution to work" (Microsoft eCDN technical overview). Microsoft states it "is the default for Teams events optimized for large audiences, such as town halls" and that it "is included with Teams Enterprise" (Microsoft Teams eCDN).
• CDNBye (SwarmCloud) ships player plugins for hls.js, dash.js and Shaka Player. These build a mesh "using bittorrent-like protocol". "The forming peer network can be layed over other CDNs or on top of the origin server". The engine will "Seamlessly fallback to normal server usage if a browser doesn't support WebRTC" (CDNBye dashjs-p2p-engine). It is a hosted commercial service, not an open-source engine. You register a domain in the SwarmCloud dashboard and load a prebuilt script. The GitHub repositories carry no licence.
• Hive Streaming sells a "software-based enterprise content delivery network with built-in analytics dashboards". It answers the mechanism question directly: "Viewers share video segments locally instead of each device pulling from the source" (Hive eCDN). Microsoft lists it as a partner eCDN for Teams events (Microsoft Teams eCDN).
• Kollective makes the browser the delivery node. WebRTC "becomes the mechanism through which viewer devices form a peer mesh — sharing video stream segments with neighboring devices rather than each pulling independently from a central source" (Kollective, WebRTC). Microsoft lists it as a partner eCDN that "uses intelligent peering" (Microsoft Teams eCDN).
• Peer sharing is only one eCDN technique. Microsoft's own partner list describes Ramp as letting you "mix and match any combination of eCDN technologies—multicast, caching, and peer-to-peer networking" (Microsoft Teams eCDN). On a managed corporate network, multicast or a local cache can beat a mesh outright.

Watch out for

• Peers learn each other's IP addresses. The first security study of WebRTC peer-assisted delivery covered three providers and 134 customer websites. It reported "free riding of the public PDN services, video segment pollution, exposure of video viewers' IPs to other peers, and resource squatting" (Stealthy Peers, arXiv 2212.02740). Transport encryption does not help with the address: the address is the connection.
• Encrypted at the hop is not protected at the object. The peer link is "a secure pipe that uses the SCTP protocol over DTLS encryption". This protects the transfer only. Microsoft is explicit that where segments are unencrypted, "the unauthorized user can receive the URL of a segment from a different user, find other peers that have this relevant resource, and attempt requesting this resource directly from these users (even though the media server / CDN would not allow access to this resource)". Content tokenization authorises the viewer "on the resource level before other peers can send data to that user". AES-128 or DRM closes it at the object (Microsoft eCDN security).
• It spends the viewer's uplink. Peer meshes "use the client's bandwidth to upload media to other connected peers, enabling each peer to act as an edge server" (Kollective, WebRTC). That upload leaves through the viewer's last mile. On a consumer connection, that direction is asymmetric and already scarce.
• A direct peer connection is not guaranteed. WebRTC negotiates paths with ICE. ICE works with STUN and TURN servers, "relaying data through a server when direct peer connection isn't possible" (Kollective, WebRTC). A relayed transfer is not a saving: it is somebody's egress. Where UDP is blocked, the segment simply arrives from the CDN instead.
• The vendor layer consolidates. Peer5 ceased to be an independent peer-assisted network when Microsoft bought it in 2021 and made it the Teams default (MediaPost, 10 August 2021). Keep the plain HTTP path fully working on its own. Then losing a mesh vendor costs you money, not the stream.

Best practice

• Enable it only where concurrency is assured. That means town halls, live sport, or product launches. Leave long-tail catalogue traffic on the CDN. Every offload figure in this category is conditional on many viewers wanting the same segments at the same moment (Peer5 listing).
• Keep HTTP authoritative. Serve manifests, encryption keys and DRM licences from the edge only. Microsoft's design does this, so neither freshness nor authorisation can be influenced by a peer (Microsoft eCDN technical overview).
• Protect the object before you enable peering. Turn on resource-level token authentication or segment encryption first. An unencrypted segment in a mesh is a segment the CDN no longer controls (Microsoft eCDN security).
• Race HTTP against P2P and fail fast. Concurrent fetching from both sources is the documented reason a slow peer does not become a rebuffer. So never let a peer request hold a segment past its playback deadline (Microsoft eCDN client logic).
• Rehearse at event scale. Microsoft ships silent testing precisely because meshes behave differently under load. This feature "allows admins to simulate large events on their corporate network, allowing thorough and nondisruptive testing and troubleshooting before a real event" (Microsoft Teams eCDN).
• Measure the peer hit ratio and the egress you were actually billed. Judge it the way you would judge a cache hit ratio. Realised offload is the only honest number. It is yours, not the vendor's.