Re: [STDS-802-16] Problems with incremental bandwidth request header?
We would work on the contribution related to
this topic and will share with you for review.
We will look at how to bring about consistency
in interpretation of service flow parameters and uplink
scheduling situations between SS and BS.
This may take some time. In case there is existing information
(meeting minutes etc.) that can be used for this contribution, it is
welcome.
Also, in case anyone would like to join this effort for contribution,
that is
welcome as well.
Regards,
Kaushik
Lei Wang wrote:
> Kalash,
>
> Please see my follow-up response below.
>
> Regards,
>
> Lei
>
> -----Original Message-----
> From: Kalash [mailto:kalash.kuhasa@gmail.com]
> Sent: Wednesday, April 13, 2005 9:45 AM
> To: STDS-802-16@LISTSERV.IEEE.ORG
> Subject: Re: [STDS-802-16] Problems with incremental bandwidth request
> header?
>
> HI Lei,
>
> Thanks for the detailed reply.
>
> I still do not understand why a core component like the behaviour of
>
> the request/grant state machine is left to implementations. There are
>
> too many items that are vendor-dependent which can result in both
>
> interoperability as well as bandwidth inefficiency.
>
> <Lei Wang> I think this is similar to the MAC scheduler, for which the
> group decided not to standardize it. Also, other IEEE groups made the
> same choice. If you believe the request/grant state machines have to
> be standardized, then I think what you need to do is to bring in a
> contribution and convince the group this is the right thing to do.
> Personally, I will be happy to review your proposal.
>
> I understand that the whole purpose of not including the feedback
>
> about which requests are under consideration by BS (DOCSIS calls these
>
> grant pending IEs) to save precious airtime. How ever, different
>
> aspects that have been left out of the specification - like which
>
> timers can be cancelled out or how much bandwidth can be requested by
>
> the connections or how the SS should handle the corner cases - these
>
> will cause bandwidth inefficiencies. And as Kaushik pointed out, this
>
> can result in very interesting (mildly put) interoperability issues.
>
> <Lei Wang> There could be something missing/incomplete in the current
> spec. Typical example is the Table 342. If you find any specific
> errors/issues, please submit your comments with suggested remedies to
> the group through Cor1 and/or 16e.
>
> As for your question about why a connection would not make a piggyback
>
> request instead of a contention request:
>
> A piggyback request can only be tagged if a connection is sending out
>
> an MPDU - I understand you cannot tag a piggyback request for a
>
> different connection. <Lei Wang> This is not correct. There are two
> types of piggyback bandwidth requests: one is piggyback onto a MAC PDU
> by using the Grant Management (GM) subheader, the other is piggyback
> onto a UL transmission by using bandwidth request MAC header. With the
> GM subheader, you cannot request bandwidth for other connections other
> than the data payload belongs to. However, you can signal the BS to
> poll you. With the Bandwidth request MAC header, you can request
> bandwidth for any other connections. The ideal approach would be for
> the connection
>
> to insert a concatenated bandwidth request header - if it fits. The
>
> question is - assuming that a MPDU for the connection cannot be
>
> scheduled and a bandwidth request header cannot be concatenated,
>
> should the contention resolution have been cancelled when the grant to
>
> SS comes in? <Lei Wang> As mentioned in the previous email, if you
> believe there are cases where you have to use contention-based
> bandwidth requests when there are other connections that are receiving
> UL allocations, you can either cancel the contention resolution
> process or keep doing it. In either cases, it would be a good idea to
> use aggregate bandwidth requests right after that to avoid/correct any
> possible errors.
>
>>From your answer, I understand that you are advocating that the SS
>
> cancel out the timers only after allocations.
>
> The problem with GPSS is that there are two entities making scheduling
>
> decisions - BS and SS. And, it is like both of them are blind <Lei
> Wang> cannot agree with you on this. Actually, it is opposite, i.e.,
> both sides know what’s going on.- BS
>
> knows initially how much bandwidth different connections of SS require
>
> but once it starts allocating any bandwidth, there is no feedback to
>
> the SS of the BS intentions. Similarly, there is no directives in the
>
> specification on how the SS can interpret the allocations from the BS.
>
> Sure, there are aggregate requests to re-sync SS view with BS - but
>
> remember that at small frame durations with maximium MAP relevance,
>
> the bandwidth requests and grants may be overlapped - that means the
>
> SS may be making an aggregate request while the BS may be granting for
>
> the remaining portion of the previous request. <Lei Wang> I hope we
> are talking about the same aggregate bandwidth request mechanism. With
> the current aggregate mechanism, there is no such an overlapping
> problem as you described. The only time the
>
> self-correction would end this ambiguity is when "none" of the
>
> connections of the SS have any more data to send - till then, both
>
> sides have a foggy idea about the allocations/requests from the other
>
> end.
>
> I did not understand your answer about setting the PM bit in multiple
>
> UGS MPDUs: when a BS receives a UGS MPDU with PM bit set, it has no
>
> idea of how many connections of the SS are requesting a bandwidth
>
> poll. It knows that at least one connection is - it may be more.
>
> Hence, if multiple UGS MPDUs have the PM bit set, does it mean that
>
> the SS is requesting that many bandwidth polls or is it trying to
>
> ensure that BS gets the indication - the question I really should ask
>
> is: Is the PM bit a boolean flag requesting a bandwidth poll directed
>
> at the SS (multiple PM bit MPDUs result in one bandwidth poll) or is
>
> it an accumulation (multiple PM bit MPDUs result in multiple bandwidth
>
> polls)? <Lei Wang> It is up to the implementations, in my opinion. The
> simple way is to use it as Boolean.
>
> I think that one of the biggest advantages of GPSS approach is the
>
> providing the SS with the ability to re-schedule the allocations from
>
> BS. I would like to believe that this was the reason for choosing GPSS
>
> over GPC (and not just saving airtime for GPC grants). Considering
>
> this feature, the rest of the request grant mechanism should specify
>
> the behavior of SS/BS when SS reschedules the bandwidth itself.
>
> <Lei Wang> What you said here is only one of the big advantages. There
> are more, e.g., save the UL MAP cost due to requiring less UL MAP IEs.
> Remember that the MAP message is very expensive with respect to the
> air link time, because it needs to be transmitted in the most robust rate.
>
> I have worked extensively (and not just theoretically) on bandwidth
>
> management and large scale fragmentation scenarios for DOCSIS systems.
>
> The fragmentation problem is one of the most debilitating if the BS
>
> cannot control the process. It is not such a major problem in the
>
> downlink because the SS is receiving only some of the fragments and
>
> hence the memory requirements are small. But for a BS supporting
>
> hundreds of SS with multiple connections, the number of outstanding
>
> fragments quickly becomes problematic. And worse yet, the BS has no
>
> control on how to control the fragmentation.
>
> <Lei Wang> I understand the fragmentation related complexity and
> resource requirements. However, I don’t understand a working BS has no
> control on how to control the fragmentation.
>
> I think I understand what has been bugging me: why is the piggyback
>
> request only incremental? Why cannot it be aggregate? Aggregate
>
> requests provide the same (if not far better) view of the bandwidth
>
> requirements of the connection to the BS. I would like to suggest that
>
> the piggyback request be changed from having a 16-bit BR field to a 1
>
> bit aggregate/incremental indicator and a 15-bit BR. This will allow
>
> the SS to make an aggregate bandwidth request to the BS.
>
> <Lei Wang> It seems a good idea to me. Well, you only have wrap-up
> space of 32K, for the aggregate.
>
> Would there be any reason why the piggyback request cannot be aggreate
>
> - the specification makes no comments on why this has to be
>
> incremental only. Is the concern that the 16-bits in the piggyback
>
> request are not enough for the bytes pending for the connection? If
>
> that is the case, the SS can always fall back to using concatenated
>
> (or a contention) bandwidth request header which allows up to 19-bits
>
> (or up to 512 KBytes).
>
> Thanks again for the details - I really hope that the self-correcting
>
> nature of GPSS mechanism works out in the end.
>
> Kalash
>
> On 4/13/05, Kaushik V Shah <kaushik@ncoretech.com> wrote:
>
>> Thank you Lei for some insights on these issues.
>
>>
>
>> Question I have is - how is "system" efficiency to be maximized with
>
>> such openness.
>
>>
>
>> Is there an inherent assumption here that any vendor will provide whole
>
>> system
>
>> i.e. both SS and BS together (and also that any service provider will
>
>> buy the system)?
>
>> OR that there are a set of compatible ways of doing these things that
>
>> are intuitive and
>
>> common sense approaches that will work.
>
>>
>
>> Another question, may be this is for WiMAX forum, but how will the
>
>> performance be certified?
>
>> i.e. can a SS and/or BS fail certification due to performance
> inefficiency?
>
>>
>
>> Regards,
>
>> Kaushik
>
>>
>
>> Lei Wang wrote:
>
>>
>
>> > Kalash and others,
>
>> >
>
>> > First, welcome to 802.16, Kalash and all other DOCSIS friends. Please
>
>> > see my response to your questions embedded in your email below.
>
>> >
>
>> > Once again, this topic had been discussed intensively inside 802.16
>
>> > for quite a long time, and finally about two years ago, the group
>
>> > reached consensus.
>
>> >
>
>> > Regards,
>
>> >
>
>> > Lei
>
>> >
>
>> > -----Original Message-----
>
>> > From: Kalash [mailto:kalash.kuhasa@gmail.com]
>
>> > Sent: Tuesday, April 12, 2005 12:45 AM
>
>> > To: STDS-802-16@LISTSERV.IEEE.ORG
>
>> > Subject: [STDS-802-16] Problems with incremental bandwidth request
> header?
>
>> >
>
>> > Hi all,
>
>> >
>
>> > I come from the DOCSIS side of the world and am still trying to figure
>
>> >
>
>> > out the GPSS (grant per SS) in 802.16 vs GPC(grant per connection) in
>
>> >
>
>> > DOCSIS.
>
>> >
>
>> > I do understand the advantages of GPSS but I feel that the lack of
>
>> >
>
>> > feedback from BS regarding the bandwidth requests received by it
>
>> >
>
>> > and/or being processed by it can cause a lot of interesting scenarios.
>
>> >
>
>> > In GPC (DOCSIS), the resolution to most (if not all) these scenarios
>
>> >
>
>> > is a clear cut answer - no interpretations.
>
>> >
>
>> > I have the following questions - would appreciate if someone would
>
>> >
>
>> > attempt to answer:
>
>> >
>
>> > 1. If two connections of an SS make a bandwidth request uplink and BS
>
>> >
>
>> > sends a grant to the SS, should the request timers of both the
>
>> >
>
>> > requests be cancelled?
>
>> >
>
>> > <Lei Wang> This is one of the fundamental issues you have to solve to
>
>> > make GPSS work. There are many solutions. It depends on the
>
>> > implementations. For example, one of the solutions can be that the SS
>
>> > cancel the timer for the connection for which the current grant is
>
>> > used, and then reset the timer for the other connection.
>
>> >
>
>> > 2. If a connection was waiting for contention resolution process to
>
>> >
>
>> > complete when a grant to SS comes in, should it also cancel out
>
>> >
>
>> > contention resolution?
>
>> >
>
>> > <Lei Wang> I have a question first about this one: when an SS has
>
>> > multiple active connections and get UL grants, why not use piggyback
>
>> > bandwidth requesting mechanism, why still use contention-based
>
>> > bandwidth requesting? Ok, even if the described scenario is realistic,
>
>> > then my answer to your question is yes, it should cancel the
>
>> > contention resolution, instead use piggyback bandwidth request on the
>
>> > UL grant for finish the bandwidth request that was in the contention
>
>> > resolution. Also, use aggregate bandwidth request to do the
>
>> > self-correction on any possible out-of-sync errors in this process.
>
>> >
>
>> > 3. How would a connection calculate the number of bytes to request in
>
>> >
>
>> > an incremental bandwidth request? The grant is to the SS and hence the
>
>> >
>
>> > SS has no idea if the grant was made to the connection that actually
>
>> >
>
>> > uses it or not. Hence, there is no way that the SS can make an
>
>> >
>
>> > estimation of how much incremental request is to be made. <Lei Wang>
>
>> > The grant is for SS, but the SS has full knowledge of the distribution
>
>> > of the grant to its multiple connections. The SS definitely know how
>
>> > many bytes allocated to those connections. Consider the
>
>> >
>
>> > following example where incremental request makes perfect sense:
>
>> >
>
>> > Last Aggregate request from connection 1: L1 = 1000 bytes
>
>> >
>
>> > Connection 1 has another 300 bytes of SDUs arriving, so total pending
>
>> >
>
>> > bytes = 1300 bytes
>
>> >
>
>> > Grant to SS: G = 500 bytes
>
>> >
>
>> > Allocated to connection 1: A1 = 500 bytes
>
>> >
>
>> > Pending bytes for connection 1: P1 = 1300 - 500 = 800 bytes
>
>> >
>
>> > Now incremntal request would be: I1 = P1 - (L1 - A1) = 800 - (1000 -
>
>> >
>
>> > 500) = 300 bytes
>
>> >
>
>> > But consider the following example where it does not:
>
>> >
>
>> > Assume 2 connections for the SS with connection 1 higher priority than
>
>> >
>
>> > connection 2.
>
>> >
>
>> > Last Aggregate request from connection 1: L1 = 100 bytes
>
>> >
>
>> > Last Aggregate request from connection 2: L1 = 600 bytes
>
>> >
>
>> > Connection 1 has another 800 bytes of SDUs arriving, so total pending
>
>> >
>
>> > bytes = 900 bytes
>
>> >
>
>> > Grant to SS: G = 500 bytes
>
>> >
>
>> > Allocated to connection 1: A1 = 500 bytes
>
>> >
>
>> > Pending bytes for connection 1: P1 = 900 - 500 = 400 bytes
>
>> >
>
>> > Now incremntal request can be either:
>
>> >
>
>> > I1 = P1 - (L1 - A1) = 400 - (100 - 500) = 800 bytes
>
>> >
>
>> > or
>
>> >
>
>> > I1 = P1 = 400 = 400 bytes
>
>> >
>
>> > What should be the incremental piggyback request for connection 1?
>
>> >
>
>> > Should it be 800 bytes? Or should it be 400 bytes?
>
>> >
>
>> > Why is this not clarified in the 802.16 specification?
>
>> >
>
>> > <Lei Wang> This is another important issue you have to solve to make
>
>> > the GPSS work. First of all, you have to make your design decision
>
>> > about whether or not you allow such a bandwidth re-distribution at SS,
>
>> > i.e., allow the connection-1 to use more than its current requested
>
>> > bandwidth. If not, what you described won't exist. If yes, then you
>
>> > have to solve the described problem. Again, there are many possible
>
>> > solutions. One simple solution is to send aggregate bandwidth requests
>
>> > for both connection-1 and connection-2.
>
>> >
>
>> > 4. If BS received multiple UGS MPDUs (say 3 MPDUs) with PM bit set,
>
>> >
>
>> > should it grant 3 bandwidth request polls or just one?
>
>> >
>
>> > <Lei Wang> This is a implementation detail issue. Remember the
>
>> > bandwidth requests is still on connection basis. If three connections
>
>> > need to be polled, i.e., need to send bandwidth requests, the BS can
>
>> > either allocate one UL transmission big enough to accommodate three
>
>> > bandwidth requests, or three UL transmission, one for each bandwidth
>
>> > request. I would say the former one is smarter. Well, again, it is
>
>> > your implementation choice.
>
>> >
>
>> > 5. Assume that the BS cannot allocate bandwidth to the bandwidth
>
>> >
>
>> > request sent by a SS' connection because link is congested. Must the
>
>> >
>
>> > BS drop the request after T16 timer? There is no indication that the
>
>> >
>
>> > BS can provide the SS that its request has been received and is being
>
>> >
>
>> > processed.
>
>> >
>
>> > <Lei Wang> I don't think GPSS causes this problem. This one applies to
>
>> > GPC too. This is the question regarding hand-shaking like bandwidth
>
>> > request/grant mechanism vs. self-correction bandwidth request/grand
>
>> > mechanism. I think this had also been discussed very intensively in
>
>> > 802.16 group. The group consensus is the self-correction mechanism.
>
>> > The indication mechanism you asked is basically hand-shaking like,
>
>> > there are multiple cons with it, e.g., sending indication needs air
>
>> > link bandwidth, also, it could be lost too, then you still need a
>
>> > timer to deal with the possible error conditions, … Well, with
>
>> > self-correction mechanism, in case the BS and the SS is out-of-sync
>
>> > for the bandwidth request/grant, e.g., SS sends duplicate request
>
>> > because the BS did not drop the previous due to time-out, those errors
>
>> > can be easily corrected by using aggregate bandwidth request,
>
>> > periodically. Very low cost, and very efficient.
>
>> >
>
>> > 6. SS can start fragmentation on its own while dividing the allocated
>
>> >
>
>> > SS grants to its connections even though BS may not have intended to
>
>> >
>
>> > start the fragmentation for the connection. This can result in
>
>> >
>
>> > unwanted and uncontrolled fragmentation.
>
>> >
>
>> > I have been involved in fragmentation reassembly on DOCSIS CMTSes and
>
>> >
>
>> > this particular point more than any before is a major concern for the
>
>> >
>
>> > BS. BS must have a way to control the fragmentation of the SDUs coming
>
>> >
>
>> > in from the SS - if not BS will either have to load up a lot of memory
>
>> >
>
>> > for the fragment reassembly or expect to drop the fragments as its
>
>> >
>
>> > buffers start filing up.
>
>> >
>
>> > <Lei Wang> Yes, there may be unexpected fragmentation caused by
>
>> > allowing SS to decide how to use a bandwidth grant. Why are those
>
>> > uncontrolled? Do you mean BS does not know how to process them? Also,
>
>> > BS actually does not depend on the UL allocation algorithm/knowledge
>
>> > to handle its reassembly part on the receiving side. If
>
>> > fragmentation/reassembly is supported, BS has to be able to the
>
>> > reassembly job. Plus, when the SS is allocating a grant to its
>
>> > connections, the same optimization idea can apply to minimizing the
>
>> > fragmentations.
>
>> >
>
>> > Is there a working group document that delved into the effects of GPSS
>
>> >
>
>> > on request grant state machine scenarios when multiple connections are
>
>> >
>
>> > active on an SS?
>
>> >
>
>> > <Lei Wang> as far as I know, the answer is no. Also, not necessary. If
>
>> > you would like to contribute, I believe there will be people
>
>> > interested in. Finally, we knew GPSS and self-correcting bandwidth
>
>> > request/grant schemes are working solutions, which have been proven by
>
>> > multiple implementations.
>
>> >
>
>> > Thank you
>
>> >
>
>> > Kalash
>
>> >
>
>>
>