[Ns-bugs] [Bug 737] Backoff procedure is not invoked when transmission is deferred

code@nsnam.ece.gatech.edu code at nsnam.ece.gatech.edu
Fri Feb 26 02:44:02 PST 2010


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





--- Comment #12 from Pavel Boyko <boyko at iitp.ru>  2010-02-26 05:44:01 EDT ---
> My initial reaction to this proposed solution is that it is wrong: we should
> not unconditionally start a backoff after a packet reception: 

  We do not propose to unconditionally start backoff after a packet reception.
We propose to start backoff for _all_ deferred transmissions including the ones
deferred because DIFS is not passed yet (as in the case of
too-fast-forwarding).   

> it goes against both the spirit and the letter of the 802.11 spec.

  I don't think so. Take a look at 9.1.1 of 802.11-2007: "After deferral, or
prior to attempting to transmit again immediately after a  successful
transmission, the STA shall select a random backoff interval and shall
decrement the backoff interval counter while the medium is idle." To understand
that "deferral" means "medium was busy of DIFS wasn't passed" take a look at
Fig. 9.3 ibid: "Defer access interval" = "Medium busy" + "DIFS".

> It seems to me that the problem is not that we need to model processing delays:
> we need to model non-deterministic _varying_ processing delays which change
> from one station to another, and, potentially, from one packet to another
> within the same station, right ? If so, I would support adding a delay in
> MacLow when we receive a packet before forwarding it to the upper layers and
> making that delay be picked from a RandomVariable with a default value of being
> a gaussian distribution centered around 10us with a non-zero value for the
> variance. I will ask a collegue what a decent value would be for the
> mean/variance to model some PC-class hardware.

  Sure you are right that good solution is to start account for processing
delays. But I am very uncomfortable with all ad-hoc solutions in this field.
Why 10 us? Why gaussian (saying nothing about negative delays)? Why "some
PC-class"? Why at wifi/mac-low? What about Ethernet, wimax, and all future
models? 

  I propose to a) apply suggested DCF patch b) start public discussion of
modeling processing delays in ns-3.

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


More information about the Ns-bugs mailing list