CDN Compliancy Tips for Media Players
[Editor's note: Streaming Media accepts vendor-written articles when they are of informational value to our readers and do not promote a single solution or product. Image courtesy of Shutterstock]
This article, which originally appeared on the Jet-Stream website, helps developers of smart TVs, smart phones, tablets, set-top boxes and software video clients to better understand the dynamics of a content delivery network so they can improve the way their client integrates with whatever CDN they work with.
Tip 1: Implement the full HTTP 1.1 Specification: HTTP redirect
HTTP adaptive bitrate streaming is great technology. But for many vendors, it is quite new technology. If you implement HTTP adaptive bitrate streaming—whether it is Apple HLS, Adobe HDS, Microsoft Smooth Streaming, or MPEG DASH—make sure you fully support HTTP redirect. Come on, it's not new, it is from 1999!
Why do clients need to implement HTTP redirect? Many portals and CDNs use HTTP redirect, for instance for active geo load balancing or in CDN federation environments. If you claim to support HTTP streaming, you claim to support the formal HTTP specs, which includes these redirect functions. Users, CDNs, and portals always must be able to assume that your client complies to the full spec. If you don't, your users will end up with broken video streaming after paying for that premium video.
We were quite surprised when we learned that Adobe implemented their own HTTP Dynamic Streaming technology in Adobe Flash but forgot to implement HTTP redirect in the very same Adobe Flash player. Whoops.
Tip 2: Respect HTTP Redirect Status
To be more specific, make sure you respect the HTTP redirect status as being provided by portals and CDNs. We have seen clients assume that any 30x response always is a permanent move. However, for instance, 307 means temporarily redirect: so go back to the original URL. Stick to the rules! Never assume that any 30x response is a specific redirect instruction. If you wrongly implement redirect, end users will be affected.
Tip 3: Retry After HTTP 503 Status Response
In rare occasions, a portal, a CDN request router, a federated CDN or a CDN delivery node may be unable to process a client's request and responds with 503 Service Unavailable. These CDNs can add a "retry-after" statement, allowing the client to wait and retry the request.
However we have seen some clients fully drop the request after a 503 response, ignoring the retry-after statement. Never assume that a 50x response immediately means complete unavailability. Please check the header for retry information and respect the retry-after time.
Tip 4: Respect DNS TTL
Many generic CDNs use DNS tricks. Their master DNS tricks third-party DNS servers into believing that for a certain domain, there can be specific IP addresses. That is how they let users connect to local edge servers. If for any reason the CDN needs to send users to an alternative server, they update their records so your DNS provider gets the latest update for the right IP address. That is why CDNs typically use a low TTL. Although DNS is a poor man's solution that never really can guarantee any controlled request routing, it is still fairly common with website accelerating internet CDNs.
So respect the DNS TTL statements; don't override this TTL. If you cache DNS records for a longer period than stated in the TTL, your viewers risk being sent to an outdated, out of order, or overloaded delivery node—meaning no video or a lousy stream. CDNs already have the risk that DNS servers override their TTLs. Don't let this happen for media clients (or their OSes). We have seen quite some set-top boxes that override DNS TTL or have poor DNS client implementations. Caching DNS records sounds like a great idea, but there is a reason why CDNs use a low TTL!
To add to the problem: many applications (not resolver libraries but video playback software) request an IP address once for a hostname. And as long as this application is running, the app will use the same IP address. We see this behavior quite a lot. So even when DNS servers and the local resolver libary on the client all respect the DNS TTL as they should, the app will still use an outdated IP address. Resulting in broken or underperforming streams. So what the application should do is re-request the right IP address for every new session.
Tip 5: Random Use of Multiple IP Addresses in DNS Record
CDNs can return a list of IP addresses for a single DNS record. DNS servers typically put these IP addresses in a random order, so end users are load balanced quite nicely over the delivery nodes. However you cannot assume this. And you can't guarantee or control or measure this from a CDN's perspective: third-party DNS servers can have their issues.
We have seen some examples where the ISP's DNS servers always respond with the same order of IP addresses. If media clients don't randomly pick an IP address, they will all connect to the first request router or to the first delivery node in the list, resulting in some servers being overloaded while others are idle. This happened in a large OTT CDN where the set-top box from a respected vendor had a poor DNS implementation. It resulted in sub-optimal performance for all clients, even ones that were not affected. Whoops.
Even though this is a limitation of how DNS works (DNS was never intended for CDN usage, so there are no clear instructions to clients about how to behave in these conditions), it is advised to vendors to make sure they do not assume that the list of IP addresses is random, but select IP addresses randomly themselves.
Tip 6: Implement the Full Protocol Spec
It is a problem of embedded technology vendors in general: They do a poor implementation of a protocol. We see it all the time in delivery appliances, but we also see it in media clients such as Smart TVs.
One example is where Samsung released a new Smart TV series not so long ago, claiming to fully support Windows Media Streaming. However they only tested with a Windows 2003 server in their lab. The TV could only connect via the MMS protocol on port 1755, which was declared by Microsoft as legacy in 2003 and isn't even supported in Windows Media Services 2008 anymore. The result was that quite a few premium OTT providers had invested in Samsung TV apps but could not launch their service. And because it was all hardcoded there was no way to force the client to connect to the right ports with the right protocols. Whoops.
Related Articles
The company plans to save customers money while improving performance by routing traffic away from underperforming CDNs.
06 Feb 2015