| Description | To ensure fairness, the CMTS will throttle the rate for
bandwidth request (upstream)/packet sent (downstream) at
which CMTS issues grants(upstream) or allow packet to be
send(downstream) such that the 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 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
wtExPacketDiscard(4) : Weighted excess packet discard
algorithm.
shaping(5): token bucket algorithm with shaping
Upstream supports the following:
No rate limiting (1),
Bursty 1 second token bucket algorithm(2),
Average token usage (CAR-like) algorithm(3),
Token bucket algorithm with shaping(5).
Downstream supports the following:
No rate limiting (1),
Bursty 1 second token bucket algorithm(2),
Average token usage (CAR-like) algorithm(3),
Weighted excess packet discard algorithm(4), and
Token bucket algorithm with shaping(5).
Token bucket algorithm with shaping is the
default algorithm for upstream if CMTS is in DOCSIS 1.0 mode
or DOCSIS 1.1 mode.
Bursty 1 second token bucket algorithm is the
default algorithm for downstream if the CMTS is in
DOCSIS 1.0 mode. If it is in DOCSIS 1.1 mode the default
algorithm for downstream is Token bucket algorithm with
shaping .
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
cable modem 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 cdxQosIfRateLimitShpMaxDelay to
configure the the maximum shaping delay and
cdxQosIfRateLimitShpGranularity to configure the
shaping granularity. |