[Ns-bugs] [Bug 555] DCF immediate access bug

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=555





--- Comment #3 from TimoB <timo.bingmann at student.kit.edu>  2009-05-11 11:09:13 EDT ---
Okay, the situation is even more complex than I thought.

I've extended DcfManagerTest to pinpoint the bug. To do that I had to add alot
of code, because DcfManagerTest didnt perform a backoff for successful
transmission. So that added could write the test case for the bug:

  // Test case where two packets are queued at DcaTxop, the first send starts
  // immediately and the second is also immediately indicated but has to wait
  // for its backoff.
  //
  //  20          60     66      70   80
  //   | tx        | sifs | aifs  | tx |
  //   |20: request access for both packets

Where the backoff of the second tx is 0. In original ns-3-dev, this test yields
a collision for the second tx at 20, where no collision should be indicated,
because the medium is busy from the first tx.

The DcfManagerTest patch contains a second test case with backoff=2 which
doesnt throw a collision, to highlight the problem with =0.

The patch I previously submitted creates more problems than fixes.

I've added a new patch, which adds a bool m_backoffElapsed to DcfState. I have
not found a way to do it without a new attribute. With the new patch the added
test cases pass ok.

See below about the simulator start.

(In reply to comment #2)
> > 
> > Furthermore, immediate medium access should be possible at simulator start,
> > because all backoffs should be regarded as elapsed. This is easily fixed by
> > setting negative start times.
> 
> This is really an arbitrary decision and I don't believe it matters in any way
> so, if I had to choose between the current behavior and the new behavior, I
> would pick the one which minimizes the number of changes to the code. Either
> way, you really have to leave this change out of what you describe as a more
> real bug for 2 subsequent unacked frames.

Yes, it is independent from the first issue. Of course "no changes" are always
the mimimum number of changes :). It's not really an arbitrary decision to make
simulator start a special point in time for backoff management.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.