Autonomous Hardware Capacity Limiting for Application Protection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Applications deployed on varying hardware or in dynamic virtual/cloud environments face challenges in setting deterministic limits due to unknown or changing processing capabilities, exacerbated by Distributed Denial of Service (DDoS) attacks that flood systems, leading to performance degradation or failure.
Innovation Solution
An algorithm within the application determines and enforces configurable limits based on user-accessible information about available processing power, memory, and hardware topology, such as in NUMA systems, to manage network traffic and prevent overload by dropping excess traffic or scaling instances.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If the application operates in dynamic virtual/cloud environments with unknown or changing hardware capacity, then the application can be deployed flexibly, but the application cannot set deterministic limits to prevent failure under excessive load
Solution Approach 1:
The application autonomously determines its hardware capacity limits by querying system information APIs and independently calculates appropriate rate limits without external intervention. The application monitors its own performance metrics and adjusts limits accordingly, enabling self-service operation in dynamic environments.
Solution Approach 2:
The system continuously monitors application performance metrics and hardware capacity, using this feedback to dynamically adjust rate limits. When the application detects excessive load or hardware constraints, it modifies its operating parameters in real-time to maintain reliable operation under varying conditions.
2Object-affected harmful factors
If the application uses known rate limiting techniques to prevent DDoS attacks, then some protection is provided, but the application performance degrades due to excessive traffic flooding
Solution Approach 1:
The application dynamically adjusts rate limiting parameters based on real-time hardware capacity monitoring and performance metrics. Instead of using fixed or overly conservative limits, the system optimizes parameters to allow maximum legitimate traffic while blocking malicious DDoS attempts, thereby maintaining high application performance.
Solution Approach 2:
The rate limiting mechanism transitions from static to dynamic operation, continuously adapting to changing hardware conditions and attack patterns. The system monitors network traffic characteristics and hardware capacity in real-time, adjusting limits dynamically to distinguish between legitimate traffic and DDoS attacks, preventing performance degradation.
3Reliability
If the application sets strict hardware capacity limits to prevent overload, then reliability is improved, but the application cannot充分利用 available processing power
Solution Approach 1:
The application uses feedback from performance monitoring to continuously optimize rate limits. By monitoring actual processing capacity utilization and adjusting limits based on real-time data, the system prevents overload while maximizing processing power usage during normal operation conditions.
Solution Approach 2:
The rate limiting mechanism dynamically adjusts to match actual hardware capacity and workload conditions. During normal operation, the system allows higher throughput to maximize processing power utilization, while automatically reducing limits when approaching capacity thresholds to prevent overload, creating an optimal balance between productivity and reliability.
Data Source
AI summary
A method, apparatus and computer program to protect an application in an underlying multiprocessor computing system, e.g., one in which a processor has local memory available but can access memory assigned to other processors. In operation, a set of hardware characteristics for the underlying computing system are extracted. These characteristics preferably comprise processing power, available memory, and a topology. For each hardware characteristic, an operating limit for that characteristic is determined based at least in part on a baseline value that is determined for the application with respect to the hardware characteristic. Based on the operating limit determined for each hardware characteristic, a recommended limit for a system feature (e.g., network traffic) of the underlying computing system is computed. Thereafter, and during runtime execution of the application, the recommended limit is then enforced, e.g., by dropping excess traffic or spinning up additional application instances, to protect the application.