heart shattering into many pieces

Dear MPLS, We Need to Break Up

Dear MPLS,

I’ve considered writing this letter for quite some time.  Fifteen years is a long time together, especially in the technology world. Many would say that this is long overdue. We’ve had our ups and downs as many relationships do, but alas, I’ve met someone else.

When we first met in the 90’s you were so full of life and had such a bright future. I had a relatively easy and reliable way to connect my offices and data centers together, and you always did a great job of getting my packets from point A to B. Over the years as you started to mature and learn more about my needs, you offered advanced services such as COS/QOS and higher SLAs for my traffic. However, you have some really bad habits and that you haven’t been able to kick.

As the enterprise WAN became more important and we started to push more traffic, you’ve largely remained the same. Connections like the T1 are just so 90’s and I need more than 1.5Mbps for my web, voice, VDI, video, WebEx, email, file sharing and streaming traffic. My users are unhappy, and so much of it is because of you. When I told you that I couldn’t afford the high monthly fees and excessive cost per megabit, you barely budged. If that wasn’t bad enough you struggle to keep pace with my business, sometimes lagging months behind to be installed after I’ve opened a new location or not being available at all in some areas.

“MPLS, I’m leaving you… for the Internet.”

Out of respect I didn’t want to tell you who my new WAN provider was, but since you are familiar with them I thought you should know, it’s the Internet. I know what you’re going to say, the internet doesn’t offer QOS, sometimes there are high amounts of packet loss and it’s not secure. I’ve done my research though, and what you are offering in those statements is only FUD. From a cost perspective the internet is on average 1/10th the cost of you, and offers extremely high speed connections without an exponential increase in cost. To securely connect my sites together I can simply install a VPN which offers highly secure connectivity and when I need to order a line, it doesn’t take months to get. The internet is able to keep speed with my business in more ways than you can.

You might be thinking, what about those real-time applications that need QOS and a guarantee to not have packet loss? The reality is that I can get all of those things with the right software defined WAN solution. Packet loss can be mitigated through parity and QOS can be guaranteed by software. The combination of these technologies removes the need for you altogether, and companies like Silver Peak have provided this service for quite some time.

It’s been great knowing you, and I appreciate all that you have done for me over the years. I’m sure you will still find others who are willing to pay for you, but please don’t bother to call me anymore. I simply can’t afford your high cost and slow performance.

Your Former Customer

About the author
Adam Fuoss
Adam Fuoss is the Director of Technical Sales at Silver Peak. He has more than 10 years of experience working with customers and partners on server, storage, cloud, virtualization and networking solutions. Prior to Silver Peak, Adam served in System Engineering positions at Emulex and NEC. He grew up in Pittsburgh, PA and is a graduate of Waynesburg University where he earned a B.S. in Business Information Science with a minor in Business Management.
  • Have you ever tried to run a global VPN using disparate internet connections? That traceroute across 4 ISP backbones can get very ugly. Do you understand that software defined QoS policies aren’t honored going through the public internet? So internet costs 1/10th of an MPLS connection, eh?(chuckle, then sigh) If you’d like to compare DSL and cable to fiber, then sure. Look, I’m actually a supporter of WAN accelerators and IP VPNs. We have plenty of customers using both. To summarily dismiss MPLS as a viable networking technology is just plain dumb.

    • Adam Fuoss

      Hi Matthew. Thank you for your feedback on the post. You make some great points about routes taken and QOS not being honored on the public internet. The internet is by no means perfect and there are benefits to the guarantees MPLS can provide, however some newer technologies are enabling MPLS like reliability across public internet, let’s dig into those for a minute from Silver Peak’s perspective.

      The first, and possibly most prominent issue around reliable delivery of traffic involves packet loss. As you know there are no guarantees on the internet and hence you generally can’t provide QOS because once this traffic leaves your network the internet doesn’t care, every packet is the same priority. For real-time traffic such as voice and video this poses a big problem, the impact of packet loss on this traffic causes a very clear degradation in the quality and reliability of the connection to the user. In MPLS networks you can generally work around this problem through guaranteed traffic buckets that are not subject to packet loss, but what about the internet?

      Silver Peak has a technology known as Forward Error Correction (FEC). FEC provides the ability to correct for packet loss in real-time, so as you send traffic across the internet and packets are lost we can simply rebuild them on the receiving side. The FEC engine provides link conditioning that can make an internet link look like an MPLS link. You can read more about FEC and how we correct for packet loss in our whitepaper: http://www.silver-peak.com/info-center/overcoming-packet-loss-forward-error-correction-fec

      OK so now that we have dealt with the packet loss issue, what about the scenario where my internet link may be taking more hops which can increase latency and out-of-order packets? Silver Peak has two other technologies that help to mitigate these problems. For packets that may arrive out-of-order from taking multiple disparate routes, Silver Peak has the ability to do real-time packet reordering which corrects for the problems introduced with routing inefficiencies. We also have another feature known as Dynamic Path Control (DPC), when combined with multiple links, can route traffic down links that have lower latency or lower packet loss, we’re actually seeing a lot of customers order two internet links when they replace MPLS, this provide redundancy and also an alternate path in case one runs into trouble. These technologies when combined allow us to drive around the problem and when we can’t we simply fix the problems introduced. You can read more about Dynamic Path Control Here: http://www.silver-peak.com/info-center/dynamic-path-control-real-time-traffic-updates-hybrid-wan

      As for QOS. Silver Peak has a full QOS engine that can prioritize packets. When you combine all of our technologies together, correction for packet loss and out-of-order packets, dynamic routing based on link quality, QOS and all of the other technologies we do to deduplicate and accelerate you start to see a solution that provides the pieces needed to get rid of MPLS.

      • claudio scola

        Much of the cost is with the access network and supporting high availability. The 10:1 cost comparison can be valid for the Internet backbone v mpls backbone. To maintain that ratio to the the end user price you need to provide consumer grade access on the internet. For and average of speed of 20Mbps the absolute price difference for the core element is not that significant. So your claim does rely on consumer grade access to hold true. For anyone who has had a broadband fault does understand that you don’t choose it based on what it can do but what happens when it stops doing what you expect. The cost of unavailability could be a hundred times the cost of the wan cost.

        This reminds me when VPLS providers started marketing themselves as the cheaper alternative to MPLS. That was really stupid as the targeting was completely off. Most providers were using the same damn routers in their networks anyway and therefore had the same cost base. When WAN Op vendors stopped marketing their business case being based on bandwidth savings and more about latency mitigation enabling DC consolidation that made a lot more sense. Ipanema did quite a good job with their messaging on hybrid wan unification.

        But anyway, lets continue to confuse the customers.

      • dlowry

        Does FEC work with voice traffic as well as Data traffic?
        I know that Data traffic uses TCP/IP which is less sensitive to things like jitter and latency. (You can always retransmit a TCP Packet).

        Can UDP Voice packets be “Rebuilt” via FEC within a timeframe that wouldn’t cause a voice quality problem?

        • Adam Fuoss

          Yes the Forward Error Correction engine works for both TCP (Data) and UDP (Voice, Video, Real-Time) based traffic.

          TCP does have built in mechanisms to retransmit packets when lost, however when a packet is lost TCP will reduce it’s window size by half to adjust for the loss in the network, this will in turn reduce your effective throughput. As loss increases TCP will continue to reduce it’s window and throughput will continue to drop.

          UDP traffic has symptoms that are much more apparent to a user when packets are lost in transmit. For real-time protocols such as voice or video, packets lost will result in degraded performance which can show up as pops, clicks, dropped calls, degraded video and a variety of other symptoms. These problems are very apparent to an end user on a call or video conference.

          The FEC engine has the ability to proactively inject parity so that as packets are lost in transmit, Silver Peak will simply rebuild the lost packet on the arriving Silver Peak appliance. Because the packet is rebuilt at the receiving Silver Peak the receiver never experiences any of the effects of packet loss. The FEC engine is able to recognize and adjust how long packets can be held to not introduce problems.

          • dlowry

            Very interesting. Thanks for the explanation. One more question. Do you know of many companies that are running both Voice and Data over the Public Internet using SilverPeaks?

          • Adam Fuoss

            I don’t have the exact number, but it’s definitely a lot. We have many customers who have locations with no carrier grade connectivity available who need to provide voice and video to their users. This is a common use case for many of our customers. Others are moving from their carrier grade lines when they reach points where they need more bandwidth, know the value we have been providing them across their MPLS and are ready to make the change.

            For current MPLS users who might want to tread more carefully rather than just jump straight to the internet we’ve seen a lot of customers take advantage of our ability to route traffic down multiple links based on the traffic type. Some users will choose to still route their most critical traffic, such as voice, down MPLS and then allow Silver Peak to route all other traffic down a less expensive internet line. This approach would allow you to maintain a lower bandwidth, less expensive MPLS line which has a higher SLA, while sending all other traffic down the internet VPN. If either line was to fail Silver Peak could also provide failover of traffic down an alternate route.

      • sonsofthepatriots

        So you are recommending piecemailing three addtional services together on your equipment which also has a cost? What about WAN aggregation services – telari boxes or the such? Always so many solutions to consider, do you see this being utilized in more tier 3 and 4 markets where infrastructure is unavailable? Where exactly are your many examples of clients operating this solution out of? I find that MPLS bandwidths can easily be upgraded out of the 90’s T1 speed. In fact there are plenty of nationwide carriers who can provide symmetrical MPLS ports alongside the internet circuit without being so costly. MPLS I agree is dated but with SDN not quite yet here I don’t see MPLS making a complete exit in the near term.

        • Adam Fuoss

          What we’re recommending is that you can take any combination of network transport, be it MPLS, Broadband Internet, LTE, etc. and build an overlay that allows you to effectively connect any branch office over any transport.

          Aggregation of WAN links is handled through Silver Peak’s Dynamic Path Control feature which allows businesses to more effectively leverage the available links they have. For instance, in a hybrid WAN scenario where one link is MPLS and the other is broadband Internet a policy could be configured to route critical voice and video traffic across the MPLS, while all other traffic uses the Internet link. In other scenarios such as a dual broadband internet design you could configure a load balance configuration to distribute and balance traffic across all available links. These policies can be simply configured for each customer’s network. For more information on this, you should check out our website here: http://www.silver-peak.com/products/unity-edge-connect/dynamic-path-control

          In terms of where customers should be looking to leverage this type of connectivity the answer is simple, anywhere you want to lower branch connectivity cost while increasing performance. You’re right that certain markets have limited connectivity options for carrier provided MPLS networks, however an internet connection is generally available anywhere, regardless of the underlying transport (Wired, LTE, Satellite, Microwave, etc). While T1 connections can generally be upgraded to faster connections, it does come at a big cost. A recent study by Telegeography found that the average cost of a 10 Mbps MPLS circuit in San Francisco was $2,100 where the average cost of a 10 Mbps business class Broadband Internet connection was just $110.

          The idea of businesses moving to all Internet is no doubt bleeding edge for some. The features we’re introducing in our EdgeConnect platform allow businesses to choose if they want to start slow with a Hybrid WAN (MPLS + Broadband Internet) or if they want to go all the way to an Internet based WAN. Our model is flexible for any customer to build their WAN the way they want.

          If you’re interested in a really detailed look at this check out our CEO’s presentation at Tech Field Day here: http://techfieldday.com/appearance/silver-peak-presents-at-tech-field-day-extra-at-onug-spring-2015/?utm_content=buffer22721&utm_medium=social&utm_source=plus.google.com&utm_campaign=buffer

  • Dave

    Not a fan of Comcast, but they have a metro e product that emulates an MPLS network but with fiber connections instead of T1 on a private network. Ours is 20mb/s at corporate, 5mb at satellites. I was a little apprehensive at first because of previous QoS issues, but we haven’t had any so far in the past year.

  • While tunneling over the internet using reliability protocols such as FEC will mitigate the loss issue on the internet and prioritize based on QOS, it doesn’t address jitter or bandwidth. You’ll never be able to move real-time traffic to internet reliably and there is no bandwidth guarantee from any ISP. The internet is all MPLS based as well, it’s just that your competing for bandwith. Loss is occurring indiscriminately. Traffic is rerouted by the carriers on demand. Build VPNs over it and use reliability and acceleration protocols, and you have a relatively reliable network that will have high jitter and variable bandwidth. If that meets your service requirements, then it can be a cost saving option.

    The merit of MPLS is somewhat exaggerated as well. You get a virtual private cloud, but the carriers still have congestion on their backbone. Unless you have a service that provides QOS and you’re marking correctly, there is going to be loss and high jitter. Furthermore, there is no bandwidth guarantee over the backbone, just the local loop.

  • Brian M

    The cost of MPLS is not that much greater than a dedicated circuit with an SLA. Many industries cannot stand to experience downtime and the drastic cost increase as you go up in bandwidth is pretty much proportionate to any dedicated access circuit. You really can’t compare broadband with VPNs to a dedicated circuit with MPLS and SLAs. The drastic cost difference comes down to one being a shared, best effort circuit and the other having dedicated bandwidth on your local loop. I get your point, there are more cost effective ways to use VPN tunneling over DIA circuits but to compare VPN over Broadband to MPLS is really off putting.