When It Comes To Content Delivery Networks, What Is The “Edge”?

When it comes to content delivery networks, there are a lot of words we use in the industry that are difficult to define. Words like performance, scalability and quality are used everyday as is the term the "edge". But depending on who you ask, definitions of what the "edge" is, and the role it plays in delivering video vary greatly.

For starters, the "edge" is really not a meaningful word if you are trying to define
how a CDN is architected and where it distributes traffic from. It has become a misused term that many of the CDNs use to indicate that traffic is coming from the closest location to the user. Just because the content may be coming from the closest location to the user does not guarantee quality. And in fact, many times, the content is not even being delivered from the closest location even though the CDNs says it is. You also have the "assumption" by many in the indsutry that CDNs cache all video or replicate content at every "edge" location they have, which is simply not the case.

Customers need to ask CDN providers where their servers are physically located that are distributing the specific content the customer is concerned with. You have to ask the CDNs where are you actually streaming that video from? In most cases, you can do simple trace routes to see for yourself. As an example, there was a lot of debate the past few weeks about the BBC’s iPlayer traffic and what impact that is having on ISPs. But if you do a trace route for iPlayer traffic today, you will find that a lot of it is coming from CDN servers outside the UK. Almost none of the traffic comes from “within” an ISP network, which is where most CDNs classify the "edge" to be. There are a couple of reason for this.

When moving small objects off a CDN, the latency associated with the distance from the CDN server to the consumer’s computer dominates the speed with which that image loads. As such that server needs to be placed as geographically close to the consumer as possible. Those images are tiny so those servers are configured with minimal storage. In addition you can afford to replicate those objects on many, many servers because the total storage costs are inexpensive. But comparing that to a large object like a video, the latency becomes irrelevant due to the overall time it will take to move the whole object. There is an impact on start time, but storage now becomes a much bigger cost.

CDN providers who originally built hugely distributed systems with little storage cannot make use of many of those previously deployed servers as they cannot store large libraries of video, in some cases not even more than a handful of videos. But, you wouldn’t want to in any case as you don’t want to replicate the video’s unnecessarily. A more centralized architecture with very large storage (only replicating for actual demand) is much more efficient. The number of locations in which you place servers is then mostly economically driven. It is a trade-off between storage and bandwidth consumption and it’s a balance based on how many objects you are distributing from the library and the popularity distribution through that library. While most CDN providers all talk about how "unique" their networks are, nearly every CDN has almost the same architecture for distributing large objects, whether cached or streamed.

Another reason almost none of the traffic comes from within an ISP network is DNS resolution. The ability of a CDN to localize traffic is somewhat limited by the resolution of the ISPs DNS. Some ISPs will not enable resolution beyond the whole ISP itself. So the whole issue of placing CDN servers within ISPs that cover large geographies networks becomes pointless.

In addition, CDN load balancing plays a big role. CDN providers determine where individual objects are served from based on many factors. The sophistication of the particular CDN’s algorithms will determine how many factors are taken into account. This is a real-time dynamic system in most cases and factors like performance of connected networks and performance of the CDN (load balancing due to demand) and costs to the CDN provider will be taken into account. This is fully under the control of the CDN provider and has nothing to do with the ISP. Even if an ISP houses a CDN server there is absolutely no guarantee it will actually be used. And as mentioned above, in relation to large objects and cost, it is most unlikely to be used.

One final point is that a CDN server placed inside an ISP network needs to be “filled”. The cache fill is data from the CDN’s origin (or the CDN’s customer’s origin). In 99% of cases this fill will come from outside the ISPs network. The cache hit ratio then should become a very important factor for the ISP. But how many think about that? The cache fill data plus the cost to house and power the CDN’s server is borne by the ISP in many cases. However, large object traffic, video, is what is causing cost increases for all ISPs. But if video is not being served from the CDN servers within the ISP network is there a real benefit to having them there?

The bottom line is that like many other topics in the content delivery market, people assume they know what terms means, how things work or more importantly the impact they think it is having on themselves, ISPs or other content owners. Content delivery networks as a whole need to do a much better job explaining exactly how they deliver video. Too many are so concerned with not giving out technical details, but it’s exactly what we need from the industry so we can educate customers and start to debate in an open manner how one network can operate more effectively than another. Over ten years later, there are still too many confusing questions about the content delivery business and trying to figure out how all of this works.

While I have a good understanding of the technology, I don’t pretend to be a network engineer who builds networks for a living. I’d like to see a really good discussion take place in the comments section with feedback from the CDNs directly as well as those who work at ISPs. This is a topic many want to know more about and one that many could benefit from with additional input.

  • shaun noll

    i look forward to watching this, any sort of open dialogue with the CDNs, ISPs, and network engineers would be golden. i cant even count how many reports i’ve read on the CDN industry that totally contradict each other and/or show an obvious lack of understanding and fundamental information.
    lets hear it guys! you CDNs have your chance to make a clear and concise case as to why your network is superior!

  • In my view, a Edge is a server, cluster or PoP that is matched to one or multiple network regions.
    A Edge does not necessarily needs to be on-network with an ISP. It can also be near a ISP network, if there are good interconnects (public or private peers) between the ISP network and the Edge PoP. Housing an Edge outside a ISP network can have some benefits (like more control over the edge and faster rollout).
    Nowadays, with ultra fast global networks, the need for Edges is lower than a few years ago. The cost-performance ratio is changing. Having servers in Asia may increase 25% local performance, but costs 250% more.
    And I also see a trend where network owners are implementing CDN technologie within their network. They can act as an Edge for third party CDN’s. And do deeper edge delivery themselves.

  • Cutting few corners to simplify discussion, the closer the point the content is served from (‘feeder’)to the user, the stream is less exposed to bottlenecks.
    The more feeders there are and the closer they are to the receiving end, the better the probability for the network to overcome bottlenecks.
    P2P networks usually handles fragments that act as the small items described in the article above.

  • We agree that the term “edge” is often used loosely as a catch-all and is associated with quality. Reality is that serving from the edge does not automatically relate to quality improvements, especially with regards to streaming video delivery. As Dan said, having an edge infrastructure only works well if it greatly reduces latency and increases predictability between the server and the player. Latency and packet loss will greatly hinder a TCP/IP connection, resulting in late arrivals (meaning lost data for video) and slower download speeds. As he also said, using “edge” POPs doesn’t equate to proximity to the player, yet CDNs claim this to be true. Over the past 10 years we have licensed our software to Telcos to resolve last-mile/access network issues. This solution has been standardized in multiple market segments including IPTV (telco) and mobile streaming. It’s also in use by the defense space for mission-critical video streaming over radio networks. If network providers who own the last-mile can’t ensure quality video streams to their customers, how can a CDN that is relying on these networks do this?
    For over-the-top video streaming, we leveraged our software to build a CDN designed solely for high quality, high bit rate video streaming that removes proximity as a factor in the video delivery and experience (read no edge required). We use multiple servers from multiple data centers to send streams to a player. The player doesn’t need to wait for all the content to arrive but merely most of it, and this provides a unique self-pruning process where the closer/faster servers do most of the work and the slower/farther ones do less—no smart DNS required. This is also not P2P, where the network must rely on highly asymmetric uploads from clients who are both on-line and have the content. Even better, this provides a number of consumer benefits:
    – Much faster video start-up times, since the player doesn’t need to wait for the slow packets—and it does this without “bit-slamming” like new progressive download solutions.
    – Resilience to latency and loss ensure the maximum video throughput is achievable for the available long-term bandwidth (if the bandwidth is constrained for a long period, we can shift down to a lower bit rate video while providing a seamless video experience).
    – Robustness to highly latent packets, packet loss, server loss, data center loss, etc.
    – Better scalability and capacity planning, since servers only do a fraction of the work to serve a stream.
    You can check it out for yourself – just visit http://www.dfsplash.com or Speed TV http://www.speedtv.com/programs/wrecked and choose the WRECKED HD online button.

  • The ‘edge’ has always been a bit of a nebulous term. We know what the core is and we know what the access network is, the ‘edge’ is the boundary layer between the two. It is poorly defined and it changes over time. Every time you hear a CDN (or anyone else) talk about the edge, they are using it as a marketing term and nothing else. As Dan noted, the economics of content delivery vary widely with the type of data being delivered. But I don’t think it is realistic to expect CDNs to give out too much detail about the internals simply because things are changing too quickly. Rather, I think we will see evolution in the SLA’s offered by CDNs, using better metrics to measure their performance than currently. If you don’t know what you are trying to optimize, it doesn’t help to know where the data is coming from.

  • Actually CDN’s can decrease the quality by using edge servers. To save costs, a CDN operator may move viewers to a remote edge. And most CDN’s don’t replicate all the content to all the edges. Only the popular content. Which is more effective, but as a result, low interest assets can have a low QoS, while popular assets can have the best QoS.

  • Jon

    The folks at the BBC will thank you for this impartial and informed article Dan, when it comes to defending their recent CDN provider selection for their H.264 iPlayer streaming.

  • I’m not sure where there is so much confusion- an edge is simply any server on a CDN network that is not the origin.
    The meaningful query is not “what is an edge?”
    The meaningful query contains two parts:
    #1 “Where are the edge servers deployed?”
    #2 “What is the traffic management (load balancing) system?”
    Two identical deployments of edge servers will have vast performance differences based on the traffic management system.
    And an all download large object site may do just fine, globally with a very large multi-homed origin system but may see better performance (to end users) by using an edge deployment of some type, as well as effective load balancing.
    When comparing CDNs those are the two questions to ask…

  • Dan brings up an important point regarding importance of and definition of an Edge in context of current massively distributed CDN technologies such as Akamai. Ten years ago Akamai correctly argued that such massively distributed architecture was necessary to overcome latency/ congestion issues to provide better response time for a good web experience, and based on the merit of their massively distributed server farm created a company whose name to day is synonymous with CDN industry. It is therefore not surprising to see the definition of Edge follows what Akamai promoted it to be i.e. Edge is the closest point of content storage and distribution for cost effective and responsive distribution to a given metro location with concentrated population of users.
    For last ten years the massively distributed server scheme promoted by Akamai has worked very well for content delivery; however this scheme is facing major cost and quality/performance challenges as the web migrates from web page transfers towards high quality video streaming on demand. As Dan pointed out adopting Akamai’s massively distributed scheme to VOD is a very costly proposition indeed and such high costs can undermine or slow down the projected growth.
    EdgeStream invented, patented and perfected technology that can stream high definition video without loss or degradation over very long distances. This allows EdgeStream to stream highest quality video across globe from a handful of server sites. Because of such centralization, we need an order of magnitude smaller number of servers. Centralization also leads to much more efficient utilization of the bandwidth i.e. to support a given volume of global traffic (terabytes/month) we utilize significantly less aggregate bandwidth because centralized bandwidth is shared by non-overlapping peak loads across globe. This results in an order of magnitude lower cap-ex and op-ex as compared to massively distributed schemes.
    Because of these inherent performance and cost advantages, EdgeStream can upgrade its customers’ video streaming quality and provide global coverage while potentially lowering total cost or allow further expansion without incurring any additional costs, all without resorting to traditional massively distributed EDGE delivery architecture. In conclusion please note that all EDGES are not created equal or even necessary for high quality video distribution.