Bug 2369

Summary:	DCF and EDCA immediate access scenarios
Product:	ns-3	Reporter:	Tom Henderson <tomh>
Component:	wifi	Assignee:	sebastien.deronne
Status:	RESOLVED FIXED
Severity:	normal	CC:	ns-bugs, rostami
Priority:	P3
Version:	unspecified
Hardware:	All
OS:	All
See Also:	https://www.nsnam.org/bugzilla/show_bug.cgi?id=555 https://www.nsnam.org/bugzilla/show_bug.cgi?id=737 https://www.nsnam.org/bugzilla/show_bug.cgi?id=912 https://www.nsnam.org/bugzilla/show_bug.cgi?id=1465 https://www.nsnam.org/bugzilla/show_bug.cgi?id=1605 https://www.nsnam.org/bugzilla/show_bug.cgi?id=2493
Attachments:	documentation patch from Ali Rostami

Description Tom Henderson 2016-04-07 15:07:09 UTC

This is prompted by a patch submission from Ali Rostami, and also my observations of mesh simulations.

This has been extensively discussed in the past (several years ago) and I considered reopening one of the old bugs but because there are so many, I thought that I'd list them all here and start a new thread to try to resolve this yet again.

see also bugs 555, 737, 912, 1465, and 1605 (they are all related)

The main issue is the following. The standard leaves room for interpretation of whether a backoff should be generated when a frame arrives and the medium has been idle for less than AIFS.

Where this is particularly noticeable is in mesh simulations on regular topologies (bug 1465). mesh nodes that relay a broadcast frame (e.g. ARP request) may collide always, causing ARP to fail and the simulation to fail. It has been suggested that this can be avoided via processing delays (bug 912) but instead, I think that in the situation of relaying a broadcast frame, the arrival should be considered to take place during the "busy" state and a backoff drawn.

So, the proposal is that the medium be considered 'busy' if the medium has not been idle for SIFS + AIFS when the frame arrives, and backoff drawn for that case. In a mesh relay case, this would be the case for forwarded broadcast frames. Immediate access could still take place if the arrival occurs after the channel has been idle for at least SIFS + AIFS.

See attached writeup from WINLAB.

I'm also posting a patch from WINLAB. I'm not sure whether this is the final patch we want for this, but you can get the idea of the change, and also the idea of the number of DCF unit tests that would need to be adjusted.

I propose that we review the DCF unit case ASCII art diagrams in the 'devices-wifi-dcf' suite, and the bug 555 test in 'devices-wifi' test suite, and agree on behavior, and then work on the resulting patch to make the revised test suites pass.

Comment 1 Tom Henderson 2016-04-07 15:07:43 UTC

Created attachment 2376 [details]
documentation

Comment 2 Tom Henderson 2016-04-07 15:09:24 UTC

Created attachment 2377 [details]
patch from Ali Rostami

I edited the test suite code and the patch a bit (after receiving initial patch from Ali Rostami)

Comment 3 sebastien.deronne 2016-04-20 16:54:25 UTC

Could you please point to the part of the standard you are mentioning?

Comment 4 sebastien.deronne 2016-04-24 05:46:13 UTC

Patch looks actually quite ok and might indeed solves some problems such as ARP collisions I also experienced in the past.

Could you generate a patch that does solve the failing tests for when we decide to deliver this?

Comment 5 Tom Henderson 2016-04-25 17:24:53 UTC

(In reply to sebastien.deronne from comment #3)
> Could you please point to the part of the standard you are mentioning?


802.11-2012, sec 9.19.2.3

Comment 6 sebastien.deronne 2016-04-27 15:55:14 UTC

My understanding of the standard is that a backoff should be generated when a frame arrives and the medium has been idle for at least AIFS, I do not find a case where it could be less than AIFS. It might be that I missed something maybe?

Comment 7 Tom Henderson 2016-04-28 14:03:49 UTC

I agree that I couldn't find the specific case "access request arrives, medium is idle, but has been idle for less than AIFS."  Section 9.3.3 covers DCF and 9.19.2.5 the EDCA.  In both cases, it seems clear that if the access request comes in during the "medium busy", backoff is generated, and it seems also the case that immediate access (skipping the backoff) may be invoked if the access request arrives and the medium has been idle for at least EIFS/DIFS/AIFS (and the frame is not a beacon).

However, it seems vague about what to do if the access request arrives during the IFS period, and I agree with the WINLAB proposal (also extending this to DCF) that if access request arrives during the IFS period, treat this as being "conceptually busy" and generate a backoff.  This will result in backoff being generated for the problematic mesh hidden terminal cases since relayed frames will arrive and generate a new access request within this IFS period.

Comment 8 sebastien.deronne 2016-04-30 03:36:01 UTC

Tom, I looked at the Winlab document and their two suggested solutions for this case and the reason why they chose this one looks now ok for me. It would worth to drop a comment in the code (they can include those comments from their document).

I also suggest to clean a bit the patch to have it ready for delivery.

Comment 9 Tom Henderson 2016-04-30 10:19:43 UTC

(In reply to sebastien.deronne from comment #8)
> Tom, I looked at the Winlab document and their two suggested solutions for
> this case and the reason why they chose this one looks now ok for me. It
> would worth to drop a comment in the code (they can include those comments
> from their document).
> 
> I also suggest to clean a bit the patch to have it ready for delivery.

I don't mind to take this and finish it off (update the patch and fix the disabled test cases).

Comment 10 sebastien.deronne 2016-04-30 10:59:02 UTC

(In reply to Tom Henderson from comment #9)
> (In reply to sebastien.deronne from comment #8)
> > Tom, I looked at the Winlab document and their two suggested solutions for
> > this case and the reason why they chose this one looks now ok for me. It
> > would worth to drop a comment in the code (they can include those comments
> > from their document).
> > 
> > I also suggest to clean a bit the patch to have it ready for delivery.
> 
> I don't mind to take this and finish it off (update the patch and fix the
> disabled test cases).

OK, thanks Tom.

Comment 11 sebastien.deronne 2016-06-04 06:56:26 UTC

Once patch is cleaned, it can be pushed.

Comment 12 Ali Rostami 2016-06-10 13:20:02 UTC

(In reply to sebastien.deronne from comment #11)
> Once patch is cleaned, it can be pushed.

I was following the conversation between you and Tom and I was wondering if you are waiting for me to start the clean up. If yes, do you have any specific comments that need to be applied on the patch other than the ones you have already included in thread comments?

Please let me know if anything I can do to move forward with this patch. Thanks.

Comment 13 Tom Henderson 2016-06-10 13:29:05 UTC

(In reply to Ali Rostami from comment #12)
> (In reply to sebastien.deronne from comment #11)
> > Once patch is cleaned, it can be pushed.
> 
> I was following the conversation between you and Tom and I was wondering if
> you are waiting for me to start the clean up. If yes, do you have any
> specific comments that need to be applied on the patch other than the ones
> you have already included in thread comments?
> 
> Please let me know if anything I can do to move forward with this patch.
> Thanks.

Ali, what remains to do are two things, IMO:
1) ensure that the patch is extended to cover both DCF and EDCA
2) for all of the commented out test cases in the DCF tests, update the ASCII art according to expected behavior and then update the test code to match, and make sure there are no surprises

I am tied up with the meeting next week so I can't get to this until week after next, but it is next on my list.  If you or anyone wants to work it between now and then, feel free and let me know.

Comment 14 Tom Henderson 2016-06-10 13:30:13 UTC

Note, I would also accept merging a first patch that handles DCF only and leave the bug open for EDCA, in which case what needs to be done initially is just fix the DCF tests.

Comment 15 Tom Henderson 2016-09-28 00:13:48 UTC

I made some edits to Ali's patch, and committed as changeset 12345:a94d790ef6e5.  I think it handles both DCF and EDCA cases because the main logic is in the DcfManager class.