What you need to know about Riverbed’s SD-WAN

At the recent Tech Field Day event (NFD10), Riverbed announced it’s entry into the SD-WAN market with it’s new solution currently dubbed Project Tiger. This threw me off guard, for I typically think of Riverbed as an APM or WanOp solution sitting between my Data Centers and large branch sites, optimizing particular traffic. I never conceived the possibility that Riverbed would enter a market dominated by edge routers. Oh, but one should not be so foolish. Riverbed certainly isn’t. With bold statements like, “The future of the WAN is NOT … a router,” it seems that Riverbed is prepared for disruption.


The big question for me is – what does Riverbed bring to the table and why would anyone consider them for SD-WAN? It’s quite obvious when you consider where their bread and butter is – optimization. Riverbed accomplishes this through a multitude of technologies, and have spent years leading in this industry.

A few specific components to the SD-WAN machine were discussed during the NFD10 event that truly make the case for Riverbed to enter the market: SSL proxy certificates, video optimization, and TCP proxy for cloud SaaS applications.

SSL Proxy Certificates

Optimization was easy back in the day with classic protocol stacks, but modern applications predominately use a new transport comprised of HTTP over SSL over TCP. The problem child, of course, is SSL. Almost all applications are encrypted with SSL, requiring decryption in order to peer into the packets and optimize the traffic. This isn’t so tough in your data centers, for you can load private keys securely on your caged Riverbed Steelhead appliances with peace of mind.

The problem of SSL decryption presents itself when we need to optimize traffic from the branch locations. Typically this is not achievable unless we expose the private keys to the branch, significantly increasing risk for theft or malicious activities. Enter SSL Proxy Certificates.

riverbed4Remember, traditionally the place where you install the keys is the place where you intercept the connection to be optimized. If we need to intercept at the branch, we need keys. Well, Riverbed has developed a way to proxy the SSL decryptions by securely transporting only the session key which is valid only for that session. No private server keys present at the branch location. How is this done?

To form an SSL connection you need an exchange of keys between the client and the server. Asymmetrical keys are exchange in this negotiation phase in order to establish the connection. Once negotiated and established, data can be sent. Data is encrypted, transferred, and decrypted using the negotiated symmetric key. This temporary session key between the client and the server is what Riverbed is loading at the branch site to decrypt, optimize and proxy the connection.

This means that your data center appliances can retain the private server keys without exposing them to the branch site by only proxying the data session keys for the particular client session. Brilliant!

Video Optimization

Modern video is delivered via adaptive streaming protocols like Apple’s HLS or Microsoft’s Smooth Streaming running exclusively over HTTP. Optimizing live streamed video can prove challenging without some sort of multicast-enabled media and multicast infrastructure. The real issue presents itself when you have multiple people at a branch office streaming the same video, copying the same stream multiple times. What Riverbed has devised is a method called Stream Splitting that will identify live streamed video, and split the stream to the individual users, leaving only a single stream between the branch office and destination.


What about on-demand video? During the NFD10 presentation Shashidar Merugu, Technical Director at Riverbed, shared an interesting use case involving viral videos.  I’ll exaggerate it a bit here.  Someone sends out a video of Jimmy Fallon‘s heartbreaking bossanova rendition of What does the fox say?, featuring Fetty Wap, remixed harlem shake style, and each view generates a penny for charity. (Someone please make this happen!).  All of sudden you have a bunch of people at your branch hit YouTube, crippling the weak branch circuit.

Not so much an issue with Riverbed. Once the first person watches this video, a copy of the video is cached locally on the Steelhead. When the next person plays the video, the Steelhead will play it back from its local cache rather than starving the circuit of precious bandwidth. This can lead to significant reduction in unnecessary bandwidth consumption.

John Herbert, Tech Field Day delegate, made an interesting point about video quality. What if one person views the video at 240potato, and the next client requests 1080p? Sashidar laid this concern to bed by clarifying that Steelhead takes into account many parameters retrievable from the end-client browsers and will only playback cached video of the appropriate type and quality. Nice.

TCP Proxy

With an ever-growing integration of SaaS applications into enterprise environments, serious implications are to be had regarding latency and performance. You may have clients in a West Coast branch location, traversing some commodity internet connection or small WAN circuit, just to be routed out to a SaaS application from the East Coast data center. This is inefficient, especially when the SaaS has a global presence and likely can deliver services in a fraction of the time from the same West Coast pop that your branch is serviced from.

Riverbed solves this via a TCP proxy feature which will intercept traffic before sending it over the WAN, enabling the branch Steelhead appliance to preemptively make intelligent path decisions and optimizations. Riverbed can scale quite a bit with this since it’s at the TCP layer, opening up the game for tons of application optimizations.


“What does Video, a Web Proxy & Hybrid WAN Path Selection have in common?”

Riverbed teased the Tech Field Day crowd with the question above.  Take all of the traffic components of a branch location, optimize them to reduce WAN costs, design the tools for scale, and automate them to simplify management. Now the picture comes into focus. Now you know why Riverbed has the potential for a solid SD-WAN solution.

While many vendors are bolting on tons of features to a router, Riverbed is bolting on a router to their tons of features. I’m excited to see what they come up with, as this tasty containerized preview has my stomach growling:



Architecting for Application Performance with Riverbed

Riverbed Steelhead Universal SaaS

Riverbed Hybrid WAN Path Selection

Riverbed Platform Future Discussion

David Varnum


You may also like...

1 Response

  1. October 1, 2015

    […] What you need to know about Riverbed’s SD-WAN […]

Leave a Reply

%d bloggers like this: