[ns] new 802.11 - CAP proportion too big
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, the flows should try to transmit them using regular EDCA contention rules I'm not getting this behavior :( Thank you. -- Best Regards, Pedro Fortuna INESC Porto
Re: [ns] new 802.11 - CAP proportion too big
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 <[EMAIL PROTECTED]> 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
Re: [ns] new 802.11 - CAP proportion too big
On Mon, 2006-08-14 at 17:20 +0100, Pedro Fortuna wrote: > 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? no, I am sorry but I don't have time to do this right now. If you want to debug this, you probably will have to look into the details of the CAP allocation calculations and try to figure out where they are wrong. I remember someone already reported some errors in them but I cannot remember getting patches to fix this and I have not had time to do it myself. Mathieu > Thank you! > > Best Regards, > Pedro Fortuna > INESC Porto > > On 8/14/06, mathieu lacage <[EMAIL PROTECTED]> 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 > > > >
Re: [ns] new 802.11 - CAP proportion too big
I'll do my best trying to find the problem. I'll submit a patch if I succeed correcting it (assuming there's a problem). There is a question on the DCF implementation part I'd like to ask if you don't mind. It seems that there's no Packet Loss. I know 802.11 DCF MAC's is an acknowledged service with up to 7 retransmissions, which eliminates almost every packet loss due to transmission errors. But shouldn't it at least have some packet loss due to limited queue sizes? I have done a simulation where I create 200 nodes exchanging 400 voip flows and although the maximum delay is a lot higher when compared with a 20 or 50 node simulation, it still does not show any packet loss. This suggests that in your implementation you have a very long queue (or infinite size). Is this true? If so, In your opinion, would it be complicated to implement a limited queue size? Thanks, Pedro Fortuna INESC Porto On 8/14/06, mathieu lacage <[EMAIL PROTECTED]> wrote: > On Mon, 2006-08-14 at 17:20 +0100, Pedro Fortuna wrote: > > 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? > > no, I am sorry but I don't have time to do this right now. If you want > to debug this, you probably will have to look into the details of the > CAP allocation calculations and try to figure out where they are wrong. > I remember someone already reported some errors in them but I cannot > remember getting patches to fix this and I have not had time to do it > myself. > > Mathieu > > > Thank you! > > > > Best Regards, > > Pedro Fortuna > > INESC Porto > > > > On 8/14/06, mathieu lacage <[EMAIL PROTECTED]> 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 > > > > > > > >
Re: [ns] new 802.11 - CAP proportion too big
On Mon, 2006-08-14 at 23:54 +0100, Pedro Fortuna wrote: > I'll do my best trying to find the problem. I'll submit a patch if I > succeed correcting it (assuming there's a problem). > > There is a question on the DCF implementation part I'd like to ask if > you don't mind. It seems that there's no Packet Loss. I know 802.11 > DCF MAC's is an acknowledged service with up to 7 retransmissions, > which eliminates almost every packet loss due to transmission errors. > But shouldn't it at least have some packet loss due to limited queue > sizes? > > I have done a simulation where I create 200 nodes exchanging 400 voip > flows and although the maximum delay is a lot higher when compared > with a 20 or 50 node simulation, it still does not show any packet > loss. This suggests that in your implementation you have a very long > queue (or infinite size). Is this true? If so, In your opinion, would > it be complicated to implement a limited queue size? I cannot remember if the queue is size-bound or delay-bound. My curent code (in yans) is both size and delay bound with a default size of 400 packets. The relevant code is located in mac-queue-80211.cc. Mathieu
Re: [ns] new 802.11 - CAP proportion too big
> I cannot remember if the queue is size-bound or delay-bound. My curent
> code (in yans) is both size and delay bound with a default size of 400
> packets. The relevant code is located in mac-queue-80211.cc.
>
> Mathieu
>
"if ((*tmp).second + m_parameters->getMSDULifetime () > now) {"
It's delay bounded, and its limited with the value returned by
function getMSDULifetime, which by default is 10 seconds, which is a
very large value for delay.
I've looked at your Yans code and ported the relevant code to your NS2 branch.
If I may ask, why did you use a queue size limit of 400 packets?
What is the delay limit on queued packets you implemented on Yans?
Thanks.
Best Regards,
Pedro Fortuna
Re: [ns] new 802.11 - CAP proportion too big
On Wed, 2006-09-06 at 01:02 +0100, Pedro Fortuna wrote:
> "if ((*tmp).second + m_parameters->getMSDULifetime () > now) {"
>
> It's delay bounded, and its limited with the value returned by
> function getMSDULifetime, which by default is 10 seconds, which is a
> very large value for delay.
Do you have a better suggestion ?
>
> I've looked at your Yans code and ported the relevant code to your NS2 branch.
> If I may ask, why did you use a queue size limit of 400 packets?
Because this is the max queue size of the linux madwifi driver the last
time I worked on it.
> What is the delay limit on queued packets you implemented on Yans?
10s
Mathieu
--
