Internet Bandwidth Congestion and Optimization

Internet Bandwidth Congestion and Optimization A Landscape Perspective A CIRRUSWORKS WHITE PAPER

INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION Contents Introduction...2 The Rise of Traffic Shaping (1.0)...2 Deep Packet Inspection (Traffic Shaping 2.0)...2 WAN Optimization (Managing End-to-End IP Flows)...3 Application Bandwidth Management (Application Acceleration)...4 Dynamic Bandwidth Control...4 The CirrusWorks Governor Platform...5 Why Operate on Layer 2?...5 CirrusWorks Governor in Collaboration...6 Landscape of Equipment Options...6 Competitive Product Review...7 About CirrusWorks...7 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 1

Introduction INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION The problem of bandwidth congestion has existed as long as there have been networks. The basic ROI premise of any telecommunications network is that the core network facilities are oversubscribed by the edge users of the network. In the days of private and for-profit backbone networks (SNA, X.25, FR, ATM, MPLS, etc.), various costs of usage were applied in terms like connection count, connection size, data volume, and time-of-day usage. These parameters controlled and constrained the usage of the network (via IT cost controls and management). When IP networks were just becoming popular, these same underlying network costs and application controls were already in place. So private IP networking was just another transport protocol. The Rise of Traffic Shaping (1.0) The advent of the public Internet and its bulk usage and billing models removed most volumetric parameters of usage and forced IT managers to manage increasing volumes of traffic beyond that which were necessary to the corporate agenda and/or exceeded dramatically the bandwidth available to the user facilities. The dedicated accounting terminals and word processing stations of the past had given way to general purpose end-station computers capable of running multiple applications that were now only discernible at the network layer by source, destination and packet content. What started as diagnostic tools to determine what was in an IP flow (logical IP session), quickly mushroomed into control mechanisms embedded by IT managers into data centers and distributed LANs to provide basic rate control during periods of link congestion; hence, traffic shaping was born. The idea behind the traffic shaper is simple; you know the devices on your LAN, how much data they are moving and the size of the WAN link. Some simple math reveals that if you rate-limit the connections of users to some high-water mark, you will avoid some of the data contention situations. At first, even the most basic packet shapers were expensive standalone boxes running inline to the WAN link. Then the basic rate limiting feature became standard on Cisco or equivalent routers at all price levels. Algorithms were advanced to provide several mechanisms of interleave (ways to make priority decisions). This is how the rules and policy-based logic we see pervasive in the industry was born. Basic rate cap traffic shaping is still effective for certain types of activities. It exists today on generic LAN switches, routers, firewalls and other specialized equipment. It is also available as a basic tool on CirrusWorks equipment. If all you need to implement is traffic shaping 1.0, you probably already have all the tools in your IT shop today. But your problem is likely more complex than control via rate capping. Deep Packet Inspection (Traffic Shaping 2.0) Obviously, static transport rules and strict rate capping do not directly address the problem of network WAN congestion. They are simply a means to mask and try to ride-out the underlying instantaneous congestion that happens on every network. The root problem lies in the behaviors and activities of network users. So Traffic shaping had to go a level deeper. This is called deep packet inspection (DPI). The idea behind deep packet inspection is also not complex: if you know the endpoints of each communication session, and you understand something about the protocol being used in each session, you have a pretty good chance at making a decision on the priority of any session versus other sessions. This is a good idea and it works as long as you have a complete view of all the traffic passing over the network and you know ALL the endpoints of every session. With that complete view, you can establish traffic shaping 2.0 rules and policies that protect your QoS for your business-critical applications. 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 2

INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION Users of DPI traffic shapers rely on self-described rules and policies designed around known data flows and protocols. This method works to divide traffic flows over the Internet or WAN links between corporate and non-corporate use. But it fails in most scenarios where the preponderance of the traffic is carried back over a VPN, is encrypted end-to-end, or where the other end of the communication is not in your control (web or cloud hosted applications). DPI satisfies traffic shaping requirements for discrete (known), controlled corporate network environments. But it falls woefully short in today s mixed usage, hosted and multi-destination networking scenarios. So DPI works if your flows are understood, organized and never change. But DPI fails over time in the more generic or dynamic environment of most corporate and remote office LANs. Deep packet inspection with policy enforcement can control some web traffic flows such as peer-to-peer (P2P) in certain situations. But these are a moving target. For as soon as the content and application management device manufacturers release new sniffing rules, the abuser communities modify their connections and protocols so that such traffic is again misqualified by those rules and policies. Even the mainstream of web services is trending to make DPI more difficult and eventually obsolete. Major industry players are adopting Google s HTML5 and WebRTC. This major jump forward in end-to-end device communications will encrypt ALL data for every session between the discrete endpoints of the communication, making it virtually impossible to sort voice, video, and transactions in real-time. Lastly, oversubscription and congestion will still occur, even with transport rates being capped and non-essential data flows having been down-prioritized by DPI and policies. And once you are in a congestion state, no amount of pure packet or traffic shaping or policy management via DPI is going to abate or optimize the situation. WAN Optimization (Managing End-to-End IP Flows) Now armed with traffic and packet shaping, but not getting the intended results, IT managers asked the industry to build more specialized equipment to accelerate certain IP flows. The notion of WAN optimization emerged as a way to accelerate certain TCP protocol exchanges between two know endpoints. The fact that TCP is not highly optimized for point-to-point communications is well known. So the industry responded with expensive devices that modify the actual protocol and payload exchanges between two points over a WAN to drop superfluous chatter; hence we have the acceleration concept. We really haven t made anything faster, we are simply sending fewer control and acknowledgement datagrams between specialized equipment sitting on both sides of a WAN. So it can be stated that WAN Optimization and Application Acceleration are really a specialized point-to-point modem or private network transmission box architecture. For some applications and companies, this solves the WAN constriction, oversubscription and congestion problem. A remote accounting office of 200 people all driving transactions to a corporate data center can benefit from this technology. This works especially well for bandwidth which is dedicated to this purpose. So if you are going to use WAN optimization, you should not subject the gross traffic to other packet or traffic shapers, lest you get a result for which you were not intending. Again, we have solved a very specific problem with an expensive and dedicated hardware solution. But we ignore the overall problem of managing generalized traffic interleaved for many applications and many destinations. 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 3

INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION Application Bandwidth Management (Application Acceleration) As you might expect, WAN optimization doesn t work well for organizations moving to the cloud or where the preponderance of traffic is not following a dedicated path for dedicated applications. The best example would be the emergence of BYOD (Bring Your Own Device) and the allowance of employees and guests to use the Internet and LAN for non-work related activities on a wide field of user and office equipment. BYOD exacerbates the contention and congestion problem since neither these devices, nor their users are playing by the rules and policies established using traditional packet shaping or WAN optimization. So the industry responded by introducing the concept of Application Bandwidth Management (sometimes called Application Acceleration.) This takes deep packet inspection up the OSI (IP protocol) stack; in some cases all the way up to OSI L7 (the application specific data payload layer). The idea is to accurately classify applications based upon detailed information within the IP data flows and reprioritize (meaning down-prioritize) traffic that does not meet IT criteria to a lower speed. This is a really good concept. However, like policies for deep packet inspection and WAN optimization, it is grounded in a singular set of complex rules for a static family of complex but discernible traffic flows that are not encrypted. So it works really well for applications requiring a transport agent (software client) to be running on the user platform, when it is running in a private and controllable network environment. But as commercial applications move to the web services model, particularly when hosted by a third party, the ability to discern the traffic flows correctly diminishes rapidly. If the application runs over a browser, it is unlikely to remain discernible for very long. Therefore, the deployment of very expensive L7 packet engines do not have a long-term ROI since their ability to detect and down-prioritize known traffic flows will decline over time. Dynamic Bandwidth Control CirrusWorks has taken a radically different approach to the bandwidth congestion problem. Rather than try and discern deep secrets from the user payload data as it is moving past, CirrusWorks arbitrates congestion as it occurs by making the best decisions possible based purely upon the available bandwidth of the WAN circuit and the activities and instantaneous data demands of the users (devices). CirrusWorks provides dynamic traffic shaping without the technical difficulties associated with establishing, maintaining and tuning programmatic rule sets. This patent pending concept by CirrusWorks maintains asynchronous (upstream and downstream) statistics on user behavior without need to look at the user data payload at any level in the OSI stack. By simply understanding the periodicity of transmission/reception, gross packets and packet volumes over a historical period at L2 (the Data Link Layer), we know a lot about what each user is doing, how they vary from the average user and if they are impacting the QoS of others. CirrusWorks has replaced inefficient and ineffective packet disassembly/sleuthing with statistical and mathematical methods that effectively define a user s transmission profile dynamically and instantly. We dynamically establish priorities among the users, being able to momentarily demote users who have a recent history of using large amounts of bandwidth over the sampling period. This in turn will promote traffic which is burst, transient or transaction in nature. We haven t created more bandwidth. But at every instant, we are ensuring a best-fit use of the bandwidth that we have available. No packet or application rules are required to make these best-fit decisions. 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 4

The CirrusWorks Governor Platform INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION The CirrusWorks Governor platform is a Layer-2 QoS bridge that doesn t rely on deep packet inspection or rule sets to deal with congestion. CirrusWorks has replaced traditional L3-L7 packet disassembly and recognition with a cost effective L2 realtime flow analysis engine that makes decisions without analyzing the user data payload. Using behavioral analytics on the L2 traffic streams and monitoring historical device usage, CirrusWorks makes instantaneous MAC layer decisions based upon actual offered traffic and the aggregate dynamic data demand based upon their recent past activity. This unique software ensures that burst traffic is cleared in an expedited fashion, while less time-dependent traffic is down-prioritized during periods of congestion. When congestion is relieved, all traffic is returned to normal (ad-hoc demand) flow. CirrusWorks extremely fast congestion engagement algorithms will normally begin to abate the congestion and control usage in less than 1 second. This granularity is far below the L3 timeout window of most IP based applications. Thus, transactional data flows that must occur in near real time continue to run unabated and unaffected during the congestion period. Most users (including those engaged in bulk data movement such as video) never see an impact from CirrusWorks algorithmic approach. The impingement (delay) methodology of CirrusWorks makes very fast, but minute adjustments in flow delay for MAC addresses that are currently using too much bandwidth in either direction (asynchronous decision processes). This approach applies only the amount of impingement necessary to reach optimization at each instant. So there is never a negative QoS big brother effect as is seen in the other data flow management technologies. Why Operate on Layer 2? In the OSI model (the various IP stacks in particular) only Layer 2 (Data Link layer = L2) represents the real-time aggregate data demand of each device/user. The upper levels of the protocol stack (L3 and above) were originally written to be flexible when running over unreliable or congested shared network infrastructure. So L3 and above try to be elastic and rely on complex end-to-end retransmission capabilities. Timeouts and retransmissions pollute the decisions made by traffic arbitration devices and often render the arbitration useless as the endpoints will attempt to recover from impingement at these layers. The management of L2 (WAN) predates the IP protocols and the Internet. This concept was entrenched within the switching fabric for Frame Relay, X.25, and SNA. L2 management has been the backbone of managing flows over oversubscribed WAN links and still multi-threading user traffic for large numbers of devices. And while the CirrusWorks Governor is not actually managing L2 within the WAN, it is making data delay decisions at the edge (within the LAN) based upon what we are seeing and understanding at that data frame level. Even in today s modern multi-segment IP networks, OSI L2 represents a proxy for a device as if it were in a point-to-point type of network (viewing device traffic as if it were spanning a single physical segment.) This is a very different view than looking at every L3+ data transmission independently. And it has very different results on how successful an impingement or delay will be and how that management will impact the data flows of other devices. For the purposes of this discussion, L2 traffic management may be considered absolute, where the L3+ traffic management is subject to impacts from the end points and even the applications themselves. Small adjustments to L2 (per device) yield absolute and instantaneous results that cannot be overridden by complex data protocols. 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 5

CirrusWorks Governor in Collaboration INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION The CirrusWorks Governor may be implemented as a stand-alone platform, or in conjunction with other traffic shaping or application-aware systems. In this deployment model, the Governor arbitrates traffic oversubscription, over and above that which may already be modified or managed by a traffic shaper or a WAN optimizer. Landscape of Equipment Options We re often asked to qualify and quantify CirrusWorks in a quadrant landscape of equipment vendors. CirrusWorks places itself in a low cost + low complexity quadrant. We are solving the problems encountered by the majority of IT organizations and their users. 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 6

Competitive Product Review INTERNET BANDWIDTH CONGESTION AND OPTIMIZATION There are no direct comparisons possible among the various technologies and industry players in the bandwidth congestion space. Each vendor is offering something different by technology and price point. CirrusWorks offers the following analysis as we believe it indicative of the marketplace and how narrow and tailored the other offerings become by the introduction of static rules and static policy management. Technology Focus Dynamic Bandwidth Control Bandwidth Equalization Traffic Shaping WAN Optimization Application Bandwidth Mgmt Company CirrusWorks Net Equalizer Blue Coat & Cisco F5 & Silver Peak Riverbed & X-Roads Decision Model Behavioral Based Yes Yes No No No Static Rules & Policies No Yes Yes Yes Yes Applicability Data Center Large Enterprise Distributed WAN / MPLS Small/Medium Enterprise TeleWorking / Residential About CirrusWorks CirrusWorks is the leader in dynamic bandwidth management. The CirrusWorks Governor optimizes traffic during peak congestion periods to ensure fast and reliable Internet performance for all users. Only CirrusWorks employs AutoAlgorithms that adapt to unpredictable traffic patterns in real time, without the need to pre-configure static rule sets or policies. For more information, visit www.cirrusworks.net. CirrusWorks, Inc. 510 N Washington Street, Suite 300 Falls Church, VA 22046 +1.703.260.6999 info@cirrusworks.net www.cirrusworks.net 2015 CirrusWorks, Inc. All rights reserved. CirrusWorks and CirrusWorks Governor are trademarks or registered trademarks of CirrusWorks, Inc. or its subsidiaries in the United States and other countries. All other names are trademarks of their respective owners. WP-IBC-1501 2015 CirrusWorks, Inc. All rights reserved. www.cirrusworks.net 7