[Ns-developers] Preliminary release of NS-3 WiMAX module

[Jahanzeb Farooq]

Hi Mathieu,
> I was not very clear but, from the point of view of merging your work
> later in ns-3, neither a) not c) are acceptable. i.e., both of these
> solutions will introduce ugly history in our tree and will increase the
> size of our tree history by large amounts. So, if you are willing to
> forget your history, go with b). If you do not want to lose it, you will
> have to re-create a clean history by replaying all your changesets in a
> clean tree and making sure you do not replay the changesets which
> contain all the unwanted files you checked in by mistake. i.e., you are
> going to deal with a lot of scripting pain. You might want to look at
> the "convert" extension of mercurial (again, make sure you have the
> latest version of mercurial if you want to use this)

Okay following your option b) I have merged my work to a clean copy of
ns-3-dev again and have uploaded the new repository at:

http://freehg.org/u/jfarooq/ns-3-wimax/

I hope it will work this time. As a result I have lost my history,
however it seems it was inevitable at this point. 

> These are unstable development versions. Is there a stable release of
> itpp  which we can use ?

Actually I really don't know this. The time I plugged in the OFDM PHY
first I tried to use the latest stable version but it did not work (I
can't recall which version was it) and then on the instruction by Fabio
I used the above development version.

> > 7) It would be really helpful to know what your TODO is over the next
> > > couple of months: it is hard, as-is, to figure out what is really just
> > > code waiting to be implemented shortly and what is ignored because you
> > > don't care about modelizing it. The end of README attempts to answer
> > > that question but it would be very helpful to have a more detailed plan
> > > of action about what you want to do. For example, the README seems to
> > > imply that scheduling will be implemented before the dynamic creation
> > > and management of service flows which seems really backward: I would
> > > have expected the latter to be implemented first properly with a very
> > > stupid scheduler.
> > 
> > May be you did not get it right here or may be I was not clear. It did
> > not mean the scheduler but the scheduling services (BE, UGS, rtPS,
> > nrtPS). As much I understand its implementation is not really dependant
> 
> What do you mean by "scheduling services" ? Can you outline what this
> is ?

Scheduling services are "data handling mechanisms" as the specification
refers it. Each connection is associated to a scheduling service which
in turn is associated to a set of QoS parameters by the means of service
flow. The traffic with different scheduling services (or the QoS
parameters) are treated differently mainly in how the bandwidth is
requested, granted and reserved for a scheduling service. 
This is how I understand it. I understand your point also that the
service flow mechanism shall be implemented first in order to implement
the scheduling services. My point was that to start with the scheduling
services could be implemented without service flows, i.e., making some
assumptions about the QoS requirements and associating them explicitly
with connections instead of service flows. And then later on service
flow mechanism could be added. However I am not completely sure about it
as I have yet to make a design before I start work on it.


-
Jahanzeb