Welcome!

Machine Learning Authors: Yeshim Deniz, Pat Romanski, Liz McMillan, Corey Roth, Elizabeth White

Related Topics: SDN Journal, Microservices Expo, Containers Expo Blog, @CloudExpo, Cloud Security, @DXWorldExpo

SDN Journal: Blog Feed Post

Service Chaining and Unintended Consequences

Service chaining in a nutshell is basically orchestration of network services

Service chaining is a popular term today to describe a process in the network that's been done in the land of application integration for a long time. Service chaining in a nutshell is basically orchestration of network services. This concept is being put forth as the way future data center networks will be designed and execute in the future.

Its unintended consequence is, of course, that chaining can have a profound impact on performance, particularly when (or if) those chains extend across providers.

Let's consider an existing service chaining example that's challenging for SSL in terms of performance.

The Rest of the "SSL Performance" Story

Now, we're all aware that SSL handshaking introduces latency. It has to because in addition to the already time-consuming process of performing cryptographic functions, it requires additional round trips between the client (browser) and server (or intermediate network proxy acting as the endpoint, such as a load balancer or ADC) to exchange the information needed to encrypt and decrypt subsequent communication.

But that's not all it needs to do. The certificate offered up by the server-side device is increasingly suspect thanks to a variety of incidents in which basically forged certificates were used to impersonate a site and trick the user into believing the site was safe. As the SSL Everywhere movement continues to grow, so has the decision by browsers to properly validate certificates by querying an OCSP (Online Certificate Status Protocol) responder as to the status of the certificate (this is increasingly favored over the use of CRL (Certificate Revocation Lists) to address certain shortcomings of the technology).

What this means is that during the SSL handshake, the client makes a request to an OCSP responder. It's an additional service in the connection chain that adds time to the "load" process. Thus, it needs to be as fast as possible because it's counted in the "load time" for a page, if not technically then from the perspective of the user which, as we all know, is what really counts.

So the browser makes a request to the responder. It does this by choosing a responder from a list of those that support the CA (Certificate Authority, the issuer of the certificate in question). While there are a large number of global CAs, the actual number of global CAs for SSL is fairly small. Thus the responder is almost certainly very large and likely to see billions of requests a day, from around the globe. This "link in the chain" is increasingly important to the overall performance experienced by the end-user. Its impact on mobile users, in particular, is worthy of note given the impact of mobile networks and constrained device capabilities, as noted by Mike Belshe, one of the folks who helped create the SPDY protocol (emphasis mine):

But this process is pretty costly, especially on mobile networks. For my own service, I just did a quick trace over 3G:

  • DNS (1334ms)
  • TCP handshake (240ms)
  • SSL handshake (376ms)
  • Follow certificate chain (1011ms) — server should have bundled this.
  • DNS to CA (300ms)
  • TCP to CA (407ms)
  • OCSP to CA #1 (598ms) — StartSSL CA uses connection close on each!
  • TCP to CA #2 (317ms)
  • OCSP to CA #2 (444ms)
  • Finish SSL handshake (1270ms)

-- Rethinking SSL for Mobile Apps

The emphasized portions of the transaction indicate those related to the certificate verification process being carried out by the browser as a security precaution. Over a non-mobile network, one would expect the performance to improve, but the impact on "regular" browsers should not be underestimated, either. Early last year Adam Langley noted this and proposed to disable OSCP validation in Chrome: .

The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.

On this basis, we're currently planning on disabling online revocation checks in a future version of Chrome.

http://www.imperialviolet.org/2012/02/05/crlsets.html

I'll save the security-related arguments for another time, but suffice to say that the impact of service chaining on performance in the case of SSL and certificate validation is significant enough at times to be noticed.

Key Takeaway

Now certainly service chaining in other contexts, say in the data center network, would not experience the same magnitude of delay based purely on the fact that we're talking about LAN speeds rather than what often end up being inter- or cross-continental communications. Still, the very real impact of service chaining, particularly when such chains are comprised of a long string of services, should not be ignored or underestimated. Such chains introduce  additional latency, often in the form of unnecessary, duplicated functions as well as the possibility of failure. Load and utilization monitoring and scaling strategies of individual (dependent) services is a vital to the overall success of any architecture which employs an orchestrated (chained) services strategy.

And while technologies like SDN and cloud offer corrective action in the face of failure, it should be noted that such corrections tend to be reactions to failure. That means at least one user experiences a failure before a correction is made. In some cases that failure will go unnoticed except for a lengthier response time, but the key takeaway there is that it is noticeable.

And when it comes to web application performance, noticeable degradations are not something the business or operations, for that matter, likes to see. Not even for a single user.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the massive amount of information associated with these devices. Ed presented sought out sessions at CloudEXPO Silicon Valley 2017 and CloudEXPO New York 2017. He is a regular contributor to Cloud Computing Journal.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogger and is a frequent speaker on the use of Big Data and data science to power the organization's key business initiatives. He is a University of San Francisco School of Management (SOM) Executive Fellow where he teaches the "Big Data MBA" course. Bill was ranked as #15 Big Data Influencer by Onalytica. Bill has over three decades of experience in data warehousing, BI and analytics. He authored E...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
Sanjeev Sharma Joins November 11-13, 2018 @DevOpsSummit at @CloudEXPO New York Faculty. Sanjeev Sharma is an internationally known DevOps and Cloud Transformation thought leader, technology executive, and author. Sanjeev's industry experience includes tenures as CTO, Technical Sales leader, and Cloud Architect leader. As an IBM Distinguished Engineer, Sanjeev is recognized at the highest levels of IBM's core of technical leaders.