Opera’s acquisition of Skyfire earlier in the year added an important component to our leadership in data compression, allowing us to also deliver advanced, cutting-edge cloud-based mobile video optimization. Skyfire’s Rocket Optimizer mobile video optimization solution is built to easily slot into different types of network architecture, whether an operator is building a new virtualized network from the ground up, or – more likely – looking to add multimedia and video optimization to an existing framework.
Opera Software happens to be a strong enthusiast for the open, scalable and exceptionally flexible ICAP standard, which works to discard the legacy “inline appliance”/single-vendor model in favor of a simple HTTP instruction set that allows operators to work with multiple best-of-breed vendors, as well as enable their networks to embrace the virtualized, software-defined tomorrow.
We caught up with Skyfire’s VP of Engineering and Operations John Metzger in order to learn more about what ICAP is, how it works, and why it’s a natural fit for virtualized, cloud-based solutions like Rocket Optimizer.
What are the advantages to working with an ICAP architecture?
John Metzger: One of the first things we should do is to define what ICAP actually is, and what it was originally intended for. It stands for “Internet Content Adaptation Protocol”, and it’s aimed at a simple content-based vectoring method for HTTP messages. Why that it makes it so suitable for what Opera and Skyfire do is that the video that we optimize is, ultimately, HTTP messages. It effectively defines a lightweight protocol for remote procedure call for HTTP.
That’s exactly what we do – we get in the middle of the flow between the client and the origin, and we do something by adapting the protocol; video optimizing the protocol – which is content adaptation, as the name implies. It’s a very natural fit for the solution we have.
Who is doing it this way so far?
Besides ourselves, there’s a standard proxy called Squid that’s implemented under Linux. They have used ICAP for vectoring and modifying HTTP. In the early incarnations of our video optimization solution and in our testing, we actually used Squid. We didn’t have to change anything out of the box – it just worked, with ICAP automatically handing things off to us. It was the impetus for Skyfire implementing our Controller as a standard ICAP server. It was a standard ICAP client in the Squid proxy to test against.
There are now a couple of other vendors in our space that have also implemented ICAP as they have seen that it provides a mechanism to pass HTTP request/response information to other components in the overall system.
The position of Opera/Skyfire’s Controller is really key in determining whether it’s an ICAP or a Steering-based architecture, is that correct?
We look at the Controller as something like a “sidecar” using the ICAP architecture. In the HTTP flow, remember, we’re not trying to be a full proxy and get inline with the content. We want to instead be surgical in our approach. Only HTTP messages that match the pre-filter from a partner’s a steering device get handed off to Skyfire when we might want to take a deeper dive, to see if it’s something we should do something with to guarantee a strong user experience. It works great, because the standard flow of most stuff goes back and forth and through the steering device, and only when the steering device detects something that would be interesting to us, is it actually handed to Skyfire for optimization.
Ultimately, why would Skyfire want to see the industry coalescing around an ICAP-based architecture?
The main reason that we see it being beneficial to everyone is because ICAP is a standard; if they want to talk to something other than a video optimization solution, maybe a parental control content filtering method, or some other thing that fits in the same place on the network, they write one method to talk to all these other various elements. We call it “ICAP chaining”, and one of our partners has already implemented ICAP chaining in their steering device. They can say, “OK, first check to see if parental controls are on or off for this content”. If it’s allowed, then they send it to the video optimization piece, or send it to the billing piece. You can think about of many means for ICAP to hand it off to lots of services.
It sounds like it’s a simple set of protocols that you can write to very easily, even if what you’re writing to are very different applications.
Exactly. They all need the same information. What ICAP is providing is a view of the HTTP request and response components of the HTTP message that went between the client and the server, which has all the headers and all the information you need to understand what this user transacton might be: what the content type is, what kind of an HTTP exchange it is, and each of these pieces that are making decisions – parental controls, video optimization and so on. That’s all the information that it needs to have.
But the way that mobile networks have evolved, this sort of elegance has not come naturally, has it, since it’s effectively been hardware bolted onto hardware? Is this a way in the post-4G world to essentially start over?
It is. It’s in contrast to the old way in which everything was done as a WAP gateway. It came in through the GGSN from the client into the carrier network, and went into a WAP gateway. Everything got handled in that gateway; they were all sort of integrated services within that gateway. What we’re trying to do here is separate pieces out, and not have one element in the network that, from a scalability standpoint, starts to create problems. Obviously it’s a chokepoint: everything’s in one box. As you keep adding on capabilities and functionality like we’re talking about here, that thing has to grow and grow and grow.
By contrast, if you take an ICAP server approach, you can move a piece into the cloud, then move a piece somewhere else, etc. They don’t have to all be physically co-resident in that one box.
It sounds very synonymous with the Network Functions Virtualization world operators are moving toward.
Correct. ICAP can offload these services to other elements in the network, and is therefore much more scalable than an inline appliance/WAP gateway model. When a number of vendors have implemented using this standard, operators can bring in best-of-breed solutions from various vendors to handle those various functional components, rather than buying it all from one vendor.
The other nice part about ICAP is that it looks very much like HTTP in and of itself. It makes it very easy to pass extra headers and things like that, so people who are familiar with HTTP already have a natural familiarity with ICAP.
Other standards that are out there seem to be very vendor-led, and it seems that one of ICAP’s strengths is that it’s not tied to a vendor and is quite open in nature.
Yes. There are lots of ways to implement things, but if Vendor A implements it one way and Vendor B implements it another, now when you integrate those products into a single network, it’s just a nightmare. ICAP is a way for operators to say to Vendors A, B and C, if you implement your product in this way, using this open standard, we can easily integrate your product.