Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

Lorenz Minder
Hi,

In a simulation of mine I see that wifi connections are dropped as soon
as any significant load is put on them with ns-3.30;  the same example
works fine in ns-3.29.  Attached below is a reduced test case.

The test case is fairly simple; there is 1 AP and 1 STA, with 20m
between them.  The AP starts sending TCP traffic to the STA 20 seconds
into the simulation.  Typically less than 1s later nothing arrives at
the AP anymore.

The commit that caused this regression is this one:

d6c31ad130abfe1a804310db54b14faa02ad29a4
Author: Stefano Avallone <[hidden email]>
Date:   Fri Apr 19 12:03:25 2019 +0200

     wifi: QosTxop does not return packets outside of the current
transmit window

     Also, make use of the new variants of the WifiMacQueue methods and
     remove unused BlockAckManager methods

Here are a few things that I noticed that may or may not be helpful to
diagnose the problem:
(1) If I reduce the 20m distance between the nodes to 10m it seems to work.
(2) If I replace MinstrelHt by a constant rate station manager, it seems
to work.

Let me know if there is anything else I can do to help diagnose or fix
this problem.  Unfortunately I don't understand the code in question
myself, nor the relevant change.

Best,
--Lorenz

simple_wifi.cc (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

Tom Henderson-2
Lorenz, thanks for reporting the issue.  I've filed #79 on our tracker
for it:
https://gitlab.com/nsnam/ns-3-dev/issues/79

- Tom


On 8/23/19 7:08 PM, Lorenz Minder wrote:

> Hi,
>
> In a simulation of mine I see that wifi connections are dropped as soon
> as any significant load is put on them with ns-3.30;  the same example
> works fine in ns-3.29.  Attached below is a reduced test case.
>
> The test case is fairly simple; there is 1 AP and 1 STA, with 20m
> between them.  The AP starts sending TCP traffic to the STA 20 seconds
> into the simulation.  Typically less than 1s later nothing arrives at
> the AP anymore.
>
> The commit that caused this regression is this one:
>
> d6c31ad130abfe1a804310db54b14faa02ad29a4
> Author: Stefano Avallone <[hidden email]>
> Date:   Fri Apr 19 12:03:25 2019 +0200
>
>      wifi: QosTxop does not return packets outside of the current
> transmit window
>
>      Also, make use of the new variants of the WifiMacQueue methods and
>      remove unused BlockAckManager methods
>
> Here are a few things that I noticed that may or may not be helpful to
> diagnose the problem:
> (1) If I reduce the 20m distance between the nodes to 10m it seems to work.
> (2) If I replace MinstrelHt by a constant rate station manager, it seems
> to work.
>
> Let me know if there is anything else I can do to help diagnose or fix
> this problem.  Unfortunately I don't understand the code in question
> myself, nor the relevant change.
>
> Best,
> --Lorenz
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

Alexander Krotov-2
In reply to this post by Lorenz Minder
I have not looked into it, but it seems like a block ack stalling.

Try to apply this patch:
https://gitlab.com/nsnam/ns-3-dev/merge_requests/76

On 8/23/19 8:08 PM, Lorenz Minder wrote:

> Hi,
>
> In a simulation of mine I see that wifi connections are dropped as soon
> as any significant load is put on them with ns-3.30;  the same example
> works fine in ns-3.29.  Attached below is a reduced test case.
>
> The test case is fairly simple; there is 1 AP and 1 STA, with 20m
> between them.  The AP starts sending TCP traffic to the STA 20 seconds
> into the simulation.  Typically less than 1s later nothing arrives at
> the AP anymore.
>
> The commit that caused this regression is this one:
>
> d6c31ad130abfe1a804310db54b14faa02ad29a4
> Author: Stefano Avallone <[hidden email]>
> Date:   Fri Apr 19 12:03:25 2019 +0200
>
>     wifi: QosTxop does not return packets outside of the current
> transmit window
>
>     Also, make use of the new variants of the WifiMacQueue methods and
>     remove unused BlockAckManager methods
>
> Here are a few things that I noticed that may or may not be helpful to
> diagnose the problem:
> (1) If I reduce the 20m distance between the nodes to 10m it seems to work.
> (2) If I replace MinstrelHt by a constant rate station manager, it seems
> to work.
>
> Let me know if there is anything else I can do to help diagnose or fix
> this problem.  Unfortunately I don't understand the code in question
> myself, nor the relevant change.
>
> Best,
> --Lorenz
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

Lorenz Minder
In reply to this post by Tom Henderson-2
Tom, ok, thanks!  (I'll try using the tracker directly going forward.)

Best,
--Lorenz

On 8/24/19 4:04 AM, Tom Henderson wrote:

> Lorenz, thanks for reporting the issue.  I've filed #79 on our tracker
> for it:
> https://gitlab.com/nsnam/ns-3-dev/issues/79
>
> - Tom
>
>
> On 8/23/19 7:08 PM, Lorenz Minder wrote:
>> Hi,
>>
>> In a simulation of mine I see that wifi connections are dropped as
>> soon as any significant load is put on them with ns-3.30;  the same
>> example works fine in ns-3.29.  Attached below is a reduced test case.
>>
>> The test case is fairly simple; there is 1 AP and 1 STA, with 20m
>> between them.  The AP starts sending TCP traffic to the STA 20 seconds
>> into the simulation.  Typically less than 1s later nothing arrives at
>> the AP anymore.
>>
>> The commit that caused this regression is this one:
>>
>> d6c31ad130abfe1a804310db54b14faa02ad29a4
>> Author: Stefano Avallone <[hidden email]>
>> Date:   Fri Apr 19 12:03:25 2019 +0200
>>
>>      wifi: QosTxop does not return packets outside of the current
>> transmit window
>>
>>      Also, make use of the new variants of the WifiMacQueue methods and
>>      remove unused BlockAckManager methods
>>
>> Here are a few things that I noticed that may or may not be helpful to
>> diagnose the problem:
>> (1) If I reduce the 20m distance between the nodes to 10m it seems to
>> work.
>> (2) If I replace MinstrelHt by a constant rate station manager, it
>> seems to work.
>>
>> Let me know if there is anything else I can do to help diagnose or fix
>> this problem.  Unfortunately I don't understand the code in question
>> myself, nor the relevant change.
>>
>> Best,
>> --Lorenz
Reply | Threaded
Open this post in threaded view
|

Re: Unexpected wifi connection drop in ns-3.30 but not in ns-3.29

Lorenz Minder
In reply to this post by Alexander Krotov-2
Thanks!  That patch does indeed fix this problem for me.  I've added a
note to the bug report to mention this.

Best,
--Lorenz

On 8/25/19 9:14 AM, Alexander Krotov wrote:

> I have not looked into it, but it seems like a block ack stalling.
>
> Try to apply this patch:
> https://gitlab.com/nsnam/ns-3-dev/merge_requests/76
>
> On 8/23/19 8:08 PM, Lorenz Minder wrote:
>> Hi,
>>
>> In a simulation of mine I see that wifi connections are dropped as soon
>> as any significant load is put on them with ns-3.30;  the same example
>> works fine in ns-3.29.  Attached below is a reduced test case.
>>
>> The test case is fairly simple; there is 1 AP and 1 STA, with 20m
>> between them.  The AP starts sending TCP traffic to the STA 20 seconds
>> into the simulation.  Typically less than 1s later nothing arrives at
>> the AP anymore.
>>
>> The commit that caused this regression is this one:
>>
>> d6c31ad130abfe1a804310db54b14faa02ad29a4
>> Author: Stefano Avallone <[hidden email]>
>> Date:   Fri Apr 19 12:03:25 2019 +0200
>>
>>      wifi: QosTxop does not return packets outside of the current
>> transmit window
>>
>>      Also, make use of the new variants of the WifiMacQueue methods and
>>      remove unused BlockAckManager methods
>>
>> Here are a few things that I noticed that may or may not be helpful to
>> diagnose the problem:
>> (1) If I reduce the 20m distance between the nodes to 10m it seems to work.
>> (2) If I replace MinstrelHt by a constant rate station manager, it seems
>> to work.
>>
>> Let me know if there is anything else I can do to help diagnose or fix
>> this problem.  Unfortunately I don't understand the code in question
>> myself, nor the relevant change.
>>
>> Best,
>> --Lorenz