Web App Performance: Think 1990s.
As I’ve mentioned before, I am intrigued by the never-ending cycle of repetition that High Tech seems to be trapped in. Mainframe->Network->Distributed->Virtualized->Cloud, which while different, shares a lot of characteristics with a mainframe environment. The same is true with disks, after several completely different iterations, performance relative to CPUs and Application needs are really not that different from 20 years ago. The big difference is that 20 years ago we as users had a lot more tolerance for delays than they do today. One of my co-workers was talking about an article he recently read that said users are now annoyed literally “in the blink of an eye” at page load times. Right now, web applications are going through one of those phases in the performance space, and it’s something we need to be talking about. Not that delivery to the desktop is a problem, network speeds, application development improvements (both developers learning tricks and app tools getting better), and processing power have all combined to overcome performance issues in most applications, in fact, we’re kind of in a state of nirvana. Unless you have a localized problem, application performance is pretty darned good. Doubt me? Consider even trying to use something like YouTube in the 90s. Yeah, that’s a good reminder of how far we’ve come. But the world is evolving again. It’s no longer about web application performance to PCs, because right about the time a problem gets resolved in computer-land, someone changes the game. Now it’s about phones. To some extent it is about tablets, and they certainly need their love too, but when it comes to application delivery, it’s about phones, because they’re the slowest ship in the ocean. And according to a recent Gartner report, that won’t change soon. Gartner speculates that new phones are being added so fast that 4G will be overtaken relatively quickly, even though it is far and away better performance-wise than 3G. And there’s always the latency that phones have, which at this point in history is much more than wired connections – or even WLAN connections. The Louis CK video where he makes like a cell phone user going “it.. it’s not working!” when their request doesn’t come back right away is funny because it is accurate. And that’s bad news for IT trying to deliver the corporate interface to these devices. You need to make certain you have a method of delivering applications fast. Really fast. If the latency numbers are in the hundreds of milliseconds, then you have no time to waste – not with excess packets, not with stray requests. Yes of course F5 offers solutions that will help you a lot, that’s the reason I am looking into this topic, but if you’re not an F5 customer, and for any reason can’t/won’t be, there are still things you can do, they’re just not quite as effective and take a lot more man-hours. Going back through your applications to reduce the amount of data being transferred to the client (HTML can be overly verbose, and it’s not the worst offender), go through and create uber-reduced versions of images for display on a phone (or buy a tool that does this for you), consider SPDY support, since Google is opening it to the world. No doubt there are other steps you can take. They’re not as thorough as purchasing a complete solution designed around application performance that supports cell phones, but these steps will certainly help, if you have the man-hours to implement them. Note that only one in three human beings are considered online today. Imagine in five years what performance needs will be. I think that number is actually inflated. I personally own seven devices that get online, and more than one of them is turned on at a time… Considering that Lori has the same number, and that doesn’t count our servers, I’ll assume their math over-estimates the number of actual people online. Which means there’s a great big world out there waiting to receive the benefits of your optimized apps. If you can get them delivered in the blink of an eye. Related Articles And Blogs March (Marketing) Madness: Consolidation versus Consolidation March (Marketing) Madness: Feature Parity of Software with Hardware March (Marketing) Madness: Load Balancing SQL March (Marketing) Madness: Consolidation versus Consolidation March (Marketing) Madness: Feature Parity of Software with Hardware What banks can learn from Amazon Mobile versus Mobile: 867-5309
A new Strategy for CSP Scalability and Performance
Communication service providers (CSP) are currently spending large amounts of money to deploy 4G and advanced networks. Historically CSP's have managed scaling and performance of networks by increasing bandwidth and spending more money on frequencies and hardware. However with 4G networks being all IP, CSP's now must take into account more elements in dealing with the scaling and performance of their networks. With all-IP networks scaling becomes more dependent upon designing and developing intelligent architectures. In order to obtain a quick return on this 4G investment, CSP’s must maintain competitiveness, provide a consistent quality of experience (QoE) for their subscribers, and deliver new services and applications. Adding more bandwidth and hardware will always be an element of scaling and performance. However with all-IP networks, these are not the only elements to consider for successful scaling and performance. CSPs are forced to design and deploy IP infrastructure that is flexible and scalable to create the basic architecture for affordable scalability for all services and applications on the network. This infrastructure includes network services and subscriber and traffic management. Intelligence is the only way that a communication service provider can maintain competitiveness and reduce subscriber churn. Network services such as AAA, IP allocation, domain name system (DNS), policy and signaling traffic are all key elements defining how traffic is managed for subscriber experience with the network optimization. As subscribers connect to the network, initial bandwidth and RF coverage are always very important. However in an all-IP network, once a subscriber has made the RF connection, the initial set up and connections to applications and services are key to establishing an acceptable and competitive QoE . AAA and IP allocations have to be managed to provide an intelligent assignment of authorizations and IP addresses based upon the tiers of service and/or subscriber definitions that the CSP designates. DNS can be used for locating applications and services both on the CSP's network and on the Internet. By using DNS, CSPs can determine the most available service to direct subscriber requests. Policy and signaling traffic is essential to the CSP's business model. Due to the change in from circuit switch voice and messaging, signaling traffic will significantly increase with voice over LTE (VoLTE) and other IMS applications. Policy can be used to help enforce rules for fair usage and bandwidth and network services. However in order to be effective these policy systems also have to be considered in planning for increasing the scale and network performance. One of the most significant changes in transition to an all IP network is the removal of circuit-switched voice channels. VoLTE is a standard that was created in order to provide voice services on LTE network. VoLTE is primarily based upon using the Internet multimedia subsystem IMS architecture to provide for subscriber registration, policy, billing, a comprehensive voice services (i.e. voice calls, roaming voice calls, voicemail, etc.). The key to initial success for voice over LTE is to provide, at a minimum, the same quality of experience that was delivered on 3G networks. With this challenge, initial scaling and performance of the networks will be essential to support new subscriber uptake and minimize churn. Changes in traffic patterns and flexibility in the scaling of network infrastructure is the only way to maintain and acceptable QoE. As new network technology is developed, new devices are launched in the market and new applications and services are demanded by subscribers, CSPs are challenged to offer all of these while still maintaining a consistent user experience on legacy applications and technology. An intelligent and flexible IP infrastructure creates the core environment to enable the launching of competitive and new services and still maintains legacy applications. By deploying an intelligent and flexible IP infrastructure allows for intelligent scaling and help identify the need and timing of adding more bandwidth and hardware to the network. Related Articles Lori MacVittie - performance Lori MacVittie - Performance F5 News - performance Ray Vinson - DNS Ray Vinson - 4G F5 Friday: No DNS? No … Anything. v11.1: DNS Blackhole with iRules > DevCentral > Tech Tips on ... Audio White Paper - High-Performance DNS Services in BIG-IP ...IPv6: Not a Solution for Security!!!
On April 15 th , 2011, the last of the IPv4 address blocks was allocated,. Due to IPv4 address depletion, migration to IPv6 is inevitable. This migration to IPv6 will ease IPv4 address depletion but it does not address other significant networking issues such as security. Networks that have already migrated to IPv6 are starting to experience the first Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. These attacks can lead to significant amounts of downtime and, especially for Communication Service Providers, loss of revenues and increases in subscriber churn. For CSP’s to stay competitive and maintain an acceptable Quality of Experience (QoE), security and mitigation of DoS/DDoS attacks must be included in the migration to IPv6. Throughout the development of IPv6 technology, security was an integrated part of the standards. In the original version of the RFC, IPsec was integrated into the IPv6 header. IPsec provided basic security in the IP stack. However, in December 2011 IPsec as a requirement was changed to an optional element in the RFC. This means that all IPv6 networks will have to be able to interoperate with traffic that includes both IPsec and non-IPsec. And even though there is the argument that by having non-IPsec integration and IPv6 opens the door for more DoS/DDOS attacks, IPsec is not the ultimate solution to DoS/DDOS attacks. Migration technologies have been created to make interoperability of IPv4 and IPv6 networks. For CSPs, this technology is crucial when their subscribers are on an IPv6 network and the content that the subscribers demand is on the IPv4 Internet. Carrier grade network address translation (CGNAT) is designed to managed address translations and assignments for IPv4 and IPv6 networks. This technology integrated with Domain Name System 64 (DNS64) ensures that addresses and domains are locatable and accessible from either an IPv4 or IPv6 network. Tunneling technologies, such as Dual Stack Lite and 6RD, transport traffic through encrypted tunnels which allows IPv4 or IPv6 traffic to be delivered across either network. All of these methods provide different tools for the CSP to migrate all or part of their network to IPv6 and still is able to interoperate with the IPv4 Internet. However, none of these methods address the security threats that exist on the Internet. DoS/DDoS attacks can never be completely prevented. The only strategy that truly works is using security tools, like IPsec, along with distributed architectures to mitigate the impact of these attacks. While CSP’s are migrating to new technologies and upgrading to IPv6, new security architecture should be examined. Since almost every part of the network has to be touched, , this is the perfect opportunity for CSP's to update their security architecture along with becoming IPv6 compliant. No matter which technology scheme for migration to IPv6 is used, all elements of the network can be designed to help mitigate the impacts and costs of Dos/DDoS attacks. Whether it is CGNAT, DNS 64, IPv6 Gateway, or tunneling methodologies, all of the different IPv6 migration technologies can be deployed to maintain service up time during a DoS/DDoS attack. The ultimate goal of mitigating a DoS/DDoS attack is to maintain services for subscribers and minimize degradation of the QoE for subscribers. The challenge of achieving this goal is deploying a network to provide this level of service during an attack without creating a CapEx nightmare. The first step in being successful is creating a network that will maintain service during a DoS/DDoS attack and minimize the expenditures associated is to create an intelligent IPv6 infrastructure that can scale, perform and distribute traffic in an intelligent manner to mitigate the impacts of an attack. Deploying IPv6 is not a solution to attacks from the Internet, however the network architecture can be built to mitigate the impacts of these attacks and this architecture can be deployed as part of the migration to IPv6. Related Articles ZDNet: “First IPv6 Distributed Denial of Service Internet Attacks Seen” RFC 6434 Pete Silva - ipv6 Ray Vinson - IPv6 Lori MacVittie - DDoS F5 Friday: 'IPv4 and IPv6 Can Coexist' or 'How to eat your cake and ... Josh Michaels - DDoS Mitigating Slow HTTP Post DDoS Attacks With iRules > DevCentral ... IPv6 - DevCentral - DevCentral Groups - Social Forums ... IP::addr and IPv6 Audio White Paper - Controlling Migration to IPv6: A Gateway to ... IPv6: Yeah, we got thatCarrier Grade DNS: Not your Parents DNS
Domain Name System (DNS) is one of the overlooked systems in the deployment of 4G and Next Generation All IP Networks. The focus tends to be on revenue-generating applications that provide ROI for these major investments. For these to be successful the CSP's have first got to be able to deploy these networks, and provide a high quality of experience in order to be sure that these services are truly revenue generating. However, most CSP’s have overlooked some of the basic IP functions in order to provide these revenue generating applications. The building blocks for these applications are a quality, efficient, scalable, and feature-rich IP architecture. One of the key items that are required for this IP architecture is Carrier Grade DNS. DNS has been a long-standing requirement for Internet services for CSP's. However with these all IP networks, DNS is being used for new capabilities along with supporting increases in data traffic for standard content and Internet services. For years CSP's and employed cheap, inexpensive, and basic DNS systems on their network. This was done to provide basic DNS services and to minimize cost. However with and developing networks, these basic DNS deployments will not support the requirements of the future. DNS services are starting to be used for new and unique capabilities, which include managing traffic on both the internal network along with external content that is located on the Internet. Along with this new functionality, DNS is also required to provide security of DNS transactions and have the ability to mitigate against DNS attacks, along with providing for authoritative DNS zone management, resolution, and non-authoritative support, such as caching. The significant challenge for communication service providers is to provide these DNS capabilities while still maintaining a manageable Capex and Opex. This challenge can only be met by deploying a carrier grade DNS solution. The carrier grade DNS solution comprises all the basic capabilities of DNS, along with including a logical scaling capability, security for DNS transactions, and an ability to intelligently manage authoritative zones. Historically, traditional DNS solutions have addressed scaling by simply adding more hardware. This method is a Capex nightmare. With the increases in data and data demands, these problems with DNS scaling will grow exponentially. The only solution to this problem is the ability to deploy an intelligent DNS system that allows the communication service provider the ability to manage how DNS queries and how DNS authoritative responses are managed and delivered to subscribers. Since DNS is key in the ability to identify the location of web content it is vulnerable to both DNS hijacking attacks and denial of service (DoS) or distributed denial of service (DDoS) attacks. To prevent DNS hijacking attacks, carrier grade DNS solutions must be incorporated DNSSEC. By incorporating DNSSEC, responses to subscribers are guaranteed the identity of the answering authoritative DNS. DoS/DDoS attacks cannot be prevented. The only strategy they can be taken against DoS/DDoS is to mitigate the impact of these attacks. The best way to address the mitigation the impact of DoS/DDoS attacks is through a distributed carrier grade DNS architecture. By using such technologies as Global Server Load Balancing (GSLB) and IP Anycast, a distributed carrier grade DNS architecture can isolate and limit the impacts of DoS/DDoS attacks. GSLB allows the communication service provider to manage how DNS requests are answered based upon the location of the contents and the requester. IP Anycast allows for multiple systems to share the same IP address thereby distributing the number of systems answering request. By using these distributed systems DoS/DDoS attacks can be isolated and minimize the number of systems impacted. As we have seen over the past year, data use on CSP networks is going to continue to increase. To provide a successful ARPU model, a Carrier Grade DNS that provides for high availability, economical scalability, subscriber security, and high performance in essential. With all of the many challenges in a CSP network, basic IP infrastructure can be overlooked. An intelligent management system of these IP essential systems is the first step in reducing an ever expanding Capex and providing for a high quality of experience for your subscribers. Related Articles DNS is Like Your Mom F5 Friday: No DNS? No … Anything. Audio White Paper - High-Performance DNS Services in BIG-IP ... DevCentral Weekly Roundup | Audio Podcast - DNS F5 Friday: When the Solution to a Vulnerability is Vulnerable You ... F5 News - DNS DNS Monitor Using Dig - DevCentral Wiki The End of DNS As We Know It F5 Video: DNS Express—DNS Die Another Day Ray Vinson – DNSPolicy: Not just QoS and Tiered Services.
With the development of Internet Multimedia Services (IMS), the challenge of defining how the IMS infrastructure would deliver application services and control the user experience was answered with Policy. Policy is simply the application of business rules to define how a subscriber interacts with the network, application and services. Since 3GPP included Policy into the IMS standards,(3GPP TS 23.203) the market has viewed Policy as simply bandwidth management and subscriber tiered services. However, this view of Policy is limited and incomplete implementation of Policy in a Communication Service Provider (CSP) network. In order to truly implement a comprehensive policy architecture, policy must be integrated into the design and implementation of all network services. Creating rules to define how a subscriber connects to the network, authenticates, has an IP address allocated, along with all the interactions of network support services such as IPv6 translations, DNS, NAT, security services, etc. This Policy definition is the only way to truly define the subscriber interaction with services and applications. As CSP’s transition to all IP networks, maintaining the Quality of Experience (QoE) will determine the CSP’s success against competition. The ultimate challenge in transitioning to these technologies is still providing at least the same QoE as the previous networks (3G and traditional circuit switched voice) across all services. Since voice is still the largest impact on ARPU, delivering a quality VOIP solution (or VoLTE for wireless 4G) that is as stable and reliable as circuit switched voice is essential for success. Comprehensive policy across all IP services in the network provides a level of management related to these new technologies and the subscriber experience. IMS standards for Policy, specifically Policy defined at the Policy Control and Revenue Function’s (PCRF) relationship with the Policy Control Enforcement Function (PCEF), takes the first step in defining this policy architecture. The PCRF, by definition, defines the policy associated with the subscriber and sends policy updates to the PCEF, which will packet, shape (via Quality of Service (QoS)) the packet for that session. The PCRF makes these decisions based upon the subscriber’s tier of service, network origin, application, service definition and network status information. This Policy step is crucial, but it is incomplete for Comprehensive Policy across the network. For Comprehensive Policy, all network services need to be Policy aware and be able to enforce policy according to the specific network service. For example, as a device connecting to the IMS network, a DNS query is sent to determine the Call Session Control Function (CSCF) for the first SIP request. A standard DNS server will simply return the A or AAAA record (depending of if this is on an IPv4 network or IPv6 network) that it has for the appropriate CSCF. However, Policy can be used to define how that DNS server can determine which CSCF is returned based upon the network and subscriber. By defining this first interaction, the most available CSCF address can be returned to the device or, more specifically, a CSCF scheme can be defined based upon the location, network status, and subscriber. This is the first step in defining the experience that subscriber has with the IMS service. By defining Policy at the network services, the CSP takes control of the subscribers interaction at every point on the network. This makes all the network services a Policy enforcement point of the CSP’s business plan. These policies can be either dynamic or static, depending on the service or technology being deployed. Dynamic Policy allows for changes in the policy within the session without having dropping the session to make this Policy change. Static Policy is simply rules defined that do not change in mid-session. To provide for dynamic policy, a policy decision point is needed to pass policy changes to the policy enforcement point, this is the scheme that the PCRF and PCEF use to provide dynamic policy. However, using a combination of static and dynamic policy across all network services is the only way to offer comprehensive policy. As CSP technologies, applications and services evolve, the real challenge is maintaining ARPU and reducing, or managing, subscriber churn in order to maximize profit and stay competitive. The only way to achieve this is to maintain, and improve, the QoE as new applications and services are delivered to the subscriber. Understanding and managing the relationships between all services and the subscriber with the network is the only way to control the QoE. Comprehensive Policy across all network elements and services is the only way to manage these relationships between the subscriber and services. Related Articles New Service Provider BlogIPv6: Not When but How?
Over the last 10 years, there have been a lot of discussions about the depletion of IPv4 addresses. With development of the IPv6 standards, general consensus is that the Internet will eventually transition to IPv6. The real question has been “When will this transition take place?” For Communication Service Providers (CSP), increases in data usage and IP devices have caused industry standard’s bodies (such as 3GPP, TiSpan, 3GPP2 and CDG) to incorporate IPv6 in their high speed network architectures. This has caused CSP’s to include transition to IPv6 as part of their 4G and advanced network rollouts. The challenge is that with the majority of the Internet still being on IPv4, how is the best way to still give subscribers access to the content that they want and demand. So for the CSP’s, the question now is not when but how to transition to IPv6. There are several articles, blogs and discussions on the Internet about the different methods of transitioning to IPv6. Instead of re-hashing this information, I want to concentrate on the pros vs. cons of a few of the more prevalent methods. Dual Stack What is it? Dual stack is where a single system supports both IPv6 and IPv4 simultaneously. This is usually accomplished by both a hardware and software on the system. PROS This is a quick method to transition to a new IPv6 network while still supporting traffic on an IPv4 network. CONS This is extremely costly and can significantly impact performance of an individual system. DS –Lite What is it? DS – Lite requires the deployment of an IPv6 network and encapsulates IPv4 traffic in an IPv6 wrapper. This method was specifically designed for Cable networks interactions with set top boxes. PROS This method allows the deployment of IPv6 across the network and allows for IPv4 deployed protocols and applications that cannot use NAT to be integrated. CONS DS-Lite provides a significant overhead and is not all encompassing. Other solutions need to be incorporated in order to support IPv6 native protocols and traffic. 6RD What is it? 6RD uses pre-existing tunnels on an IPv4 network to transport IPv6 traffic. PROS This method is a fast way to support IPv6 traffic. CONS This does not deploy an IPv6 network at all. All the problems of IPv6 transition sill exist. Gateway and DNS64/NAT64 What is it? This method deploys a gateway to translate IPv4 traffic to IPv6, and back, and uses DNS64 to translate IPv4 records (A records) to IPv6 records (AAAA records) and coordinates with NAT64 to translate and manage IP addresses for both IPv4 and IPv6 traffic. PROS Allows for a complete migration to IPv6. Supports a complete interaction with both IPv6 and IPv4 Internet content. CONS Does not support IPv4 protocols that cannot interoperate in an NAT environment. Difficult to scale and manage performance These methods are not always independent and all inclusive. For example, if a CSP has a Quad Play offering (TV, Phone, Internet, and Wireless), DS-Lite may be a good solution for TV (Cable set top box) while still using an IPv6 Gateway, DNS64 and NAT64, and Dual Stack for other offering and systems. This architecture allows for a complete migration to an IPv6 offering while still supporting existing set top boxes at the customer locations. The ultimate challenge is for CSP’s to migrate to IPv6 with as little impact to the subscriber experience. The method chosen by CSP’s needs to be able to migrate to IPv6 and still support current IPv4 content and applications, and this needs to be done seamlessly to the subscribers. Related Articles F5 Friday: IPv6 Day Redux F5 Friday: 'IPv4 and IPv6 Can Coexist' or 'How to eat your cake ... IP::addr and IPv6 IPv6 and the End of the World DevCentral World IPv6 Day Live Podcast IPv6: Yeah, we got that Service Provider Series: Managing the IPv6 Migration Hackers, IPv6 and Denial of Service Attacks. Oh My! What is F5 Doing for World IPv6 Day? F5 Friday: Thanks for calling... please press 1 for IPv6 or 2 for ...
