[Ns-developers] Update on ns-3 802.11n

[Mathieu Lacage]

On Tue, 2010-08-31 at 14:30 +0200, Nicola Baldo wrote:

> The real issue is that the problem is not well defined. The WifiManager 
> API was developed for Rate Adaptation in mind, and with several 
> well-defined use cases (all those WifiMangers that you implemented).

I actually did it that way also with the tx power and preamble thing in
mind. At least, that was the plan from the start. I just never got to
work on this kind of algorithm or implement an existing one (yes, there
is some published stuff).

> Now, we are just talking about a feature request: "it would be nice to 
> have an API for TX power adaptation and preamble adaptation". But, I see 
> no real use case as of now: is anybody interesting in implementing a TX 
> power adaptation algorithm? A preamble adapatation algorithm? I would be 
> glad if somebody were, but so far nobody said that. I am not interested 
> in implementing these algorithms. I wouldn't even know what algorithm to 
> implement, if I were to implement one. An API designed in such a 
> situation is just a guess.

What I would have expected is merely a delegate to the
WifiRemoteStationManager with a default stupid implementation (say, use
the constant you want to put in the PHY) that can be overriden entirely
by subclasses should they want to. Something like the maximum retry
threshold. For tx power, it should be sufficient. For the preamble
thing, it's more tricky because the preamble type should be chosen
depending also on the capabilities of the remote station. The short
preamble is allowed only when the remote side explicitely supports it so
you need to keep track of the supported preambles for each remote.

> >> To summarize my position on the topic, I wonder whether we should avoid
> >> passing TX power and preamble as arguments to WifiPhy::SendPacket(), and
> >> have them as WifiPhy attributes instead.
> >
> > My personal experience is that if you don't take time to do this
> > yourself, none of those with experience in this kind of rate control/tx
> > power adaptation will do it. i.e., the onus of providing a clean API is
> > on the maintainer :)
> 
> I already spent some time coming up with API proposals for the case 

Those proposals were in the bug report, I presume ?

> where all adaptation is done in WifiManager. I just don't like the 
> resulting API, and have strong doubts that people will actually use it. 

This is the old egg or chicken first dilemma...

> That's why I am wondering whether simpler solutions, such as having the 
> TX power and preamble in WifiPhy, might be better.

It is certainly simpler.

Anyway, I don't intend to force the decision in any direction but I
wanted to point out what the original intention was when the code was
written. Again, whether or not you intend to go in that direction is
your call: I don't intend to work on any of that stuff anymore :)

Mathieu