Verifying Service Readiness with DoS (part 2 of 2)
Previously on Mu Line Blog
Continued from last week…
Meanwhile, the reality is that if the NIC doesn't like the CRC and the IP stack doesn't like it's checksum and so on, the data usually gets tossed in the bit bucket before it reaches the true target - the application itself. This is what makes Mu's DoS module useful - our development team uses service level traffic variation and protocol knowledge to make sure that the payload passed all the system checks and gets all the way to the top level where it can attack the service, rather than just bouncing off one of the lower-level data checking subroutines.
Let's say you are a network operator and have built this awesome infrastructure that pushes bits. That's what your development and operations team has been capable of delivering and testing. We can sniff and calculate latency and guarantee that the data is getting there OK. Then what? The application is traditionally a "black box", the effectiveness of which you have to rely on vendor tools to gauge. So I’m going to trust Vendor X’s tool to tell me that Vendor X’s box is perfectly free of flaws? Vendor reps are trained to say, "Uh, it's your network." Saw this personally many, many times when I used to conduct that kind of work. So ultimately you may waste your time and money hiring a consultant to run essentially load-only traffic testing and tell you your network is OK.
Well, Mu's DoS module, since it is service level traffic-aware and smart enough to interact with the target service itself and not just spam the hardware, ignores the network, hits the service directly, and gauges its responsiveness. Product vendors simply can't hide quality issues from Operator customers any longer. Network operators know a lot about selling bandwidth, but NGN services aren't simply a bandwidth commodity. You need a systematic approach that goes all the way to the top and gives you meaningful metrics on your "exhaustion profile". At what level of service-specific abuse on the upswing do I start to lose the app and at what point on the release do I get it back?
This application analysis and testing proof point is likely an alien concept to bandwidth salesmen because they are typically on the defensive. The attitude is, "I delivered the packets, what more do you want from me? Go bug the IT, Security or Server guys." The server hardware and front end load balancer salesmen blame the network and the application and the application authors just blame everyone else. The OS vendor tells you to read the fine print on your EULA. Time to stop the finger pointing and get everyone to fix the REAL problem.
Perhaps it will not happen tomorrow. but at least you have Mu's DoS module to accurately define and describe the pickup and dropoff points for your service configuration and plan accordingly. This way vendors (e.g. network, load balancer, and application developers) argue among themselves while operators do the real work of correlating configuration changes to the real user experience. Let the server guy throw more RAM and a more hardcore NIC on the box - then rerun the test and see if your exhaustion profile changes. We are all about helping our customers short-circuit these finger pointing games that vendors like to play with you.
And in my experience, once operators and enterprises provide vendors with hard data they can't weasel their way out of, their SEs start buying you much better lunches. And if they have real data to work with, like the Mu Test Suite provides, they stop blaming and start fixing.
Comments:
Write a comment
- Required fields are marked with *.
|
