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 > > > > > > > >
