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 ...
View Source

Related to Negative Leacky Bucket

  • INTERIM ASSET SERVICING ARRANGEMENT With respect to each asset (or liability) designated from time to time by the Receiver to be serviced by the Assuming Bank pursuant to this Arrangement (such being designated as "Pool Assets"), during the term of this Arrangement, the Assuming Bank shall:

  • Wire Unbundled DS1 Digital Loop This is a designed 4-wire Loop that is provisioned according to industry standards for DS1 or Primary Rate ISDN services and will come standard with a test point, OC, and a DLR. A DS1 Loop may be provisioned over a variety of loop transmission technologies including copper, HDSL-based technology or fiber optic transport systems. It will include a 4-Wire DS1 Network Interface at the End User’s location.

  • Under-Frequency and Over Frequency Conditions The New York State Transmission System is designed to automatically activate a load- shed program as required by the NPCC in the event of an under-frequency system disturbance. Developer shall implement under-frequency and over-frequency relay set points for the Large Generating Facility as required by the NPCC to ensure “ride through” capability of the New York State Transmission System. Large Generating Facility response to frequency deviations of predetermined magnitudes, both under-frequency and over-frequency deviations, shall be studied and coordinated with the NYISO and Connecting Transmission Owner in accordance with Good Utility Practice. The term “ride through” as used herein shall mean the ability of a Generating Facility to stay connected to and synchronized with the New York State Transmission System during system disturbances within a range of under-frequency and over-frequency conditions, in accordance with Good Utility Practice and with NPCC Regional Reliability Reference Directory # 12, or its successor.

  • Unbundled Voice Loops (UVLs) 2.2.1 BellSouth shall make available the following UVLs:

  • Assuming Institution Portfolio Sales of Remaining Shared-Loss Loans The Assuming Institution shall have the right, with the consent of the Receiver, to liquidate for cash consideration, from time to time in one or more transactions, all or a portion of Shared-Loss Loans held by the Assuming Institution at any time prior to the Termination Date (“Portfolio Sales”). If the Assuming Institution exercises its option under this Section 4.1, it must give sixty