[ns] new 802.11 - CAP proportion too big

[Pedro Fortuna]

Hello Mathieu,
Thanks for replying.

I got things clearer now that I've read a couple of papers about
802.11e. I'm not an 802.11e expert. I think the behavior you
implemented is correct. Flows not accepted by the scheduler must not
use the EDCA slots in the CP, as those are reserved for legacy
(non-802.11e) nodes.

I've been having a problem where I keep getting CAP Proportion error
messages. It would be ok if I was requesting a considerable number of
flows. But no, I get it when I try to request 2 flows. The first flow
is accepted but the second is refused due to CAP Proportion error.
You can replicate it with the attached script. Its a modification of
the test-80211e.tcl. Instead of 3 nodes, it's only 2 nodes.

Can you please run the script and verify if you get the same result?
Thank you!

Best Regards,
Pedro Fortuna
INESC Porto

On 8/14/06, mathieu lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
> hi pedro,
>
> On Fri, 2006-08-11 at 19:53 +0100, Pedro Fortuna wrote:
> > Hello Mathieu,
> >
> > Sorry for bothering you again.  I have a question which might have
> > more to do with the 802.11e standard, but maybe you can enlighten me a
> > bit. Im using your 802.11e implementation in NS2 to setup a scenario
> > where a number of VoIP flows is exchanged between the QAP and a bunch
> > of nodes.
> >
> > Each flow is configured with the exact same TSpec:
> >               # set TSpec
> >               set tspec [new TclTspec]
> >               $tspec set-minimum-service-interval 0.0
> >               $tspec set-maximum-service-interval 0.0
> >               # ms
> >               $tspec set-delay-bound 0.125
> >               # bytes
> >               $tspec set-nominal-msdu-size 80
> >               # bytes per second
> >               $tspec set-mean-data-rate 8000
> >               $tspec set-peak-data-rate 8000
> >
> > But when running the simulation, only the first flows are accepted (1
> > or 2 flows). The subsequent flows are refused due to CAP proportion
> > being too big.
> > I understand that during the CP, the QAP is able to provide TXOP to
> > stations (CAPs), and that the overall number of CAPs shouln't not be
> > over a certain value (0.4 i think). But why such a limited set of
> > flows result in this error? When there aren't enough CAPs to offer,
>
> Are you asking why 0.4 was choosen ? If so, the answer is that it seemed
> like a decent default. Feel free to change it.
>
> > the flows should try to transmit them using regular EDCA contention
> > rules.... I'm not getting this behavior :(
>
> Are you saying that traffics which are not accepted by the scheduler
> should be accepted anyway and fed into EDCA slots ? This sounds
> completely broken or maybe I don't understand what you are suggesting.
>
> thanks for your feedback,
> Mathieu
>
>