Re: [STDS-802-16] Maximum Sustained Traffic Rate, Maximum Traffic Burst
Hi Steve,
I come from a comparable background (but not same) - DOCSIS systems,
so I will try to take a shot at answering. I am sure I will stand
corrected on some of these answers because the application of these
parameters to 802.16 may have been intended differently.
802.16 is a GPSS protocol - i.e., grants are made to the SS and the SS
can re-assign the grants to any of the requests pending with it. So,
if the SS is not policing the maximum sustained uplink rate for a
connection, it will be possible for SS to go over the limit when
multiple connections of the SS are transmitting (remember that there
are already multiple connections because each SS has at least 2
management connections - basic and primary). Hence, there is no way
that BS alone can police the uplink maximum sustained rate - it can
try to, but the ultimate control of which SDUs to transmit is with the
SS. Hence, the policing must be with SS.
This is very different than DOCSIS, which is a GPC (grant per
connection) protocol. In this protocol, the BS can exactly indicate
which of the connections must use the grant being made - hence, there
is an easy way to police the maximum rate at the BS. In fact, in
DOCSIS both the BS and SS are expected to police the maximum rate for
uplink transmissions (the BS policing requirement is to ensure that a
"hacked" SS cannot request and transmit more than its limit).
There is yet an other additional reason why this is required - the MAC
overhead is not expected to be accounted for the maximum rate (or
minimum rate) calculations. Note that the BS does not have *any* clue
about the MAC overhead for the allocations it is making - sure, it can
make a guess but the overhead can vary widely (will be glad to provide
a good example). Only the transmitter - in this case SS - has the
exact knowledge of what the exact SDU length being transmitted and
hence only SS can make this calculations correct. With some
difficulty, you can make the BS also to account only for SDU lengths
only and not the MAC overhead - but this means that the BS must be
tracking each and every SDU transmitted by each connection (I have
implemented this for DOCSIS and please take my word for this when I
say it is not an easy task, not to mention the amount of
processing/book keeping needed on the BS).
I am not sure if it is wise to make the BS account for the memory
limitations on the SS - if the memory is limited on the SS, the SDUs
will be lost and the higher level protocols (TCP for instance) should
be able to correct (by retransmissions). But may be, I am not
understanding your question here.
As for the maximum burst parameter, one of the common approaches to
implementing the maximum sustained rate is using a token bucket
algorithm. One of the parameters there is the bucket size - I believe
that maximum burst is expected to serve as the token bucket size. In
DOCSIS, this is the way the maximum rate requirement is defined even
though a vendor can use any other algorithm (as long as the
implementation satisfies the requirement).
I am not sure if the maximum latency parameter really makes any sense
for any connections other than RTPS and UGS - the specification is
very ambiguous about the way these parameters can be used. I believe
that the interpretation of this for NRTPS/BE connections will be
vendor dependent.
I believe the response to oversubscribing for minimum reserved rate
will be vendor dependent. DOCSIS also allows over-subscription but the
RTPS and NRTPS are guaranteed the bandwidth no matter what the
oversubscription situation is (you can not oversubscribe RTPS and UGS
in DOCSIS). I think that the 802.16 approach is to leave it to the
vendors - one may implement in a manner that the UGS connections are
given the minimum reserved rate and throttle the rest of the
connections; another may drop the bandwidth of all the connections;
yet another may do this for UGS and RTPS connections - the choices are
endless. I myself believe that the UGS connections must always get
their minimum reserved traffic rate - no matter what (just like
DOCSIS) - because UGS connections are normally used for voice flows or
circuit emulation services (like CESoIP, CESoE or TDMoIP -
http://www.tdmoip.com).
Do not have any clue about minimum tolerable traffic rate - would
appreciate if some one can pass on information on how this is expected
to work.
Thanks
Kalash
On 4/13/05, Ma Steve-p20680 <steve.ma@freescale.com> wrote:
>
>
> I am confused when reading the parameters in 11.13.6 and 11.13.7 (Maximum
> Sustained Traffic Rate, Maximum Traffic Burst). These parameters say to
> describe in the uplink the policing needing to be done by the SS and in the
> DL the policing needing done by the network.
> In the UL, is there a need for the SS to do this policing? The BS scheduler
> sets the transmission allowance, so why should a SS police?
>
> I can see a use for similar parameters as described in these chapters, but
> then in a system in which the BS limits the maximum data rate transmission
> to the SS for the case where the SS is limited in its output data rate. So:
> if the SS MAC can only transmit to the user x bps and has a memory limit y,
> the BS from this could shape the traffic to the SS in order to not overflow
> the SS memory requirements. This might impose some larger queuing on the BS,
> but this can be vendor implemented.
>
> As I see it, the maximum traffic burst (11.13.7) would only have any use if
> the egress link speed on the SS (from the MAC to the end user) is given and
> lower than the airlink speed, allowing for a shaping such as described
> above.
>
> The 11.13.14 (Maximum Latency) parameter seems to be an additional input to
> a shaped connection only, so that I can define where I have to be within the
> min and max rate to achieve the latency target. On the other hand, this
> could conflict with the burst parameter, because we would need to
> potentially exceed a burst limit and sustained traffic rate to achieve a
> given latency. Anybody has any thoughts on this?
>
> On 11.3.8 (Minimum reserved traffic rate), is there a mechanism described
> for the case of overbooking (all links have traffic to transmit, the
> aggregate available traffic is beyond the available BW)? Should all traffic
> then be derated proportionally to fit into the available BW? Or is this
> vendor defined?
>
> On 11.3.9 (Minimum tolerable traffic rate), the section as a whole and the
> definition of T is confusing. Should T be a vendor defined "fixed" sliding
> window? If not, how is T defined? Isn't this parameter really only a
> watchdog value that is a different expression for maximum latency? I don't
> see how this could be used to realistically define shaping, because you
> cannot be clairvoyant about your ingress queue's future to make sure the
> traffic distribution fulfills this minimum tolerable requirement? As I said,
> very confusing ....
>
> Thanks,
>
> Steve