| Description | To ensure fairness, at the upstream, the HE will throttle
the rate of bandwidth grants, such that the flow never
gets more than its provisioned peak rate in bps.
Similarly at the downstream, HE controls the packets
sent such that flow never gets more than its provisioned
peak rate in bps.
There are two directions for every Service Id (Sid) traffic:
downstream and upstream. Each direction is called a service
flow here and is assigned one token bucket with chosen
algorithm.
The enumerations for the rate limiting algorithm are:
noRateLimit(1): The rate limiting is disabled. No rate
limiting.
oneSecBurst(2): Bursty 1 second token bucket algorithm.
carLike(3) : Average token usage (CAR-like) algorithm
wgtExPacketDiscard(4) : Weighted excess packet discard
algorithm.
shaping(5): token bucket algorithm with shaping
Upstream supports all the above except
wgtExtPacketDiscard(4).
Downstream supports all the above rate-limiting algorithms.
Token bucket algorithm with shaping is the
default algorithm for upstream.
Bursty 1 second token bucket algorithm is the
default algorithm for downstream.
Each algorithm is described as below:
No rate limiting:
The rate limiting process is disabled and no checking
against the maximum bandwidth allowed.
Bursty 1 second token bucket rate limiting algorithm:
In this algorithm, at the start of every 1 second interval,
a service flow's token usage is reset to 0, and every time
the modem for that service flow sends a request (upstream) /
packet (downstream) the upstream/downstream bandwidth
token usage is incremented by the size of the
request/packet sent. As long as the service flow's bandwidth
token usage is less than the maximum bandwidth in bits
per second (peak rate limit) its QoS service class
allows, the request/packets will not be restricted.
Once the service flow has sent more than its peak rate in the
one second interval, it is prevented from sending more
data by rejecting request (upstream) or dropping
packets (downstream). This is expected to slow down
the higher layer sources. The token usage counter gets
reset to 0 after the 1 second interval has elapsed. The
modem for that service flow is free to send more data up to the
peak rate limit in the new 1 second interval that follows.
Average token usage (Cisco CAR like) algorithm:
This algorithm maintains a continuous average of the
burst token usage of a service flow. There is no sudden
refilling of tokens every 1 second interval. Every time a
request/packet is to be handled, the scheduler tries to see
how much time has elapsed since last transmission, and
computes the number of tokens accumulated by this service flow
at its QoS class peak rate. If burst usage of the service flow
is less than tokens accumulated, the burst usage is reset to 0
and request/packet is forwarded. If the service flow has
accumulated fewer tokens than its burst usage, the burst usage
shows an outstanding balance usage after decrementing by the
tokens accumulated. In such cases, the request/packet is still
forwarded, provided the service flow's outstanding usage does
not exceed peak rate limit of its QoS class. If outstanding
burst usage exceeds the peak rate of the class, the service
flow is given some token credit up to a certain maximum credit
limit and the request/packet is forwarded. The request/packet
is dropped when outstanding usage exceeds peak rate and maximum
credit has been used up by this service flow. This algorithm
tracks long term average bandwidth usage of the service flow
and controls this average usage at the peak rate limit.
Weighted excess packet discard algorithm:
This rate limiting algorithm is only available as an option
for downstream rate limiting. The algorithm is to maintain an
weighted exponential moving average of the loss rate of a
service flow over time. The loss rate, expressed in packets,
represents the number of packets that can be sent from this
service flow in a one second interval before a packet will
be dropped. At every one second interval, the loss rate gets
updated using the ratio between the flow peak rate (in bps)
in its QoS profile and the service flow actual usage (in bps).
If the service flow begins to send more than its peak rate
continuously, the number of packets it can send in an one
second interval before experiencing a drop will slowly keep
reducing until SU for that service flow slows down
as indicated by actual usage less or equal to the peak rate.
Token bucket algorithm with shaping:
If there is no QoS class peak rate limit, forward the
request/packet without delay. If there is a QoS peak rate
limit, every time a request/packet is to be handled, the
scheduler determines the number of bandwidth tokens that this
service flow has accumulated over the elapsed time at its
QoS class peak rate and increments the tokens counter of the
service flow accordingly. The scheduler limits the token
count to the maximum transmit burst (token bucket depth).
If token count is greater than the number of tokens required
to handle current request/packet, decrement token count by
size of request/packet and forwards the request/packet
without delay. If token count is less than the size of
request/packet, compute the shaping delay time after
which the deficit number of tokens would be available. If
shaping delay time is less than the maximum shaping delay,
decrement tokens count by size of request/packet and
forward this request/packet with the shaping delay in the
shaping delay queue. When the delay time expires, the
request/packet is forwarded. If shaping delay time is
greater than the maximum shaping delay that the subsequent
shaper can handle, the request/packet is dropped. Users can
use cwdxQosIfRateLimitShpMaxDelay to configure the maximum
shaping delay and cwdxQosIfRateLimitShpGranularity to
configure the shaping granularity. |