Negative Leacky Bucket Sample Clauses
The Negative Leaky Bucket clause establishes a mechanism for managing and limiting the rate at which certain actions, such as data transmissions or requests, can occur, but allows for temporary negative balances or overdrafts. In practice, this means that if the allowed quota is exceeded, the system can temporarily permit additional actions, resulting in a negative balance that must be compensated for by reduced activity in the future. This clause is particularly useful for smoothing out short-term spikes in activity while still enforcing overall limits, thereby preventing abuse while accommodating occasional bursts.
Negative Leacky Bucket. The DSMeterNTB class is based on a leaky bucket algorithm, with CBS and CIR parameters, which allows the bucket tokens to go negative as much as –CBS. It differentiates between 4 different colors (of traffic): invisible, non-conformant, visible, and critical. It relies on the previous stage of Meters to color 2 of the traffic classes (e.g. for the Silver DSMeterNTB, Silver and Bronze traffic will be observed) into one of those categories based on the initial service class and whether that class was conformant or not in the first stage. The invisible and non-conformant colors apply to the same traffic class that this DSMeterNTB is assigned, and the visible and critical colors apply to the lower class that this DSMeterNTB need to assess for upgrade. For example, for the Silver DSMeterNTB, the first stage conformant Silver traffic will be invisible, non-conformant Silver traffic will be non- conformant, conformant Bronze will be visible and non-conformant Bronze will be critical. This class is best described by a snippet of the code as shown in Table 5. Table 5 DSMeterNTB code snippet if (*color == invisible) { if ((tokenBytes + CBS - size) < 0) { return(NONCONFORMANT); } tokenBytes -= size; return(CONFORMANT); } if ((tokenBytes - size) >= 0) { if (*color == visibleColor) { /*keep visible count to recolor critical pkts*/ criticalTokens += size; } tokenBytes -= size; *color = invisible; return(CONFORMANT); /*upgrade*/ } else { if ((*color == criticalColor)&& ((criticalTokens - size) >= 0)) { /*remark as visible but do not upgrade*/ criticalTokens -= size; *color = visibleColor; } return(NONCONFORMANT); } The code shows that if the color is invisible and there are enough bucket tokens (up to –CBS), the packet is inserted in the queue (packet deemed CONFORMANT, and is not dropped). Therefore, only invisible color packets can drive the bucket tokens to go negative. For the 3 remaining colors, if there is enough tokens (tokenBytes-size>=0), the packet is inserted in the queue and thus automatically upgraded in case the color is visible or critical. If there aren’t any bucket-tokens remaining, the packet is either dropped in case it is a non- conformant packet or could not be upgraded if it was a lower class packet (the caller of this function acts accordingly based on the NONCONFORMANT return code). This class keeps track of the number (in bytes) of visible packets upgraded so that it re-colors critical packets as visible in their place whenever a critical packet ...