©Peerplug. All rights reserved

 

Peerplug for ISP

Peerplug MESH streaming engine is beneficial even for ISP usage.

Overview:

Internet Service Providers usually consider peer-to-peer functionality non beneficial as in most cases it increases the load on their infrastructure. Peerplug’s “Peer neighborhood AI” and dynamic segmentation features allow ISPs that have OTT services to benefit from peer-to-peer in way never before possible.

This explanation is suitable for tier 2/3 ISPs purchasing transit between it's different autonomous systems and/or outside networks.

Let’s take as an example the following oversimplified setup of an OTT service at ISP:

DEMO 1.png

There are 3 autonomous systems (ASN-0, ASN-1, ASN-2):

  • ASN-0 - Is an autonomous system where the video source is located, it may or may not belong to the ISP

  • ASN-1 - Autonomous system for region 1

  • ASN-2 - Autonomous system for region 2

The ISP has two caching servers CS1 and CS2 to distribute video in corresponding ASN to prevent overloading the AS peering links.

For the sake of simplicity, we will assume each AS has a single border gateway that connects internal components to the outside world (Main router, MR).

  • ASN 0 has MR0 that is connected directly to the video source.

  • ASN-1 has MR1 and 3 internal routers R[1-3] and a local caching server CS1

  • ASN-2 has MR2 and 3 internal routers R[4-6] and a local caching server CS2

User devices [U1-U12] are connected to their corresponding local router R[1-6] accordingly.

This is minimal oversimplified topology to illustrate each of the necessary building blocks of a large OTT service, again for the sake of simplicity we will assume there is only 1 live stream (TV channel in case of IPTV).

 

Let’s see the video data flow:

DEMO 2.png

  • There is a single link for each of caching servers to deliver the video for local ASN distribution in yellow

  • There is a single link for each of the users watching the stream in green

As we can see, both CS[1-2] servers have a lot of connection as those servers should have a separate connection to each of their end-users to distribute the video.

 

It is easy to see that CS[1-2] are the bottleneck of the infrastructure.

Now let’s see an example of peer-to-peer acceleration done wrong:

DEMO 3B.png

Red lines illustrate the peer-to-peer traffic.​

CS1 and CS2 servers are now much less of a bottleneck as they require much lower bandwidth. This may benefit a non-ISP OTT service provider as that's what they pay for (CDN or self-hosted) but it is terribly counter productive for the ISP !

Instead of the traffic being local, inside the autonomous system, big portion of the traffic now crosses from one AS to another leading to a huge strain on the peering links. Those peering links are usually long physical links with limited bandwidth available. Using bandwidth of those links is the least favorable solution !

Finally, let's see how Peerplug engine will build the MESH network:

DEMO 4.png

 

Blue lines show the Peerplug's peer-to-peer connections​.

CS[1-2] servers are no long a bottleneck, MR[1-2] routers have less load, no cross autonomous links.

This accurate kind of mesh building with minimal hops is possible due to highly efficient Peerplug’s “Peer-neighborhood AI” technology and ability to supplement it by dynamic “segmentation rules” to further control the process.

Additional Peerplug segmentation rule types:

  • Separate peers by ASN (prevent cross autonomous system connections)

  • Separate peers by netmask

  • Limit connections by the amount of network-hops

  • Limit connections if they go through specific ASN

  • Limit connections by “black hole” - If a peer-to-peer connection route requires going through a specific network router(hop) that is defined as a “black hole” the peer-to-peer connection will not be initiated

  • Limit connections by “black hole pair” - if a peer-to-peer connection router requires going through a two consequent routers(hops) that are defined as “black hole pair” the peer-to-peer connection will not be initiated

Each of the limitations can be applied per AS and/or per defined group of end-users. For example, some users may be restricted to their specific AS while users in other ASes are not limited by this rule.

Black hole features are meant to prevent peer-to-peer links from overloading a specific routes/links that could not be easily identified by other means. Peerplug provides REST API to automatically update the black hole rules to compensate for dynamically changing network conditions.

For ISP OTT service providers, on premises deployment options are available.

If you are an ISP OTT service provider and still have doubts about Peerplug’s MESH streaming engine, contact us and we will be glad to address them.