From gjcarneiro at gmail.com  Sun Nov  7 15:39:05 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Sun, 7 Nov 2010 23:39:05 +0000
Subject: [Ns-developers] ns-3 modular python bindings
Message-ID: <AANLkTi=pZPBZLRP3xj1hT7z4rF6DZwcEg866nMLBdJ5y@mail.gmail.com>

Hello,

I have begun to work on modular Python bindings.  The work I have so far has
been uploaded to branch gjc/ns-3-modular-bindings:
http://code.nsnam.org/gjc/ns-3-modular-bindings/

A new waf configure option was added: ./waf configure --bindings-type=TYPE,
where type can be "modular", "monolithic" (default), or "both".

A new waf option ./waf --apiscan=MODULE1,MODULE2,..., will scan bindings
just for the specifying modules an place the apidefs in
src/<module-path>/bindings.  The apidefs of a module will have to pull in
partial apidefs of other modules that are used by it, which is unfortunate
but needed to give enough information for pybindgen to generate correct
code.  In runtime, the other modules' types are simply imported, not wrapped
again.

A new Build method is added at runtime to request that bindings for the
current module be added, just call "bld.ns3_python_bindings()" in the module
wscript file, it will figure the rest by context (current wscript path).

The new Python bindings are installed into an 'ns' Python namespace, instead
of ns3.  For instance, "import ns.node".  This will avoid clashes with the
old bindings, in case we want to keep the old bindings for compatibility.

TODO:

  1. This stuff doesn't even build right now, for anyone else but me, due to
circular dependencies between ns-3 modules; I have some quick-and-dirty
patches in my tree, to get it to build, but then it fails again in runtime
for the same reason.  We need to fix circular dependencies, or else modular
bindings have no chance of working and it's not my fault;

  2. In the modular bindings there was custom code for wrapping ns-3
Callbacks, with a callbacks_list.py file holding the list of detected
Callback types.  This stuff wasn't yet replicated in the modular bindings;

  3. In the old bindings, some code was injected in the scanned header file
to force some template instantiations, this is missing for now in the new
bindings;

  4. When a module includes a header of another module, all the types of the
other module are imported by its python module.  Maybe it is possible to
detect which types are actually needed by the current module's bindings and
import just those types; I'll have to check if I have time.


Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

From jens.mittag at kit.edu  Mon Nov  8 00:42:04 2010
From: jens.mittag at kit.edu (Jens Mittag)
Date: Mon, 08 Nov 2010 09:42:04 +0100
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CAFA932.1000900@tomh.org>
References: <4CAFA932.1000900@tomh.org>
Message-ID: <4CD7B7DC.8030506@kit.edu>

Hi all,

I just stumbled across the C-library called C-Pluff, which aims to 
provide a plugin-based framework for C/C++ based applications - similar 
to the OSGi framework used in Eclipse. I know, this goes further than a 
modular build system, and would still need a modular build system, but: 
it has full dependency support and fully loose coupling of modules 
through extension points and extensions. Might be worth a look. I know 
that for example the XBMC project [1] makes use of C-Pluff for their 
addon/plugin system.

Jens

[1] http://www.xbmc.org/

On 09.10.2010 01:28, Tom Henderson wrote:
> We started to discuss the need for a more modular system at our
> developers meeting in Malaga, and since then, Mathieu and I have
> discussed the need to start to address this soon rather than increase
> the pain later. Longer term, we would like to move to a system that
> relies more on separate modules for simulation models, including a
> package management system for managing (fetching, building,
> managing dependencies) models and libraries maintained by others.
>
> The first step in this process, we believe, is to start to take
> our existing monolithic library and split it into modules. For
> instance, find some piece of our existing system and build it as a
> separate library. Even taking an initial step such as with a device
> with few external dependencies (e.g. src/devices/uan) will immediately
> present some issues such as with bindings, the test framework, etc.
> that we will need to address. Eventually we'll have to move to modules
> with more dependencies (e.g. WiFi) and the simulation core itself.
>
> Once we have a modular system, or in parallel, we can start to look
> at how to manage simulation modules from a package management system
> perspective, especially to consider modules that might start to be
> maintained by an external research group. Here, we plan to study
> and adapt the workflows and possibly code of existing systems (e.g.
> jhbuild and Debian package system); if people have other suggestions
> that might fit, please let us know.
>
> We previously started a page [1] to track the proposed design and
> schedule for changes (hopefully this is something that we can address
> the remainder of the year and start to put into place after the next
> release), and we plan to discuss issues as they arise on ns-developers.
> If other developers want to pitch in, please let us know.
>
> There will be a bit of inconvenience once we start to transition but it
> seems to be unavoidable for the future maintainability and we should
> start to see improvements along the way (e.g. shorter build times for
> typical usage).
>
> - Tom
>
> [1] http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements


-- 
Dipl.-Inform. Jens Mittag
Karlsruhe Institute of Technology (KIT)
Institute of Telematics
Decentralized Systems and Network Services Research Group

Zirkel 1, 76131 Karlsruhe, Germany
Building 20.20, Room 356.1

Phone: +49 (721) 608 5768
Fax:   +49 (721) 608 6789

http://dsn.tm.uni-karlsruhe.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5833 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20101108/00e84772/smime.bin

From cabreu at vialink.com.br  Sun Nov  7 12:16:54 2010
From: cabreu at vialink.com.br (=?iso-8859-1?Q?Claudio_S=E1_de_Abreu?=)
Date: Sun, 7 Nov 2010 18:16:54 -0200
Subject: [Ns-developers] Tcp header and SACK
Message-ID: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>

Hi,

I and some colleagues are working in the implementation of tcp-sack on ns-3. To do it, it is necessary to use the tcp-options field of tcp header, but this field is not implemented on tcp-header class. I'm using the ns-3-tcp founded in http://code.nsnam.org/adrian/ns-3-tcp which uses a new tcp structure, and have yet implemented tcp-tahoe, tcp-reno and tcp-newreno. The next natural implementations is the tcp-sack.

We think that before try to implement tcp-sack, We need to include the tcp header options in the tcp header structure, and the respective methods to put/get data into this. Our plan is to do the follow steps:

- Fix the data treatment of data offset of TcpHeader (GetLength and SetLength) - only the left 4 bits may be used
- Create a type to enclose ONE option: tcp-option.h / tcp-option.cc
- Create a new array of options in tcp-header.h
- Implement the get/set of this options in Serialize and Deserialize methods of TcpHeader
- Verify if the checksum calculus is working well after this modifications
- Create methods to get options data based on his index
- Create methods to read the index arrays of SACK packets;

- New type TcpOption:
  uint8_t Number;
  uint8_t Length;
  Buffer OptionData;  Construtor receiving the Number (without buffer);
  Construtor receiving the Number and the Buffer;
  Serialize and Deserialize methods, which will be used inside TcpHeader::Serialize and TcpHeader::Deserialize

- New type SackTcpOption inherited of TcpOption:
  uint8_t GetNumBlocks(); (Returns (Length - 2) / 8);
  GetBlock(uint8_t nBlock, uint32_t &start, uint32_t &end);
  AddBlock(uint32_t start, uint32_t end);

After do this, we need:

- Test and fix all tcp header calls in ns-3
- Test and fix all simulations examples

Are we in the correct path?

Tks.

Claudio S? de Abreu
Diretor
55 21 9119-5644
cabreu at vialink.com.br



Rua Dr. Anibal Moreira, 40 | Tijuca
Rio de Janeiro, RJ | Brasil | CEP: 20510-110
55 21 3294-2900
www.vialink.com.br


From huanzhongli at gmail.com  Sun Nov  7 15:27:05 2010
From: huanzhongli at gmail.com (huanzhongli huanzhongli)
Date: Sun, 7 Nov 2010 18:27:05 -0500
Subject: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
Message-ID: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>

Hi all,

I find a fatal bug in
ns-allinone-2.35-RC7<http://www.isi.edu/nsnam/dist/release/ns-allinone-2.35-RC7.tar.gz>
.
I install it in cygwin and it works well.
But after I add a new agent and recompile it, ns can not start anymore.
It shows the following error information:

[code omitted because of length]
: invalid command name "?-*-"
    while executing
"?-*-    Mode:tcl"

This is caused by the Tcl scripts ns-packet.tcl in the folder
ns-2.35\tcl\lib.
There is two unknown bytes 0XFF 0XFE at the beginning of the file.
I delete these two bytes, and then the bug is fixed.

Good luck to all :-)

Huanzhong

From adrian at ieaa.org  Mon Nov  8 09:43:55 2010
From: adrian at ieaa.org (Adrian Sai-Wah TAM)
Date: Mon, 8 Nov 2010 12:43:55 -0500
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>
References: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>
Message-ID: <AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>

Hi Claudio,

> We think that before try to implement tcp-sack, We need to include the tcp header options in the tcp header structure, and the respective methods to put/get data into this. Our plan is to do the follow steps:
>
> - Fix the data treatment of data offset of TcpHeader (GetLength and SetLength) - only the left 4 bits may be used
> - Create a type to enclose ONE option: tcp-option.h / tcp-option.cc
> - Create a new array of options in tcp-header.h
> - Implement the get/set of this options in Serialize and Deserialize methods of TcpHeader
> - Verify if the checksum calculus is working well after this modifications
> - Create methods to get options data based on his index
> - Create methods to read the index arrays of SACK packets;

I've thought of implementing TCP options, as there are quite a number
of useful ones that should be implemented in NS3 but not yet. I think
your approach above is exactly what in my mind but beware of one
thing: I spotted a few instances (I forget where now) in the NS3 code
that hard-coded the TCP header length to be 20 bytes. That needs to be
changed definitely.

I would like to raise another issue to everyone in
ns-developers at isi.edu: I found that, in case you are not using NSC in
NS3, having a bunch of serialize/deserialize is very inefficient. In a
future release, I would like to see the serialization/deserialization
are done only when necessary, e.g. writing to a pcap file. At other
times, we hold a vector of packet components (headers, trailers, and
payload) for fast read/write and we can also support new operations
such as retrieving a particular header in the middle of the packet,
without a series of push/pop operations. Moreover, we can test for the
type of each header (currently, it is perfectly legal to retrieve a
TCP header as IP header, both of 20 bytes). I did a test drive on this
approach and found a significant performance improvement in the
expense of very moderate memory usage.

- Adrian.

From mathieu.lacage at gmail.com  Tue Nov  9 01:58:20 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Tue, 9 Nov 2010 10:58:20 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>
References: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>
	<AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>
Message-ID: <AANLkTi=BCyrcY-feZA1ChA1mT40_6+ONm7pQixZOUSZZ@mail.gmail.com>

On Mon, Nov 8, 2010 at 18:43, Adrian Sai-Wah TAM <adrian at ieaa.org> wrote:
> I would like to raise another issue to everyone in
> ns-developers at isi.edu: I found that, in case you are not using NSC in
> NS3, having a bunch of serialize/deserialize is very inefficient. In a
> future release, I would like to see the serialization/deserialization
> are done only when necessary, e.g. writing to a pcap file. At other
> times, we hold a vector of packet components (headers, trailers, and
> payload) for fast read/write and we can also support new operations
> such as retrieving a particular header in the middle of the packet,
> without a series of push/pop operations. Moreover, we can test for the
> type of each header (currently, it is perfectly legal to retrieve a
> TCP header as IP header, both of 20 bytes). I did a test drive on this

You raise different issues here so, let me try to answer them separately:

1) performance: I don't believe you can go really faster (there are
some things you could do but the added implementation complexity might
offset any gains from being smarter) and if you can, I would love to
see the code and benchmarks. i.e., see
http://www-sop.inria.fr/members/Mathieu.Lacage/thesis.pdf (chapter 3)
for a detailed discussion of various design options and their
performance. I would be happy to publish the associated benchmark code
if you need it and I would be more than happy to be proven wrong :)

2) retrieving a header in the middle: we don't support this on purpose
to make sure that whatever code you write in ns-3 will work
transparently in emulation mode so, I will nack any patch that adds
this capability.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>

From mathieu.lacage at gmail.com  Tue Nov  9 02:28:08 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Tue, 9 Nov 2010 11:28:08 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <8AD0C5E5-25DD-46B0-985B-17249EDB6DD2@vialink.com.br>
References: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>
	<AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>
	<AANLkTi=BCyrcY-feZA1ChA1mT40_6+ONm7pQixZOUSZZ@mail.gmail.com>
	<8AD0C5E5-25DD-46B0-985B-17249EDB6DD2@vialink.com.br>
Message-ID: <AANLkTikvRxHDRjahK_FJUyeBQHwihCxPOiDOFcFEP3W6@mail.gmail.com>

On Tue, Nov 9, 2010 at 11:22, Claudio S? de Abreu <cabreu at vialink.com.br>wrote:

> I don's understand. ns-3 don't have a full tcp header implemented, missing
> tcp options and making wrong treatment of data offset. Because of this, any
> kid of tcp flavor that uses tcp options may not be implemented unless we do
> a work around inside the specific class that implements, for exemple,
> tcp-sack  (like ns-2). Speaking about emulation mode, all great Operating
> Systems (Linux, Windows, Mac OS X), uses tcp-sack as default to have
> performance improvement in communications when we have some packet loss or
> when the packets arrive in wrong order. If ns-3 is not able to emulate sack,
> for exemple, we never will be capable to really make any correct
> consideration about performance in real world.
>

Yes, I think that it's a great idea to add tcp option support to the ns-3
tcp header but my point was that I would nack any patch that attempts to
allow someone to read a header in the middle of a packet without calling
RemoveHeader as many times as needed to peel off external headers.


> I don't have problems with the serialize/deserialize methods, but I think
> that the best way do make header operations is to have a class that
> implements the full header specification, and methods to get/put each header
> field, including tcp-options, of course.
>

We are in violent agreement here.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>

From L.Wood at surrey.ac.uk  Tue Nov  9 02:39:58 2010
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 9 Nov 2010 10:39:58 +0000
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTikvRxHDRjahK_FJUyeBQHwihCxPOiDOFcFEP3W6@mail.gmail.com>
References: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>
	<AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>
	<AANLkTi=BCyrcY-feZA1ChA1mT40_6+ONm7pQixZOUSZZ@mail.gmail.com>
	<8AD0C5E5-25DD-46B0-985B-17249EDB6DD2@vialink.com.br>
	<AANLkTikvRxHDRjahK_FJUyeBQHwihCxPOiDOFcFEP3W6@mail.gmail.com>
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC921F@EXMB01CMS.surrey.ac.uk>

 
> my point was that I would nack any patch that attempts to allow someone to read
> a header in the middle of a packet without calling RemoveHeader as many times
> as needed to peel off external headers.

That prevents simulation of Snoop (which has been broken in ns-2, like, forever), PEPs, cross-layer optimisation, etc.

Is closing that off and enforcing layering desirable?

Lloyd Wood
http://tinyurl.com/lloydwood-ccsr


From ruben at net.t-labs.tu-berlin.de  Tue Nov  9 03:01:47 2010
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Tue, 09 Nov 2010 12:01:47 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTikvRxHDRjahK_FJUyeBQHwihCxPOiDOFcFEP3W6@mail.gmail.com>
References: <258D317A-538E-4665-B8BC-F8500B039BA2@vialink.com.br>	<AANLkTi=A8JjtxQcJwToKkaVxwH2QrFbz2fDcmM3ENzby@mail.gmail.com>	<AANLkTi=BCyrcY-feZA1ChA1mT40_6+ONm7pQixZOUSZZ@mail.gmail.com>	<8AD0C5E5-25DD-46B0-985B-17249EDB6DD2@vialink.com.br>
	<AANLkTikvRxHDRjahK_FJUyeBQHwihCxPOiDOFcFEP3W6@mail.gmail.com>
Message-ID: <4CD92A1B.9030502@net.t-labs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mathieu,

On 11/9/10 11:28 AM, Mathieu Lacage wrote:
> On Tue, Nov 9, 2010 at 11:22, Claudio S? de Abreu <cabreu at vialink.com.br>wrote:
> 
>> I don's understand. ns-3 don't have a full tcp header implemented, missing
>> tcp options and making wrong treatment of data offset. Because of this, any
>> kid of tcp flavor that uses tcp options may not be implemented unless we do
>> a work around inside the specific class that implements, for exemple,
>> tcp-sack  (like ns-2). Speaking about emulation mode, all great Operating
>> Systems (Linux, Windows, Mac OS X), uses tcp-sack as default to have
>> performance improvement in communications when we have some packet loss or
>> when the packets arrive in wrong order. If ns-3 is not able to emulate sack,
>> for exemple, we never will be capable to really make any correct
>> consideration about performance in real world.
>>
> 
> Yes, I think that it's a great idea to add tcp option support to the ns-3
> tcp header but my point was that I would nack any patch that attempts to
> allow someone to read a header in the middle of a packet without calling
> RemoveHeader as many times as needed to peel off external headers.

Why is that (yes, I read the previous email, but still)? Is this a
performance issue? A design issue? What's wrong with having both
capabilities? ns-3 is a simulator after all. Users should have the
freedom to peek into packets the way they want?

I'm sure you have other good reasons. So what is it?


> 
>> I don't have problems with the serialize/deserialize methods, but I think
>> that the best way do make header operations is to have a class that
>> implements the full header specification, and methods to get/put each header
>> field, including tcp-options, of course.
>>
> 
> We are in violent agreement here.

Again, why is that? I'm no expert here, I just want to understand.

Ruben

> Mathieu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM2SobAAoJEF+2tk4uvSJPi6AH/1YEQrG3COMtzvcYujdhKmIl
VHomzVAv+TEQqrJFb7UtRaIfAtQZ1Zb/z3p4YPLh47PpOf6rSSb2TBvC3A+JgUCI
xFk4n6FGFJmgPFMimhBYh/wGY1gO4sBBu89mK2GLf9GgR9vViAkOASQ28TX/iDqS
PAp/L5U+xrZ18EleRTfkglVaYNcbigSkmVVpdPrvQ/f1Irm9Xea+YZFlWXpLV3kV
H8HflyM89ov+KXe1Y6LcthoXttxRco5qKxcleO2BW9Ltum5i5xyvMAoc4U1eQebk
Oj7cuh0Wno+sSV+LCpfNDa6jtgt93ggzi2jqHBQL6F6aJVHwEb8wg0rfgDBZh90=
=fPyc
-----END PGP SIGNATURE-----

From mathieu.lacage at inria.fr  Tue Nov  9 03:28:39 2010
From: mathieu.lacage at inria.fr (Mathieu Lacage)
Date: Tue, 9 Nov 2010 12:28:39 +0100 (CET)
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <4CD92A1B.9030502@net.t-labs.tu-berlin.de>
Message-ID: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>



> > Yes, I think that it's a great idea to add tcp option support to the
> > ns-3
> > tcp header but my point was that I would nack any patch that
> > attempts to
> > allow someone to read a header in the middle of a packet without
> > calling
> > RemoveHeader as many times as needed to peel off external headers.
> 
> Why is that (yes, I read the previous email, but still)? Is this a
> performance issue? A design issue? What's wrong with having both
> capabilities? ns-3 is a simulator after all. Users should have the
> freedom to peek into packets the way they want?
> 
> I'm sure you have other good reasons. So what is it?

1) writing a protocol implementation that relies on being able to ask for a header of a certain type in a packet would make this protocol implementation not work when the packet comes from the real world.
2) reading a header in the middle of a packet is easy to do if you really need it by calling RemoveHeader as many times as needed.

To summarize: no real loss of functionality by not providing this function and a major upside: all our protocols work transparently when interconnected with real code (DCE or realtime scheduling) which was one of the major design goals of ns-3. It's like a coding style enforcement except we enforce it through API design.

If you don't care about this, yes, you are going to be unhappy because you have more work to do but being able to have this transparent integration is what ns-3 set out to achieve when it started. So, the goals could be changed but that would take quite a lot of convincing (for me at least).

> >> I don't have problems with the serialize/deserialize methods, but I
> >> think
> >> that the best way do make header operations is to have a class that
> >> implements the full header specification, and methods to get/put
> >> each header
> >> field, including tcp-options, of course.
> >>
> >
> > We are in violent agreement here.
> 
> Again, why is that? I'm no expert here, I just want to understand.

Are you asking why it is a good idea to add tcp option processing to the ns-3 tcp/ip stack ?

Mathieu

From ruben at net.t-labs.tu-berlin.de  Tue Nov  9 04:45:42 2010
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Tue, 09 Nov 2010 13:45:42 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
Message-ID: <4CD94276.2050007@net.t-labs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 11/9/10 12:28 PM, Mathieu Lacage wrote:
> 
> 
>>> Yes, I think that it's a great idea to add tcp option support to the
>>> ns-3
>>> tcp header but my point was that I would nack any patch that
>>> attempts to
>>> allow someone to read a header in the middle of a packet without
>>> calling
>>> RemoveHeader as many times as needed to peel off external headers.
>>
>> Why is that (yes, I read the previous email, but still)? Is this a
>> performance issue? A design issue? What's wrong with having both
>> capabilities? ns-3 is a simulator after all. Users should have the
>> freedom to peek into packets the way they want?
>>
>> I'm sure you have other good reasons. So what is it?
> 
> 1) writing a protocol implementation that relies on being able to ask for a header of a certain type in a packet would make this protocol implementation not work when the packet comes from the real world.

I'm afraid I don't understand why.

> 2) reading a header in the middle of a packet is easy to do if you really need it by calling RemoveHeader as many times as needed.

Sure. But RemoveHeader is going to trash all the headers it removes,
right? So, say that at the layer 2 you want to read a header at the
layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
believe that is also what Lloyd is hinting at.)

> To summarize: no real loss of functionality by not providing this function and a major upside: all our protocols work transparently when interconnected with real code (DCE or realtime scheduling) which was one of the major design goals of ns-3. It's like a coding style enforcement except we enforce it through API design.
> 
> If you don't care about this, yes, you are going to be unhappy because you have more work to do but being able to have this transparent integration is what ns-3 set out to achieve when it started. So, the goals could be changed but that would take quite a lot of convincing (for me at least).
> 
>>>> I don't have problems with the serialize/deserialize methods, but I
>>>> think
>>>> that the best way do make header operations is to have a class that
>>>> implements the full header specification, and methods to get/put
>>>> each header
>>>> field, including tcp-options, of course.
>>>>
>>>
>>> We are in violent agreement here.
>>
>> Again, why is that? I'm no expert here, I just want to understand.
> 
> Are you asking why it is a good idea to add tcp option processing to the ns-3 tcp/ip stack ?

Forget it. I read "disagreement" in your statement earlier instead of
"agreement".

Ruben

> Mathieu

- -- 
Ruben Merz                   Deutsche Telekom Laboratories
http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM2UJ2AAoJEF+2tk4uvSJPpC4H/1qvcRhIjalY9eEPlFNNryax
RQCxObHI/mtAV6dwO7d12eXV55bTYzlltr9EOG996V/luBc/xE9zzKpiUv9SRWbY
n7+oOIHjTTYBcMg2i/FWLfK+fQQYg7qLMd5CNHZj88cBgd+wwTfzpDssYqGXV7Ue
3DiWncUEPHECTomTtww47q1hAICqcbgSpiLnBQbye8BgycKths2fowucJ6BiVoP3
oXhBvOxRdykD/6/s0ieuPYardYvlCXTQepJeuvcAS1LBqxxKCs/VIt7ZzCgRCNXY
j7MxzDvFAv1Tbf1MTTta8Q9s3pR3qfIa4nu8476GsmcbhQvGO3SpKDUWd07DDn4=
=D1hR
-----END PGP SIGNATURE-----

From mathieu.lacage at gmail.com  Tue Nov  9 04:55:09 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Tue, 9 Nov 2010 13:55:09 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <4CD94276.2050007@net.t-labs.tu-berlin.de>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
Message-ID: <AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>

On Tue, Nov 9, 2010 at 13:45, Ruben Merz <ruben at net.t-labs.tu-berlin.de> wrote:

>> 1) writing a protocol implementation that relies on being able to ask for a header of a certain type in a packet would make this protocol implementation not work when the packet comes from the real world.
>
> I'm afraid I don't understand why.

If you have API like this:

packet->GetHeaderOfType (TCP_HEADER);

You (the packet code) need to be able to tell the type of each header
stored in the packet. This information is not available if the packet
is coming from the real-world. You could attempt to reconstruct it
manually when you get the packet from the real world before sending it
in ns-3 but that would defeat the whole idea of making everything work
transparently: you would have to write adhoc conversion code for every
emulation use-case.

> Sure. But RemoveHeader is going to trash all the headers it removes,
> right? So, say that at the layer 2 you want to read a header at the
> layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
> believe that is also what Lloyd is hinting at.)

Yes, I would expect you to call Copy before calling RemoveHeader.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>

From ruben at net.t-labs.tu-berlin.de  Tue Nov  9 05:10:09 2010
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Tue, 09 Nov 2010 14:10:09 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
Message-ID: <4CD94831.9000408@net.t-labs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 11/9/10 1:55 PM, Mathieu Lacage wrote:
> On Tue, Nov 9, 2010 at 13:45, Ruben Merz <ruben at net.t-labs.tu-berlin.de> wrote:
> 
>>> 1) writing a protocol implementation that relies on being able to ask for a header of a certain type in a packet would make this protocol implementation not work when the packet comes from the real world.
>>
>> I'm afraid I don't understand why.
> 
> If you have API like this:
> 
> packet->GetHeaderOfType (TCP_HEADER);
> 
> You (the packet code) need to be able to tell the type of each header
> stored in the packet. This information is not available if the packet
> is coming from the real-world. You could attempt to reconstruct it
> manually when you get the packet from the real world before sending it
> in ns-3 but that would defeat the whole idea of making everything work
> transparently: you would have to write adhoc conversion code for every
> emulation use-case.

Make sense. Thanks.

>> Sure. But RemoveHeader is going to trash all the headers it removes,
>> right? So, say that at the layer 2 you want to read a header at the
>> layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
>> believe that is also what Lloyd is hinting at.)
> 
> Yes, I would expect you to call Copy before calling RemoveHeader.

Works too.
Ruben

> Mathieu

- -- 
Ruben Merz                   Deutsche Telekom Laboratories
http://www.net.t-labs.tu-berlin.de/people/ruben_merz.shtml
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM2UgxAAoJEF+2tk4uvSJPC0sIAKMcTauDXm6QPB44dzNX1c3G
Sd4MX3tqqSFmhB0/zpS8QSVpFu2hjrLsldxYJ81wd+ruHb4r7EGBjq7AUvf0y7VV
r5wyp4LznDsDtCTXRKVXJllqGLzcfdLRf1b8WfCcoGMDLtDOA2gKtIrU0TfmnoAZ
sDIXyejmh3OUqIU+4ay4QlCXo1Wjeq9+tYaoFbDqlzVMzJgMmXz2DOVye75gWTZP
cvZbm2jo01W+c0juswKU/5tslbeHD/aDL1Wo5/Z6FJEW/bRh+7y8ttlsbDgqDNIU
rMo7NUKLe7Hjy5GspJYQCfKXol7DYwud8c/TXKzKxFDgwCagyr2V05swqfW2V1M=
=zWnV
-----END PGP SIGNATURE-----

From L.Wood at surrey.ac.uk  Tue Nov  9 05:49:17 2010
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 9 Nov 2010 13:49:17 +0000
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>

> > Sure. But RemoveHeader is going to trash all the headers it removes, 
> > right? So, say that at the layer 2 you want to read a header at the 
> > layer 3 or above. Isn't using RemoveHeader going to be problematic? (I 
> > believe that is also what Lloyd is hinting at.)
>
> Yes, I would expect you to call Copy before calling RemoveHeader.

There's probably a need for a function that recursively does the RemoveHeader/Copy thing as often as possible, and then presents the copied pieces of packets for inspection in a list...




From mathieu.lacage at gmail.com  Tue Nov  9 06:00:46 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Tue, 9 Nov 2010 15:00:46 +0100
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
Message-ID: <AANLkTik2HGg=LrfASZeNyZN6GJY9sm3etjmP7s+EY8kJ@mail.gmail.com>

On Tue, Nov 9, 2010 at 14:49,  <L.Wood at surrey.ac.uk> wrote:
>> > Sure. But RemoveHeader is going to trash all the headers it removes,
>> > right? So, say that at the layer 2 you want to read a header at the
>> > layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
>> > believe that is also what Lloyd is hinting at.)
>>
>> Yes, I would expect you to call Copy before calling RemoveHeader.
>
> There's probably a need for a function that recursively does the RemoveHeader/Copy thing as often as possible, and then presents the copied pieces of packets for inspection in a list...

That API would depend on the Packet knowing the type of the headers
present in the packet which is precisely a feature we want to make
sure no protocol implementation depends upon to make emulation really
transparent. i.e., a packet knows the type of headers present
internally but it's used solely to implement Packet::Print and this
function will not print what you think it should if you use it in
emulation mode.

I suspect that if you really intend to write a protocol implementation
that depends on this knowledge (type of headers present), you could
use Packet::BeginItem and Packet::EndItem because this is what
Packet::Print is implemented with. However, we do not intend to make
this easier to do for you because we specifically want to put the
incentive towards not doing this. So, you can do all this stuff with
the current API but, it's hard to do and it's on purpose.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>

From suresh.lalith at gmail.com  Tue Nov  9 06:02:58 2010
From: suresh.lalith at gmail.com (Lalith Suresh)
Date: Tue, 9 Nov 2010 14:02:58 +0000
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
Message-ID: <AANLkTik=avZ6Q_HsRDLBURq+eaDm9zm6xMh6GeKdKpvh@mail.gmail.com>

Hello,

On Tue, Nov 9, 2010 at 1:49 PM, <L.Wood at surrey.ac.uk> wrote:

> > > Sure. But RemoveHeader is going to trash all the headers it removes,
> > > right? So, say that at the layer 2 you want to read a header at the
> > > layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
> > > believe that is also what Lloyd is hinting at.)
> >
> > Yes, I would expect you to call Copy before calling RemoveHeader.
>
> There's probably a need for a function that recursively does the
> RemoveHeader/Copy thing as often as possible, and then presents the copied
> pieces of packets for inspection in a list...
>

RemoveHeader() currently works with a reference to an instance of a
particular header type passed to it as an argument, judging the number of
bytes to extract based on the header type. Considering this, I guess it's
better done manually because the function can't make any assumption as to
what kind of headers the packet holds. For instance, if someone is working
with IPSec, he'd probably have an AH/ESP header between the IP and TCP/UDP
headers.


-- 
Lalith Suresh
*Department of Computer Science and Engineering*
*Instituto Superior T?cnico*
www.lalith.in

From L.Wood at surrey.ac.uk  Tue Nov  9 06:27:09 2010
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Tue, 9 Nov 2010 14:27:09 +0000
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <AANLkTik=avZ6Q_HsRDLBURq+eaDm9zm6xMh6GeKdKpvh@mail.gmail.com>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
	<AANLkTik=avZ6Q_HsRDLBURq+eaDm9zm6xMh6GeKdKpvh@mail.gmail.com>
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC928E@EXMB01CMS.surrey.ac.uk>

Yes, you'd have to implement a parser walking the stack, and looking at returned byte values to determine what the next header to remove is.

This is non-trivial to implement, but useful.

________________________________
From: Lalith Suresh [mailto:suresh.lalith at gmail.com]
Sent: 09 November 2010 14:03
To: Wood L Dr (Electronic Eng)
Cc: mathieu.lacage at gmail.com; ruben at net.t-labs.tu-berlin.de; ns-developers at isi.edu; simu2010 at vialink.com.br
Subject: Re: [Ns-developers] Tcp header and SACK
Importance: High

Hello,

On Tue, Nov 9, 2010 at 1:49 PM, <L.Wood at surrey.ac.uk<mailto:L.Wood at surrey.ac.uk>> wrote:
> > Sure. But RemoveHeader is going to trash all the headers it removes,
> > right? So, say that at the layer 2 you want to read a header at the
> > layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
> > believe that is also what Lloyd is hinting at.)
>
> Yes, I would expect you to call Copy before calling RemoveHeader.

There's probably a need for a function that recursively does the RemoveHeader/Copy thing as often as possible, and then presents the copied pieces of packets for inspection in a list...

RemoveHeader() currently works with a reference to an instance of a particular header type passed to it as an argument, judging the number of bytes to extract based on the header type. Considering this, I guess it's better done manually because the function can't make any assumption as to what kind of headers the packet holds. For instance, if someone is working with IPSec, he'd probably have an AH/ESP header between the IP and TCP/UDP headers.


--
Lalith Suresh
Department of Computer Science and Engineering
Instituto Superior T?cnico
www.lalith.in<http://www.lalith.in>


From gjcarneiro at gmail.com  Tue Nov  9 06:56:40 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 9 Nov 2010 14:56:40 +0000
Subject: [Ns-developers] Tcp header and SACK
In-Reply-To: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC928E@EXMB01CMS.surrey.ac.uk>
References: <1737333729.731642.1289302119526.JavaMail.root@zmbs1.inria.fr>
	<4CD94276.2050007@net.t-labs.tu-berlin.de>
	<AANLkTin3hkqkf_XaPDc4W1XAwUj5j_1WQYAFeboLVd-u@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC9287@EXMB01CMS.surrey.ac.uk>
	<AANLkTik=avZ6Q_HsRDLBURq+eaDm9zm6xMh6GeKdKpvh@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC928E@EXMB01CMS.surrey.ac.uk>
Message-ID: <AANLkTinuepf=oN9BZnVOAZyY6T1cGFahyEmQDNuJ8+NZ@mail.gmail.com>

On Tue, Nov 9, 2010 at 14:27, <L.Wood at surrey.ac.uk> wrote:

> Yes, you'd have to implement a parser walking the stack, and looking at
> returned byte values to determine what the next header to remove is.
>
> This is non-trivial to implement, but useful.
>

If it is not generic, it's not useful.  And it's not possible to make it
generic due to the diversity of protocols.  You can't make the 'common'
module (that keeps the Packet APIs) be aware of the existence of UDP or TCP
headers.

You could make an API to do what you want, but it has to sit in a high-level
module that is aware of a multitude of protocols.  It just does not belong
in the Packet class, or anywhere in the 'common' module.


>
> ________________________________
> From: Lalith Suresh [mailto:suresh.lalith at gmail.com]
> Sent: 09 November 2010 14:03
> To: Wood L Dr (Electronic Eng)
> Cc: mathieu.lacage at gmail.com; ruben at net.t-labs.tu-berlin.de;
> ns-developers at isi.edu; simu2010 at vialink.com.br
> Subject: Re: [Ns-developers] Tcp header and SACK
> Importance: High
>
> Hello,
>
> On Tue, Nov 9, 2010 at 1:49 PM, <L.Wood at surrey.ac.uk<mailto:
> L.Wood at surrey.ac.uk>> wrote:
> > > Sure. But RemoveHeader is going to trash all the headers it removes,
> > > right? So, say that at the layer 2 you want to read a header at the
> > > layer 3 or above. Isn't using RemoveHeader going to be problematic? (I
> > > believe that is also what Lloyd is hinting at.)
> >
> > Yes, I would expect you to call Copy before calling RemoveHeader.
>
> There's probably a need for a function that recursively does the
> RemoveHeader/Copy thing as often as possible, and then presents the copied
> pieces of packets for inspection in a list...
>
> RemoveHeader() currently works with a reference to an instance of a
> particular header type passed to it as an argument, judging the number of
> bytes to extract based on the header type. Considering this, I guess it's
> better done manually because the function can't make any assumption as to
> what kind of headers the packet holds. For instance, if someone is working
> with IPSec, he'd probably have an AH/ESP header between the IP and TCP/UDP
> headers.
>
>
> --
> Lalith Suresh
> Department of Computer Science and Engineering
> Instituto Superior T?cnico
> www.lalith.in<http://www.lalith.in>
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

From tomh at tomh.org  Tue Nov  9 09:38:45 2010
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 09 Nov 2010 10:38:45 -0700
Subject: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
In-Reply-To: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>
References: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>
Message-ID: <eedf42691d96c7599d34c2ac54569b2e@tomh.org>

On Sun, 7 Nov 2010 18:27:05 -0500, huanzhongli huanzhongli
<huanzhongli at gmail.com> wrote:
> Hi all,
> 
> I find a fatal bug in
>
ns-allinone-2.35-RC7<http://www.isi.edu/nsnam/dist/release/ns-allinone-2.35-RC7.tar.gz>
> .
> I install it in cygwin and it works well.
> But after I add a new agent and recompile it, ns can not start anymore.
> It shows the following error information:
> 
> [code omitted because of length]
> : invalid command name "?-*-"
>     while executing
> "?-*-    Mode:tcl"
> 
> This is caused by the Tcl scripts ns-packet.tcl in the folder
> ns-2.35\tcl\lib.
> There is two unknown bytes 0XFF 0XFE at the beginning of the file.
> I delete these two bytes, and then the bug is fixed.
> 

This seems to me that you may have accidentally edited the first line of
ns-packet.tcl to remove the comment symbol "#".  Can you make sure that
your first line reads:
# -*-   Mode:tcl; tcl-indent-level:8; tab-width:8; indent-tabs-mode:t -*-

Thank you for testing the ns-2 release candidate.  Here is a brief update
on the status.  I've not made a release yet since I am aiming to fix all of
the 64-bit issues for those models covered by the regression tests, before
making the release.  I am getting close; there is one remaining issue to
fix with the web models that result in divergent traces in 32-bit and
64-bit (due to passing web page pointers to Tcl space and back again).  I
expect to get some time to finish that off this month.

- Tom
  


From tomh at tomh.org  Tue Nov  9 10:13:03 2010
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 09 Nov 2010 11:13:03 -0700
Subject: [Ns-developers] ns-3 modular python bindings
In-Reply-To: <AANLkTi=pZPBZLRP3xj1hT7z4rF6DZwcEg866nMLBdJ5y@mail.gmail.com>
References: <AANLkTi=pZPBZLRP3xj1hT7z4rF6DZwcEg866nMLBdJ5y@mail.gmail.com>
Message-ID: <c21a048b02c979421927b7efcfc2615b@tomh.org>

Hi Gustavo, thanks for starting this work.  Below are some responses
inline.

On Sun, 7 Nov 2010 23:39:05 +0000, Gustavo Carneiro <gjcarneiro at gmail.com>
wrote:
> Hello,
> 
> I have begun to work on modular Python bindings.  The work I have so far
> has
> been uploaded to branch gjc/ns-3-modular-bindings:
> http://code.nsnam.org/gjc/ns-3-modular-bindings/
> 
> A new waf configure option was added: ./waf configure
--bindings-type=TYPE,
> where type can be "modular", "monolithic" (default), or "both".

Do you intend to propagate these options long-term, or is the monolithic
just
to preserve the current system for now?

> 
> A new waf option ./waf --apiscan=MODULE1,MODULE2,..., will scan bindings
> just for the specifying modules an place the apidefs in
> src/<module-path>/bindings.  The apidefs of a module will have to pull
in
> partial apidefs of other modules that are used by it, which is
unfortunate
> but needed to give enough information for pybindgen to generate correct
> code.  In runtime, the other modules' types are simply imported, not
> wrapped
> again.
> 
> A new Build method is added at runtime to request that bindings for the
> current module be added, just call "bld.ns3_python_bindings()" in the
> module
> wscript file, it will figure the rest by context (current wscript path).
> 
> The new Python bindings are installed into an 'ns' Python namespace,
> instead
> of ns3.  For instance, "import ns.node".  This will avoid clashes with
the
> old bindings, in case we want to keep the old bindings for
compatibility.

What do you think about a system that tries to build some kind of
compatibility
ns3 module based on the active modules?  For instance, if a particular
module is
omitted from the build, the _ns3.so library doesn't have those bindings? 
Or
do you favor having each module explicitly imported such as "import
ns.node"?

> 
> TODO:
> 
>   1. This stuff doesn't even build right now, for anyone else but me,
due
>   to
> circular dependencies between ns-3 modules; I have some quick-and-dirty
> patches in my tree, to get it to build, but then it fails again in
runtime
> for the same reason.  We need to fix circular dependencies, or else
modular
> bindings have no chance of working and it's not my fault;

I fixed src/core and src/simulator yesterday, and stalled at src/common.  
Propagation loss tests in src/common depend on src/mobility.

Trying to fix some of these issues raises the issue of what do we want the
granularity to be in the future.  For instance, it may be possible to
merge
src/core and src/simulator, and we could go further down that path as
needed.
Do people have an opinion of where the sweet spot lies here, with respect
to module granularity?

Another consideration is that we could define meta-modules such as
"ns3-core"
that could be specified at build time and would just build those modules
that are considered to be the essential core of ns-3.  It seems also that
waf
makes it easier here for script writers by tracking dependencies, so that
I 
just have to specify, for instance, ['node'] dependency to get all of the
parent
modules built.

In looking at what we have now, core and simulator probably could be
merged.
common/ is actually a mix of packet-related stuff and propagation-related
stuff; perhaps that should be split.  node/ is a mix of abstract base
classes and
Internet-related stuff.  Perhaps we could migrate some internet-related
interfaces
to internet-stack.

- Tom

From tomh at tomh.org  Tue Nov  9 10:35:26 2010
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 09 Nov 2010 11:35:26 -0700
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CD7B7DC.8030506@kit.edu>
References: <4CAFA932.1000900@tomh.org> <4CD7B7DC.8030506@kit.edu>
Message-ID: <387f67dbef56643f0b8c2988b80bd71f@tomh.org>

On Mon, 08 Nov 2010 09:42:04 +0100, Jens Mittag <jens.mittag at kit.edu>
wrote:
> Hi all,
> 
> I just stumbled across the C-library called C-Pluff, which aims to 
> provide a plugin-based framework for C/C++ based applications - similar 
> to the OSGi framework used in Eclipse. I know, this goes further than a 
> modular build system, and would still need a modular build system, but: 
> it has full dependency support and fully loose coupling of modules 
> through extension points and extensions. Might be worth a look. I know 
> that for example the XBMC project [1] makes use of C-Pluff for their 
> addon/plugin system.
> 
> Jens
> 

Thanks for the pointer; I'm not sure that a plug-in framework is a
priority need, but we'll have a look.

Although we ran out of time on Friday to discuss this, Mathieu and I had
some time to discuss afterwards.  Please have a look here at some revised
planning documentation:
http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements

In particular, the Goals section tries to elaborate the broader project
goal of where I would like to go, and the requirements section discusses
how it might work from a user/developer perspective.

It seems that jhbuild (or something that might lightly wrap jhbuild) meets
most of the requirements elaborated, so our next steps are to try out
jhbuild.

As usual, comments or suggestions would be appreciated.  One can see that
there are still some open issues.

- Tom



From gjcarneiro at gmail.com  Tue Nov  9 10:38:26 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Tue, 9 Nov 2010 18:38:26 +0000
Subject: [Ns-developers] ns-3 modular python bindings
In-Reply-To: <c21a048b02c979421927b7efcfc2615b@tomh.org>
References: <AANLkTi=pZPBZLRP3xj1hT7z4rF6DZwcEg866nMLBdJ5y@mail.gmail.com>
	<c21a048b02c979421927b7efcfc2615b@tomh.org>
Message-ID: <AANLkTim1URdK3V9PWoxxFwQ1XUkx-tLFtU1zF2o960yk@mail.gmail.com>

On Tue, Nov 9, 2010 at 18:13, Tom Henderson <tomh at tomh.org> wrote:

> Hi Gustavo, thanks for starting this work.  Below are some responses
> inline.
>
> On Sun, 7 Nov 2010 23:39:05 +0000, Gustavo Carneiro <gjcarneiro at gmail.com>
> wrote:
> > Hello,
> >
> > I have begun to work on modular Python bindings.  The work I have so far
> > has
> > been uploaded to branch gjc/ns-3-modular-bindings:
> > http://code.nsnam.org/gjc/ns-3-modular-bindings/
> >
> > A new waf configure option was added: ./waf configure
> --bindings-type=TYPE,
> > where type can be "modular", "monolithic" (default), or "both".
>
> Do you intend to propagate these options long-term, or is the monolithic
> just
> to preserve the current system for now?
>
>
I favor keeping the monolithic module for the time being, in parallel. In
the future we could build only the modular bindings, and for a while (a
couple of ns-3 releases) add a compatibility module that pulls the modular
bindings and makes them appear as monolithic.


> >
> > A new waf option ./waf --apiscan=MODULE1,MODULE2,..., will scan bindings
> > just for the specifying modules an place the apidefs in
> > src/<module-path>/bindings.  The apidefs of a module will have to pull
> in
> > partial apidefs of other modules that are used by it, which is
> unfortunate
> > but needed to give enough information for pybindgen to generate correct
> > code.  In runtime, the other modules' types are simply imported, not
> > wrapped
> > again.
> >
> > A new Build method is added at runtime to request that bindings for the
> > current module be added, just call "bld.ns3_python_bindings()" in the
> > module
> > wscript file, it will figure the rest by context (current wscript path).
> >
> > The new Python bindings are installed into an 'ns' Python namespace,
> > instead
> > of ns3.  For instance, "import ns.node".  This will avoid clashes with
> the
> > old bindings, in case we want to keep the old bindings for
> compatibility.
>
> What do you think about a system that tries to build some kind of
> compatibility
> ns3 module based on the active modules?  For instance, if a particular
> module is
> omitted from the build, the _ns3.so library doesn't have those bindings?
> Or
> do you favor having each module explicitly imported such as "import
> ns.node"?
>

I favor that new code is written to "import ns.node".  Yes, it's more
verbose, but it is more efficient to import just the modules that you need.
 And is more modular.  Even in C++ you don't import one big mega header with
everything; I don't see why Python should be different.

And I am not talking just about the Python module.  I envision that the ns-3
C++ module 'node' will be created as a libns3_node.so.  The corresponding
Python module will be ns/node.so, and node.so links to libns3_node.so.
 Importing all ns-3 python modules means importing all ns-3 code.

I favor that the compatiblity "ns3" module is generated based on the set of
"active" modules, using the modular bindings as source.  For example:

---- ns3/__init__.py: ---
from ns.core import *
from ns.common import *
from ns.simulator import *
from ns.node import *
# ...
import warnings
warnings.warn("the ns3 module is deprecated, import ns instead",
DeprecationWarning)



>
> >
> > TODO:
> >
> >   1. This stuff doesn't even build right now, for anyone else but me,
> due
> >   to
> > circular dependencies between ns-3 modules; I have some quick-and-dirty
> > patches in my tree, to get it to build, but then it fails again in
> runtime
> > for the same reason.  We need to fix circular dependencies, or else
> modular
> > bindings have no chance of working and it's not my fault;
>
> I fixed src/core and src/simulator yesterday, and stalled at src/common.
> Propagation loss tests in src/common depend on src/mobility.
>
> Trying to fix some of these issues raises the issue of what do we want the
> granularity to be in the future.  For instance, it may be possible to
> merge
> src/core and src/simulator, and we could go further down that path as
> needed.
> Do people have an opinion of where the sweet spot lies here, with respect
> to module granularity?
>
>
Just to be clear, whatever merging occurs, there can be no build or runtime
circular dependencies in the module dependency graph.  Else everything else
falls apart.


> Another consideration is that we could define meta-modules such as
> "ns3-core"
> that could be specified at build time and would just build those modules
> that are considered to be the essential core of ns-3.  It seems also that
> waf
> makes it easier here for script writers by tracking dependencies, so that
> I
> just have to specify, for instance, ['node'] dependency to get all of the
> parent
> modules built.
>

Yes.  This works if dependencies between modules are correctly declared in
the wscript files, which is not always the case. But I think it is useful to
have this info, for cases like this.


>
> In looking at what we have now, core and simulator probably could be
> merged.
> common/ is actually a mix of packet-related stuff and propagation-related
> stuff; perhaps that should be split.  node/ is a mix of abstract base
> classes and
> Internet-related stuff.  Perhaps we could migrate some internet-related
> interfaces
> to internet-stack.
>

This is another discussion, it should be another email thread (different
subject)...

But I agree that perhaps we do not need 45 (what we have now) different
modules in ns-3...

Thanks,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

From huanzhongli at gmail.com  Tue Nov  9 16:29:47 2010
From: huanzhongli at gmail.com (huanzhongli huanzhongli)
Date: Tue, 9 Nov 2010 19:29:47 -0500
Subject: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
In-Reply-To: <eedf42691d96c7599d34c2ac54569b2e@tomh.org>
References: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>
	<eedf42691d96c7599d34c2ac54569b2e@tomh.org>
Message-ID: <AANLkTino4ZDLoX_+SueshjnwXbCC+QRXJSkpN7P_KCL9@mail.gmail.com>

Hi Tom,

I do a double check and make sure that the problem will definitely happen in
Cygwin (the version of Cygwin I use is CYGWIN_NT-5.1 736db0b156344a7
1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin). I'm quite sure that there
will be two invisible hexadecimal bytes 0XFF and 0XFE at the beginning of
the file ns-packet.tcl if you download the release candidate
ns-allinone-2.35-RC7
and unzip it in Cygwin. You can also find them if you open the file
ns-packet.tcl
with a hexadecimal editor. Note that the two bytes can not be seen in a text
editor, you need a hexadecimal editor (such as UltraEdit) to get them.

However, when I do the same check in Ubuntu 10.04, the problem is gone. I
don't know why. Maybe it is a problem of unzip in Cygwin (the command I use
to unzip in Cygwin is "tar vzxf ns-allinone-2.35-RC7.tar.gz"). Anyway, if
you encounter such a problem in Cygwin, you know how to fix it now.

Looking forwards to the lease of ns-2.35 :-)

Huanzhong


On Tue, Nov 9, 2010 at 12:38 PM, Tom Henderson <tomh at tomh.org> wrote:

> On Sun, 7 Nov 2010 18:27:05 -0500, huanzhongli huanzhongli
> <huanzhongli at gmail.com> wrote:
> > Hi all,
> >
> > I find a fatal bug in
> >
> ns-allinone-2.35-RC7<
> http://www.isi.edu/nsnam/dist/release/ns-allinone-2.35-RC7.tar.gz>
> > .
> > I install it in cygwin and it works well.
> > But after I add a new agent and recompile it, ns can not start anymore.
> > It shows the following error information:
> >
> > [code omitted because of length]
> > : invalid command name "?-*-"
> >     while executing
> > "?-*-    Mode:tcl"
> >
> > This is caused by the Tcl scripts ns-packet.tcl in the folder
> > ns-2.35\tcl\lib.
> > There is two unknown bytes 0XFF 0XFE at the beginning of the file.
> > I delete these two bytes, and then the bug is fixed.
> >
>
> This seems to me that you may have accidentally edited the first line of
> ns-packet.tcl to remove the comment symbol "#".  Can you make sure that
> your first line reads:
> # -*-   Mode:tcl; tcl-indent-level:8; tab-width:8; indent-tabs-mode:t -*-
>
> Thank you for testing the ns-2 release candidate.  Here is a brief update
> on the status.  I've not made a release yet since I am aiming to fix all of
> the 64-bit issues for those models covered by the regression tests, before
> making the release.  I am getting close; there is one remaining issue to
> fix with the web models that result in divergent traces in 32-bit and
> 64-bit (due to passing web page pointers to Tcl space and back again).  I
> expect to get some time to finish that off this month.
>
> - Tom
>
>
>

From tomh at tomh.org  Tue Nov  9 21:43:05 2010
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 09 Nov 2010 21:43:05 -0800
Subject: [Ns-developers] GENI materials posted
Message-ID: <4CDA30E9.6060209@tomh.org>

Hi all,
We had a productive week at the GENI Engineering Conference in 
Washington DC.  We introduced aspects of ns-3 to two working groups, 
held a three hour ns-3 tutorial, and on Friday, held an all-day 
developers meeting.  I put a link to the tutorial materials here:
http://www.nsnam.org/tutorials.html

At the developers meeting, we spent a good bit of time discussing the 
need for node/device processing and start-up delays (previously 
discussed on this list), which led to another discussion about whether 
we should be modeling the power-up and power-down of nodes.  We also 
reviewed the ongoing work on the NSF Frameworks project, and reviewed a 
new motion planning framework that should be very useful for future 
mobility scenario generation.  The full notes are posted here:
http://www.nsnam.org/docs/meetings/november10.txt

Thanks to everyone who traveled to DC to participate!  As Nicola 
previously mentioned, we're aiming to have another such meeting either 
the day before or after the Workshop on ns-3 in late March.

- Tom

From nbaldo at cttc.es  Wed Nov 10 03:15:30 2010
From: nbaldo at cttc.es (Nicola Baldo)
Date: Wed, 10 Nov 2010 12:15:30 +0100
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <387f67dbef56643f0b8c2988b80bd71f@tomh.org>
References: <4CAFA932.1000900@tomh.org> <4CD7B7DC.8030506@kit.edu>
	<387f67dbef56643f0b8c2988b80bd71f@tomh.org>
Message-ID: <4CDA7ED2.8060400@cttc.es>



On 11/09/2010 07:35 PM, Tom Henderson wrote:
> Although we ran out of time on Friday to discuss this, Mathieu and I had
> some time to discuss afterwards.  Please have a look here at some revised
> planning documentation:
> http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements
>
> In particular, the Goals section tries to elaborate the broader project
> goal of where I would like to go, and the requirements section discusses
> how it might work from a user/developer perspective.
>
> It seems that jhbuild (or something that might lightly wrap jhbuild) meets
> most of the requirements elaborated, so our next steps are to try out
> jhbuild.
>
> As usual, comments or suggestions would be appreciated.  One can see that
> there are still some open issues.


My two cents:

> The basic idea of the ns-3 app store would be to store on a server a set of user-submitted metadata which describes various source code packages. Typical metadata would include:
>
>     * unique name
>     * version number
>     * last known good ns-3 version (tested against)
>     * description
>     * download url
>     * untar/unzip command
>     * configure command
>     * build command
>     * system prerequisites (if user needs to apt-get install other libraries)
>     * list of ns-3 package dependencies (other ns-3 packages which this package depends upon)
>

I would have an install command which is separate from the build command


> Requirements
>  Build and configuration
>
>     * Enable optimized, debug, and static builds

Do we have an agreement that static build will be done using static 
libraries, and the non-static build will be done using dynamic 
libraries? With one library per module in both cases?



> the above will install headers into build/debug/ns3/ and a libns3core.so into build/debug/lib/

1) can we go for more traditional and well-understood install paths?
I mean this:
headers   in build/debug/include
libraries in build/debug/lib
programs  in build/debug/bin

2) if "one library per module" is agreed upon, we should have a naming 
convention for libraries. Following the libns3core.so example, the name 
of the library for the wimin module should be "ns3wimin", so the shared 
lib on linux will be called libns3wimin.so, and whatever module that 
depends on wimin will need to be linked with -lns3wimin.
(I would actually remove the "ns3" prefix from the name, i.e., using 
libwimin.so and -lwimin)

3) as I said some time ago, once modules can be distributed 
independently, we'll run into header file name clashes. What about 
installing all headers in a subdir named after the module?
For example:
module wimin will install headers in build/debug/include/wimin
all modules depending on wimin will compile with -Ibuild/debug/include/wimin

Note that, based on the points 2) and 3) above, I get the feeling that 
we need some dependency system in place in order to get the modular 
build right. I am no expert on jhbuild, but my understanding was that 
this is not part of it. In order not to re-invent the wheel, what about 
pkg-config? For example, we could automatically generate a pkg-config 
file for each module based on its dependencies, and then call pkg-config 
to sort out the dependency tree and determine the right -I and -l flags 
for each module to be built.



> Open issue: What granularity of modules should we maintain? Continue with core, simulator, common, node? Merge them somehow?

I would merge them. I see no practical use case for a ns3 user to have 
them separate. If anybody ever wants to use src/simulator to build 
something that is not ns3, they can just copy the code. I wouldn't 
bother providing a separate module for that purpose.








From gjcarneiro at gmail.com  Wed Nov 10 03:38:23 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Wed, 10 Nov 2010 11:38:23 +0000
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CDA7ED2.8060400@cttc.es>
References: <4CAFA932.1000900@tomh.org> <4CD7B7DC.8030506@kit.edu>
	<387f67dbef56643f0b8c2988b80bd71f@tomh.org>
	<4CDA7ED2.8060400@cttc.es>
Message-ID: <AANLkTingPiEZ8h5mMB8pX3kBx9Vk+Fjs2ptn1=eAmAya@mail.gmail.com>

On Wed, Nov 10, 2010 at 11:15, Nicola Baldo <nbaldo at cttc.es> wrote:

>
>
> On 11/09/2010 07:35 PM, Tom Henderson wrote:
>
>> Although we ran out of time on Friday to discuss this, Mathieu and I had
>> some time to discuss afterwards.  Please have a look here at some revised
>> planning documentation:
>> http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements
>>
>> In particular, the Goals section tries to elaborate the broader project
>> goal of where I would like to go, and the requirements section discusses
>> how it might work from a user/developer perspective.
>>
>> It seems that jhbuild (or something that might lightly wrap jhbuild) meets
>> most of the requirements elaborated, so our next steps are to try out
>> jhbuild.
>>
>> As usual, comments or suggestions would be appreciated.  One can see that
>> there are still some open issues.
>>
>
>
> My two cents:
>
>  The basic idea of the ns-3 app store would be to store on a server a set
>> of user-submitted metadata which describes various source code packages.
>> Typical metadata would include:
>>
>>    * unique name
>>    * version number
>>    * last known good ns-3 version (tested against)
>>    * description
>>    * download url
>>    * untar/unzip command
>>    * configure command
>>    * build command
>>    * system prerequisites (if user needs to apt-get install other
>> libraries)
>>    * list of ns-3 package dependencies (other ns-3 packages which this
>> package depends upon)
>>
>>
> I would have an install command which is separate from the build command
>
>
>  Requirements
>>  Build and configuration
>>
>>    * Enable optimized, debug, and static builds
>>
>
> Do we have an agreement that static build will be done using static
> libraries, and the non-static build will be done using dynamic libraries?
> With one library per module in both cases?
>

I agree. If static library is practical, we should support it.  And it does
appear practical.


>
>
>
>  the above will install headers into build/debug/ns3/ and a libns3core.so
>> into build/debug/lib/
>>
>
> 1) can we go for more traditional and well-understood install paths?
> I mean this:
> headers   in build/debug/include
> libraries in build/debug/lib
> programs  in build/debug/bin
>
> 2) if "one library per module" is agreed upon, we should have a naming
> convention for libraries. Following the libns3core.so example, the name of
> the library for the wimin module should be "ns3wimin", so the shared lib on
> linux will be called libns3wimin.so, and whatever module that depends on
> wimin will need to be linked with -lns3wimin.
> (I would actually remove the "ns3" prefix from the name, i.e., using
> libwimin.so and -lwimin)
>
>
I wouldn't remove the ns3 prefix.  It's so short, why not keep it for extra
security against name clashes with system libraries?


> 3) as I said some time ago, once modules can be distributed independently,
> we'll run into header file name clashes. What about installing all headers
> in a subdir named after the module?
> For example:
> module wimin will install headers in build/debug/include/wimin
> all modules depending on wimin will compile with
> -Ibuild/debug/include/wimin
>
> Note that, based on the points 2) and 3) above, I get the feeling that we
> need some dependency system in place in order to get the modular build
> right. I am no expert on jhbuild, but my understanding was that this is not
> part of it. In order not to re-invent the wheel, what about pkg-config? For
> example, we could automatically generate a pkg-config file for each module
> based on its dependencies, and then call pkg-config to sort out the
> dependency tree and determine the right -I and -l flags for each module to
> be built.
>

jhbuild does support dependencies.  Jhbuild works with "modulesets", which
are XML files listing modules available, how to build them, and what are
their dependencies.  See for instance:

http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-2.30.modules

pkg-config may not be needed if all modules are installed to the same
location.  Although, on the other hand, it can be useful if each ns-3 module
has its own version number and we want to check for that version in modules
depending on it.


>
>
>  Open issue: What granularity of modules should we maintain? Continue with
>> core, simulator, common, node? Merge them somehow?
>>
>
> I would merge them. I see no practical use case for a ns3 user to have them
> separate. If anybody ever wants to use src/simulator to build something that
> is not ns3, they can just copy the code. I wouldn't bother providing a
> separate module for that purpose.
>
>
I would perhaps merge core+simulator and node+common.  The first two are for
even-driven simulations in general, the second group adds infrastructure for
network simulations in particular.

Other things we could merge are 1) all applications into a single
applications module; 2) merge nix, list, static, global routing into a
single module (leave only aodv and oslr separate).


-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

From L.Wood at surrey.ac.uk  Wed Nov 10 04:38:42 2010
From: L.Wood at surrey.ac.uk (L.Wood@surrey.ac.uk)
Date: Wed, 10 Nov 2010 12:38:42 +0000
Subject: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
In-Reply-To: <AANLkTino4ZDLoX_+SueshjnwXbCC+QRXJSkpN7P_KCL9@mail.gmail.com>
References: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>
	<eedf42691d96c7599d34c2ac54569b2e@tomh.org>
	<AANLkTino4ZDLoX_+SueshjnwXbCC+QRXJSkpN7P_KCL9@mail.gmail.com>
Message-ID: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC932E@EXMB01CMS.surrey.ac.uk>

Huan Zhongli,

I've just downloaded ns-allinone-2.35-RC7 under Cygwin 1.7.7 and tar xvfz'd it.
less ns-2.35/tcl/lib/ns-packet.tcl 
shows no binary codes.
emacs ns-2.35/tcl/lib/ns-packet.tcl
shows no binary codes.

Since you're Asian, I presume you are (knowingly or otherwise) a heavy Unicode user for different languages. ns is primitive single-byte ASCII (now UTF-8 equivalent) in all its source files - but this is not marked in any way. Editing an ASCII file with a unicode editor demands care.

http://en.wikipedia.org/wiki/Byte_Order_Mark

"The byte order mark (BOM) is a Unicode character used to signal the endianness (byte order) of a text file or stream. Its code point is U+FEFF. BOM use is optional, and, if used, should appear at the start of the text stream. Beyond its specific use as a byte-order indicator, the BOM character may also indicate which of the several Unicode representations the text is encoded in"
[..]
"Many Windows programs (including Windows Notepad) add BOMs to UTF-8 files by default. However in Unix-like systems (which make heavy use of text files for file formats as well as for inter-process communication) this practice will interfere with correct processing of important codes such as the shebang at the start of an interpreted script"

That page suggests that you are editing tcl script files using a UTF-16-capable editor, which is inserting the little-endian equivalent of the marker. Be careful with your text editors.


-----Original Message-----
From: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU] On Behalf Of huanzhongli huanzhongli
Sent: 10 November 2010 00:30
To: Tom Henderson
Cc: ns-developers at ISI.EDU
Subject: Re: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin

Hi Tom,

I do a double check and make sure that the problem will definitely happen in Cygwin (the version of Cygwin I use is CYGWIN_NT-5.1 736db0b156344a7
1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin). I'm quite sure that there will be two invisible hexadecimal bytes 0XFF and 0XFE at the beginning of the file ns-packet.tcl if you download the release candidate
ns-allinone-2.35-RC7
and unzip it in Cygwin. You can also find them if you open the file ns-packet.tcl with a hexadecimal editor. Note that the two bytes can not be seen in a text editor, you need a hexadecimal editor (such as UltraEdit) to get them.

However, when I do the same check in Ubuntu 10.04, the problem is gone. I don't know why. Maybe it is a problem of unzip in Cygwin (the command I use to unzip in Cygwin is "tar vzxf ns-allinone-2.35-RC7.tar.gz"). Anyway, if you encounter such a problem in Cygwin, you know how to fix it now.

Looking forwards to the lease of ns-2.35 :-)

Huanzhong


On Tue, Nov 9, 2010 at 12:38 PM, Tom Henderson <tomh at tomh.org> wrote:

> On Sun, 7 Nov 2010 18:27:05 -0500, huanzhongli huanzhongli 
> <huanzhongli at gmail.com> wrote:
> > Hi all,
> >
> > I find a fatal bug in
> >
> ns-allinone-2.35-RC7<
> http://www.isi.edu/nsnam/dist/release/ns-allinone-2.35-RC7.tar.gz>
> > .
> > I install it in cygwin and it works well.
> > But after I add a new agent and recompile it, ns can not start anymore.
> > It shows the following error information:
> >
> > [code omitted because of length]
> > : invalid command name "?-*-"
> >     while executing
> > "?-*-    Mode:tcl"
> >
> > This is caused by the Tcl scripts ns-packet.tcl in the folder 
> > ns-2.35\tcl\lib.
> > There is two unknown bytes 0XFF 0XFE at the beginning of the file.
> > I delete these two bytes, and then the bug is fixed.
> >
>
> This seems to me that you may have accidentally edited the first line 
> of ns-packet.tcl to remove the comment symbol "#".  Can you make sure 
> that your first line reads:
> # -*-   Mode:tcl; tcl-indent-level:8; tab-width:8; indent-tabs-mode:t -*-
>
> Thank you for testing the ns-2 release candidate.  Here is a brief 
> update on the status.  I've not made a release yet since I am aiming 
> to fix all of the 64-bit issues for those models covered by the 
> regression tests, before making the release.  I am getting close; 
> there is one remaining issue to fix with the web models that result in 
> divergent traces in 32-bit and 64-bit (due to passing web page 
> pointers to Tcl space and back again).  I expect to get some time to finish that off this month.
>
> - Tom
>
>
>


From tomh at tomh.org  Thu Nov 11 07:16:54 2010
From: tomh at tomh.org (Tom Henderson)
Date: Thu, 11 Nov 2010 07:16:54 -0800
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CDA7ED2.8060400@cttc.es>
References: <4CAFA932.1000900@tomh.org>
	<4CD7B7DC.8030506@kit.edu>	<387f67dbef56643f0b8c2988b80bd71f@tomh.org>
	<4CDA7ED2.8060400@cttc.es>
Message-ID: <4CDC08E6.8030906@tomh.org>

On 11/10/2010 03:15 AM, Nicola Baldo wrote:
>
>
> On 11/09/2010 07:35 PM, Tom Henderson wrote:
>> Although we ran out of time on Friday to discuss this, Mathieu and I had
>> some time to discuss afterwards. Please have a look here at some revised
>> planning documentation:
>> http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements
>>
>> In particular, the Goals section tries to elaborate the broader project
>> goal of where I would like to go, and the requirements section discusses
>> how it might work from a user/developer perspective.
>>
>> It seems that jhbuild (or something that might lightly wrap jhbuild)
>> meets
>> most of the requirements elaborated, so our next steps are to try out
>> jhbuild.
>>
>> As usual, comments or suggestions would be appreciated. One can see that
>> there are still some open issues.
>
>
> My two cents:
>
>> The basic idea of the ns-3 app store would be to store on a server a
>> set of user-submitted metadata which describes various source code
>> packages. Typical metadata would include:
>>
>> * unique name
>> * version number
>> * last known good ns-3 version (tested against)
>> * description
>> * download url
>> * untar/unzip command
>> * configure command
>> * build command
>> * system prerequisites (if user needs to apt-get install other libraries)
>> * list of ns-3 package dependencies (other ns-3 packages which this
>> package depends upon)
>>
>
> I would have an install command which is separate from the build command

Since we don't have an install step presently, we would need to teach 
users to build, install, run (instead of present build, run) if they are 
editing ns-3 modules.  Is that what you have in mind?

>
>
>> Requirements
>> Build and configuration
>>
>> * Enable optimized, debug, and static builds
>
> Do we have an agreement that static build will be done using static
> libraries, and the non-static build will be done using dynamic
> libraries? With one library per module in both cases?
>
>
I'll add to the requirements list.

>
>> the above will install headers into build/debug/ns3/ and a
>> libns3core.so into build/debug/lib/
>
> 1) can we go for more traditional and well-understood install paths?
> I mean this:
> headers in build/debug/include
> libraries in build/debug/lib
> programs in build/debug/bin

OK

>
> 2) if "one library per module" is agreed upon, we should have a naming
> convention for libraries. Following the libns3core.so example, the name
> of the library for the wimin module should be "ns3wimin", so the shared
> lib on linux will be called libns3wimin.so, and whatever module that
> depends on wimin will need to be linked with -lns3wimin.
> (I would actually remove the "ns3" prefix from the name, i.e., using
> libwimin.so and -lwimin)


I lean towards including the ns3 prefix but don't care strongly.

>
> 3) as I said some time ago, once modules can be distributed
> independently, we'll run into header file name clashes. What about
> installing all headers in a subdir named after the module?
> For example:
> module wimin will install headers in build/debug/include/wimin
> all modules depending on wimin will compile with
> -Ibuild/debug/include/wimin

OK, in user programs then, we do something like"
#include "ns3/wimin/wimin.h"?

>
> Note that, based on the points 2) and 3) above, I get the feeling that
> we need some dependency system in place in order to get the modular
> build right. I am no expert on jhbuild, but my understanding was that
> this is not part of it. In order not to re-invent the wheel, what about
> pkg-config? For example, we could automatically generate a pkg-config
> file for each module based on its dependencies, and then call pkg-config
> to sort out the dependency tree and determine the right -I and -l flags
> for each module to be built.
>
>
>
>> Open issue: What granularity of modules should we maintain? Continue
>> with core, simulator, common, node? Merge them somehow?
>
> I would merge them. I see no practical use case for a ns3 user to have
> them separate. If anybody ever wants to use src/simulator to build
> something that is not ns3, they can just copy the code. I wouldn't
> bother providing a separate module for that purpose.
>
>

I will try to put together a repo with a sample module layout for 
discussion and see what issues arise.

Thanks for the feedback,
Tom


From nbaldo at cttc.es  Thu Nov 11 10:51:36 2010
From: nbaldo at cttc.es (Nicola Baldo)
Date: Thu, 11 Nov 2010 19:51:36 +0100
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CDC08E6.8030906@tomh.org>
References: <4CAFA932.1000900@tomh.org>
	<4CD7B7DC.8030506@kit.edu>	<387f67dbef56643f0b8c2988b80bd71f@tomh.org>
	<4CDA7ED2.8060400@cttc.es> <4CDC08E6.8030906@tomh.org>
Message-ID: <4CDC3B38.1030704@cttc.es>



On 11/11/2010 04:16 PM, Tom Henderson wrote:
> On 11/10/2010 03:15 AM, Nicola Baldo wrote:
>> I would have an install command which is separate from the build command
>
> Since we don't have an install step presently, we would need to teach
> users to build, install, run (instead of present build, run) if they are
> editing ns-3 modules. Is that what you have in mind?
>


I mean that it should be possible to build each separate module manually 
using this procedure:

nicola at pcnbaldo:~/ns-3-dev$ cd wimin

nicola at pcnbaldo:~/ns-3-dev/wimin$ ./waf configure 
--prefix=~/ns-3-dev/install

nicola at pcnbaldo:~/ns-3-dev/wimin$ ./waf build
(objects and libns3wimin.so in ~/ns-3-dev/wimin/build/debug)

nicola at pcnbaldo:~/ns-3-dev/wimin$ ./waf install
(copy libns3wimin.so in ~/ns-3-dev/install/lib
wimin headers in  ~/ns-3-dev/install/include
wimin programs in  ~/ns-3-dev/install/bin )


Note that the user is not supposed to do the above by hand, because the 
global build will be done using a global tool (jhbuild or whatever 
else). I am fine if this global tool features a simple "build, run" 
paradigm.

Also note that "./waf configure --prefix", "./waf build" and "./waf 
install" are all already supported by waf. So it should be enough, as a 
first step, to cut and paste the current root wscript into the wscript 
within each module directory, with minor modifications, in order to 
support the "manual" modular build procedure that I described above.



>>
>> 1) can we go for more traditional and well-understood install paths?
>> I mean this:
>> headers in build/debug/include
>> libraries in build/debug/lib
>> programs in build/debug/bin
>
> OK

note that our current "./waf install" already does the above... well, 
the target is the "install" dir rather than "build/debug"



>
>>
>> 2) if "one library per module" is agreed upon, we should have a naming
>> convention for libraries. Following the libns3core.so example, the name
>> of the library for the wimin module should be "ns3wimin", so the shared
>> lib on linux will be called libns3wimin.so, and whatever module that
>> depends on wimin will need to be linked with -lns3wimin.
>> (I would actually remove the "ns3" prefix from the name, i.e., using
>> libwimin.so and -lwimin)
>
>
> I lean towards including the ns3 prefix but don't care strongly.
>

I don't care strongly either, so I am fine with keeping the ns3 prefix 
if people like it better.


>>
>> 3) as I said some time ago, once modules can be distributed
>> independently, we'll run into header file name clashes. What about
>> installing all headers in a subdir named after the module?
>> For example:
>> module wimin will install headers in build/debug/include/wimin
>> all modules depending on wimin will compile with
>> -Ibuild/debug/include/wimin
>
> OK, in user programs then, we do something like"
> #include "ns3/wimin/wimin.h"?
>

no, because if as I said you pass to the compiler
-Ibuild/debug/include/wimin

then you will just
#include "wimin.h"

(maybe "-Iinstall/include/wimin" depending on the build vs install thing)


>
> I will try to put together a repo with a sample module layout for
> discussion and see what issues arise.
>
> Thanks for the feedback,
> Tom



As a final note, I would like to recall how the ns-2 dynamic library 
approach works:
http://telecom.dei.unipd.it/ns/miracle/nsmiracle-dei80211mr-mini-howto/#dei80211mr

my experience with that is that it works ok, in that it effectively 
allows people to ship modules in a .tar.gz, and to use different 
collections of modules for their simulations.

Its biggest problems are:

1) it lacks a tool to orchestrate the build of all modules, so each 
module has to be built, configured and installed manually;

2) it is a pain to handle all the -I and -l flags, especially for 
recursive module dependencies

That's why I like jhbuild and pkg-config, respectively.


Nicola


From tazaki at sfc.wide.ad.jp  Thu Nov 11 20:35:15 2010
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Fri, 12 Nov 2010 13:35:15 +0900
Subject: [Ns-developers] NEMO/Mobile IPv6 simulator
Message-ID: <m2sjz7yxa4.wl@sfc.wide.ad.jp>


Hi folks,

I'd like to inform you my contribution of NEMO/MIP
simulator. 

Based on great ns-3-dce and ns-3-linux by Mathieu, NEMO and
Mobile IPv6 functionality of umip and linux net-next kernel
could be run with ns-3. You can use umip source code and
net-next-2.6 code 'as-is' in simulation.
# umip : USAGI-patched Mobile IPv6 for Linux
  http://umip.linux-ipv6.org/

I've only tested under Ubuntu 10.4 x86_64.
Fedora 12 x86_64 is tested but failed (it doesn't work correctly).
Other distro, including 32bit env, is not tested. 


You can try as following instruction.

# hg clone http://code.nsnam.org/thehajime/ns-3-dce-quagga-umip/
# cd ns-3-dce-quagga-umip/
# ./dce_binary.py
(this will download umip, net-next, ns-3, our zebra, pybindgen)
(it will show some error during iproute2 build, but ignore it)
# ./waf configure --with-linux-stack=./dce_build/ns-3-linux --with-pybindgen=./dce_build/pybindgen-0.15.0.770
# ./waf

now you can execute mip6d with sample script
# ./waf --run "dce-mip6d --useViz=1"

This script do Mobile Router handoff scenario between two
access routers, and do automatically
 - mip6d.conf generate (for HA, MR)
 - access router with quagga configuration with HAopt
 - MNN send ping6 to CN
 - MR send RA to MNN(s) by zebra
 - MR moves as Random Way Point model
 - pcap file generate per node
 - log (stdout/stderr) generate per process

You can take a look of this operation.

http://www.youtube.com/watch?v=y790NE3EPCg

You need to install a bunch of packages before building,
execution. I only have partial list as follows.

 libsqlite3-dev git git-core gcc-4.3 libreadline-dev
 ncurses-dev libncurses-dev gdb autoconf libc6-dbg mercurial
 pip python-pygraphviz python-pygraphviz python-gtk2
 python-pygoocanvas python-gnomedesktop python-gnome2
 python-rsvg python-kiwi indent bzr ipython python-dev
 libc6-dev-i386 

I will setup the document for this, and plan to merge this
into ns-3-dev, ns-3-dce, and ns-3-linux branch in future.

Comments, bug report, suggestion, and of course patch are
very welcome. 

regards,
hajime




From huanzhongli at gmail.com  Sat Nov 13 06:46:08 2010
From: huanzhongli at gmail.com (huanzhongli huanzhongli)
Date: Sat, 13 Nov 2010 09:46:08 -0500
Subject: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
In-Reply-To: <FD7B10366AE3794AB1EC5DE97A93A3730C2EDC932E@EXMB01CMS.surrey.ac.uk>
References: <AANLkTinVYxBc-Fi-Ajw_dTACVfGTe2KpxpOgEDyGPFCg@mail.gmail.com>
	<eedf42691d96c7599d34c2ac54569b2e@tomh.org>
	<AANLkTino4ZDLoX_+SueshjnwXbCC+QRXJSkpN7P_KCL9@mail.gmail.com>
	<FD7B10366AE3794AB1EC5DE97A93A3730C2EDC932E@EXMB01CMS.surrey.ac.uk>
Message-ID: <AANLkTimGqonBb=7MmHkb=2mq2wqNWnZtDK88J5AFxvb9@mail.gmail.com>

Hi,

I use hexedit to open the file ns-packet.tcl in Cygwin, no problem occurs.
Tom is right. My problem is caused by the editor UltraEdit I use to edit the
file.
I have learned a lesson from this discussion.
I'm grateful to Tom, Wood and all those developers who have concerned with
my problem.

Huanzhong


On Wed, Nov 10, 2010 at 7:38 AM, <L.Wood at surrey.ac.uk> wrote:

> Huan Zhongli,
>
> I've just downloaded ns-allinone-2.35-RC7 under Cygwin 1.7.7 and tar xvfz'd
> it.
> less ns-2.35/tcl/lib/ns-packet.tcl
> shows no binary codes.
> emacs ns-2.35/tcl/lib/ns-packet.tcl
> shows no binary codes.
>
> Since you're Asian, I presume you are (knowingly or otherwise) a heavy
> Unicode user for different languages. ns is primitive single-byte ASCII (now
> UTF-8 equivalent) in all its source files - but this is not marked in any
> way. Editing an ASCII file with a unicode editor demands care.
>
> http://en.wikipedia.org/wiki/Byte_Order_Mark
>
> "The byte order mark (BOM) is a Unicode character used to signal the
> endianness (byte order) of a text file or stream. Its code point is U+FEFF.
> BOM use is optional, and, if used, should appear at the start of the text
> stream. Beyond its specific use as a byte-order indicator, the BOM character
> may also indicate which of the several Unicode representations the text is
> encoded in"
> [..]
> "Many Windows programs (including Windows Notepad) add BOMs to UTF-8 files
> by default. However in Unix-like systems (which make heavy use of text files
> for file formats as well as for inter-process communication) this practice
> will interfere with correct processing of important codes such as the
> shebang at the start of an interpreted script"
>
> That page suggests that you are editing tcl script files using a
> UTF-16-capable editor, which is inserting the little-endian equivalent of
> the marker. Be careful with your text editors.
>
>
> -----Original Message-----
> From: ns-developers-bounces at ISI.EDU [mailto:ns-developers-bounces at ISI.EDU]
> On Behalf Of huanzhongli huanzhongli
> Sent: 10 November 2010 00:30
> To: Tom Henderson
> Cc: ns-developers at ISI.EDU
> Subject: Re: [Ns-developers] Bugs of ns-allinone-2.35-RC7 under cygwin
>
> Hi Tom,
>
> I do a double check and make sure that the problem will definitely happen
> in Cygwin (the version of Cygwin I use is CYGWIN_NT-5.1 736db0b156344a7
> 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin). I'm quite sure that there
> will be two invisible hexadecimal bytes 0XFF and 0XFE at the beginning of
> the file ns-packet.tcl if you download the release candidate
> ns-allinone-2.35-RC7
> and unzip it in Cygwin. You can also find them if you open the file
> ns-packet.tcl with a hexadecimal editor. Note that the two bytes can not be
> seen in a text editor, you need a hexadecimal editor (such as UltraEdit) to
> get them.
>
> However, when I do the same check in Ubuntu 10.04, the problem is gone. I
> don't know why. Maybe it is a problem of unzip in Cygwin (the command I use
> to unzip in Cygwin is "tar vzxf ns-allinone-2.35-RC7.tar.gz"). Anyway, if
> you encounter such a problem in Cygwin, you know how to fix it now.
>
> Looking forwards to the lease of ns-2.35 :-)
>
> Huanzhong
>
>
> On Tue, Nov 9, 2010 at 12:38 PM, Tom Henderson <tomh at tomh.org> wrote:
>
> > On Sun, 7 Nov 2010 18:27:05 -0500, huanzhongli huanzhongli
> > <huanzhongli at gmail.com> wrote:
> > > Hi all,
> > >
> > > I find a fatal bug in
> > >
> > ns-allinone-2.35-RC7<
> > http://www.isi.edu/nsnam/dist/release/ns-allinone-2.35-RC7.tar.gz>
> > > .
> > > I install it in cygwin and it works well.
> > > But after I add a new agent and recompile it, ns can not start anymore.
> > > It shows the following error information:
> > >
> > > [code omitted because of length]
> > > : invalid command name "?-*-"
> > >     while executing
> > > "?-*-    Mode:tcl"
> > >
> > > This is caused by the Tcl scripts ns-packet.tcl in the folder
> > > ns-2.35\tcl\lib.
> > > There is two unknown bytes 0XFF 0XFE at the beginning of the file.
> > > I delete these two bytes, and then the bug is fixed.
> > >
> >
> > This seems to me that you may have accidentally edited the first line
> > of ns-packet.tcl to remove the comment symbol "#".  Can you make sure
> > that your first line reads:
> > # -*-   Mode:tcl; tcl-indent-level:8; tab-width:8; indent-tabs-mode:t -*-
> >
> > Thank you for testing the ns-2 release candidate.  Here is a brief
> > update on the status.  I've not made a release yet since I am aiming
> > to fix all of the 64-bit issues for those models covered by the
> > regression tests, before making the release.  I am getting close;
> > there is one remaining issue to fix with the web models that result in
> > divergent traces in 32-bit and 64-bit (due to passing web page
> > pointers to Tcl space and back again).  I expect to get some time to
> finish that off this month.
> >
> > - Tom
> >
> >
> >
>

From fabinader at gmail.com  Sat Nov 13 09:52:46 2010
From: fabinader at gmail.com (Fuad Abinader)
Date: Sat, 13 Nov 2010 13:52:46 -0400
Subject: [Ns-developers] NEMO/Mobile IPv6 simulator
In-Reply-To: <m2sjz7yxa4.wl@sfc.wide.ad.jp>
References: <m2sjz7yxa4.wl@sfc.wide.ad.jp>
Message-ID: <AANLkTikqZbjH_0NtA8FFeBGBd4Y8fP5_bVg3inYuMPp0@mail.gmail.com>

Hi Hajime,

   I've seen the video, and it is quite impressive! We're extending Nautilus
for replacing IPSec/IKE for TLS negotiation (i.e. see
http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-06 for more
info), and this is great news as it could allow us testing our
implementation very easily, and therefore, I'm quite interested on this...
Could you describe a little bit more the environment, e.g. are you running
UMIP code as a daemon or is it integrated to NS-3? How do you integrated it?
Are you exchanging the whole MIPv6 signaling?

Regards,

Fuad Abinader

2010/11/12 Hajime Tazaki <tazaki at sfc.wide.ad.jp>

>
> Hi folks,
>
> I'd like to inform you my contribution of NEMO/MIP
> simulator.
>
> Based on great ns-3-dce and ns-3-linux by Mathieu, NEMO and
> Mobile IPv6 functionality of umip and linux net-next kernel
> could be run with ns-3. You can use umip source code and
> net-next-2.6 code 'as-is' in simulation.
> # umip : USAGI-patched Mobile IPv6 for Linux
>  http://umip.linux-ipv6.org/
>
> I've only tested under Ubuntu 10.4 x86_64.
> Fedora 12 x86_64 is tested but failed (it doesn't work correctly).
> Other distro, including 32bit env, is not tested.
>
>
> You can try as following instruction.
>
> # hg clone http://code.nsnam.org/thehajime/ns-3-dce-quagga-umip/
> # cd ns-3-dce-quagga-umip/
> # ./dce_binary.py
> (this will download umip, net-next, ns-3, our zebra, pybindgen)
> (it will show some error during iproute2 build, but ignore it)
> # ./waf configure --with-linux-stack=./dce_build/ns-3-linux
> --with-pybindgen=./dce_build/pybindgen-0.15.0.770
> # ./waf
>
> now you can execute mip6d with sample script
> # ./waf --run "dce-mip6d --useViz=1"
>
> This script do Mobile Router handoff scenario between two
> access routers, and do automatically
>  - mip6d.conf generate (for HA, MR)
>  - access router with quagga configuration with HAopt
>  - MNN send ping6 to CN
>  - MR send RA to MNN(s) by zebra
>  - MR moves as Random Way Point model
>  - pcap file generate per node
>  - log (stdout/stderr) generate per process
>
> You can take a look of this operation.
>
> http://www.youtube.com/watch?v=y790NE3EPCg
>
> You need to install a bunch of packages before building,
> execution. I only have partial list as follows.
>
>  libsqlite3-dev git git-core gcc-4.3 libreadline-dev
>  ncurses-dev libncurses-dev gdb autoconf libc6-dbg mercurial
>  pip python-pygraphviz python-pygraphviz python-gtk2
>  python-pygoocanvas python-gnomedesktop python-gnome2
>  python-rsvg python-kiwi indent bzr ipython python-dev
>  libc6-dev-i386
>
> I will setup the document for this, and plan to merge this
> into ns-3-dev, ns-3-dce, and ns-3-linux branch in future.
>
> Comments, bug report, suggestion, and of course patch are
> very welcome.
>
> regards,
> hajime
>
>
>
>

From tazaki at sfc.wide.ad.jp  Sat Nov 13 17:59:08 2010
From: tazaki at sfc.wide.ad.jp (Hajime Tazaki)
Date: Sun, 14 Nov 2010 10:59:08 +0900
Subject: [Ns-developers] NEMO/Mobile IPv6 simulator
In-Reply-To: <AANLkTikqZbjH_0NtA8FFeBGBd4Y8fP5_bVg3inYuMPp0@mail.gmail.com>
References: <m2sjz7yxa4.wl@sfc.wide.ad.jp>
	<AANLkTikqZbjH_0NtA8FFeBGBd4Y8fP5_bVg3inYuMPp0@mail.gmail.com>
Message-ID: <m2wroghdhv.wl@sfc.wide.ad.jp>


Hi Fuad,

#dropped ns-3-users since non-subscriber's post seems not to
 be permitted..

At Sat, 13 Nov 2010 13:52:46 -0400,
Fuad Abinader wrote:

>[2  <text/html; ISO-8859-1 (quoted-printable)>]
>
>?? I've seen the video, and it is quite impressive! We're extending Nautilus for replacing IPSec/IKE for
>TLS negotiation (i.e. see http://tools.ietf.org/html/draft-korhonen-mext-mip6-altsec-06 for more info),
>and this is great news as it could allow us testing our implementation very easily, and therefore, I'm
>quite interested on this... Could you describe a little bit more the environment, e.g. are you running
>UMIP code as a daemon or is it integrated to NS-3? 

Latter,
-PIC/-PIE compiled UMIP code called inside ns-3 process is
running.

See Mathieu's slide at last WNS 2010,
http://www.nsnam.org/workshops/wns3-2010/code-execution.pdf

and mine.
http://www.nsnam.org/workshops/wns3-2010/tazaki-wns3-100315.pdf

>How do you integrated it? 

Inside the simulation script, Mip6dHelper is used to load
mip6d binary, generated all the configuration (mip6d.conf)
per node, etc.

>Are you exchanging the whole MIPv6 signaling?

Yes, theoretically whole signaling could be simulated.
Though i've only tested BU/BA, MrS/MrA, RS/RA/NS/NA, and
ip6-ip6 encapsulation.


I've found that loading OpenSSL binary in umip, you may
need, doesn't work straightforward. Thus I didn't fix it by
umip configuration with --with-builtin-crypto.
#you can see in dce_binary.py.

anyway, I will update the detail document, after my thesis
writing (hopefully sooner :-)).

thanks,
hajime



From tomh at tomh.org  Sun Nov 14 22:39:25 2010
From: tomh at tomh.org (Tom Henderson)
Date: Sun, 14 Nov 2010 22:39:25 -0800
Subject: [Ns-developers] ns-3 modularity
In-Reply-To: <4CDC3B38.1030704@cttc.es>
References: <4CAFA932.1000900@tomh.org>
	<4CD7B7DC.8030506@kit.edu>	<387f67dbef56643f0b8c2988b80bd71f@tomh.org>
	<4CDA7ED2.8060400@cttc.es> <4CDC08E6.8030906@tomh.org>
	<4CDC3B38.1030704@cttc.es>
Message-ID: <4CE0D59D.1020105@tomh.org>

Nicola, Gustavo, and all,

An update on this project... Mitch has started an ns-3-jhbuild that uses 
jhbuild to download (and as a next step, to build) the components in the 
ns-3-allinone directory.  On Friday, I put together another sandbox 
repository (tomh/ns-3-modular) that does the following:
- renames ns-3-dev/src to ns-3-dev/modules
- merges simulator and core to a single module called simulator
- cut over modules/simulator to the new module directory structure

The --enable-modules=simulator will just include the simulator module in 
the build.

There is a README in the repo with a few more details.  What I was 
thinking was that this should be sufficient for people to try to address 
the following issues.

1) how to split the python bindings (presently, python must be disabled 
but it would be a nice step to be able to re-enable python when 
--enable-modules=simulator is specified)

2) start to build separate libraries (i.e. libns3simulator.so)

3) split the tests from the model/ code, and build a separate test 
library that test-runner uses

4) fix test.py to better handle examples

When we make progress on making one module work as we want, we can go 
for adding the second module (common).  Then, once we have two working, 
getting the rest working the same should be fairly straightforward.

I took another pass at providing a use case for discussion purposes:
http://www.nsnam.org/wiki/index.php/App_Store_Technical_Requirements#Example_third-party_ns-3_module

not all of the issues that have been discussed are resolved one way or 
another but I tried to flag the known open issues.

- Tom

From mathieu.lacage at gmail.com  Sun Nov 14 23:21:21 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Mon, 15 Nov 2010 08:21:21 +0100
Subject: [Ns-developers] Fwd: CAN DHT model available in ns-3
In-Reply-To: <a8bec966-bfd0-44b2-9fc4-553b43532726@26g2000yqv.googlegroups.com>
References: <a8bec966-bfd0-44b2-9fc4-553b43532726@26g2000yqv.googlegroups.com>
Message-ID: <AANLkTi=NrPoBD++kOqy=bn93HFmbUoCKX79fR+wy_sxV@mail.gmail.com>

I did not see this email on the developers ML. It might be of interest
to others.


---------- Forwarded message ----------
From: Vijay K. Gurbani <vijay.gurbani at gmail.com>
Date: Wed, Nov 3, 2010 at 16:47
Subject: CAN DHT model available in ns-3
To: ns-3-users <ns-3-users at googlegroups.com>
Cc: Derar al-omari <oderar2001 at yahoo.com>, tricha at ece.iit.edu


Hello: We are pleased to release an application model of the Content
Addressable
Network (CAN) distributed hash table in ns-3.

In order to get the CAN model, please follow the steps below:

?1) Please create an account for yourself at
? ? https://market.alcatel-lucent.com/release/SPRegistrantTypeSvlt
(please
? ? choose "General Access" role.)
?2) Once the account has been created, please go to the CAN home
? ? page at the following URL:
? ? http://open-innovation.alcatel-lucent.com/projects/ns-3-can
?3) Please select the "Request to join" link on the CAN home page
? ? and follow instructions to join the project and receive access
? ? to the SVN repository.
?4) The CAN SVN repository is:
? ? https://open-innovation.alcatel-lucent.com/svn/ns-3-can

Please download the model and read the README.CAN file for more
information
on compilation and related logistical information.

Vijay K. Gurbani ? ? ? ? ? ?Tricha Anjali ? ? ? ? ? ? ? Derar Al-Omari
<vkg at bell-labs.com> <tricha at ece.iit.edu> <oderar2001 at yahoo.com>

--
You received this message because you are subscribed to the Google
Groups "ns-3-users" group.
To post to this group, send email to ns-3-users at googlegroups.com.
To unsubscribe from this group, send email to
ns-3-users+unsubscribe at googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/ns-3-users?hl=en.




-- 
Mathieu Lacage <mathieu.lacage at gmail.com>


From nbaldo at cttc.es  Mon Nov 15 07:09:55 2010
From: nbaldo at cttc.es (Nicola Baldo)
Date: Mon, 15 Nov 2010 16:09:55 +0100
Subject: [Ns-developers] LTE dev coordination
Message-ID: <4CE14D43.8070101@cttc.es>


Hi all,

after the successful GSoC work on LTE by Giuseppe, I heard that a few 
other people/groups started working on the LTE code. Also at our 
institution (CTTC) we just started some development. I think it is of 
great interest for all of us working on LTE to coordinate, in order to 
benefit of each other's effort. So I'd like to ask everybody interested 
in LTE development to speak now and briefly describe their interests and 
activities.

To start with, I will explain what we are working on at CTTC.
We are interested on distributed Radio Resource Management and Mobility 
Management. To begin with, the development will be done by myself and 
Marco Miozzo, and we will focus on the following enhancements:
  - adding UL link adaptation
  - modeling inter-cell interference
  - reworking the RRM/scheduling API

So, if anyone interested in LTE development could come up with a short 
description on their current or planned activity, similar to what I 
provided above, it would be very much appreciated.

Regards,

Nicola


From andrea.sacco85 at gmail.com  Tue Nov 16 01:58:06 2010
From: andrea.sacco85 at gmail.com (Andrea Sacco)
Date: Tue, 16 Nov 2010 10:58:06 +0100
Subject: [Ns-developers] Bug 1012
Message-ID: <AANLkTi=S2WS18orZ5xJLkJ-V-xqp_R2EhL6MwZcqre3k@mail.gmail.com>

Hello everybody,
I've proposed a patch for the bug 1012. I've posted it to the bugzilla bug
page.
If someone can look at the patch (it is a minor change to the code), to let
me mark the bug as solved, it would be great.

Thanks,
Andrea

From mathieu.lacage at gmail.com  Tue Nov 16 04:22:31 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Tue, 16 Nov 2010 13:22:31 +0100
Subject: [Ns-developers] ns-3 projects on code.google.com
Message-ID: <AANLkTim3XTdrE-y0LHc4J25SqiuU9BnFVq2U7nff1Bsj@mail.gmail.com>

Some people might be interested in searching for the keyword "ns3" on
code.google.com. Here is the list of projects I found (many of which I
had never heard of before):

? ? ? ?http://code.google.com/p/ns-3-dev-def-routing/
? ? ? ?http://code.google.com/p/mptcp-ns3/
? ? ? ?http://code.google.com/p/zepler/
? ? ? ?http://code.google.com/p/ns3-mpls/
? ? ? ?http://code.google.com/p/ngpsvcanal/
? ? ? ?http://code.google.com/p/chord-ns3/
? ? ? ?http://code.google.com/p/tmix-ns3/
? ? ? ?http://code.google.com/p/ns3-wireless-planning/
? ? ? ?http://code.google.com/p/wwplan/
? ? ? ?http://code.google.com/p/dtnsimulationns3/
? ? ? ?http://code.google.com/p/ns3/
? ? ? ?http://code.google.com/p/ns3-debian/

Mathieu
--
Mathieu Lacage <mathieu.lacage at gmail.com>


From wzssyqa at gmail.com  Tue Nov 16 04:36:23 2010
From: wzssyqa at gmail.com (YunQiang Su)
Date: Tue, 16 Nov 2010 20:36:23 +0800
Subject: [Ns-developers] ns-3 projects on code.google.com
In-Reply-To: <AANLkTim3XTdrE-y0LHc4J25SqiuU9BnFVq2U7nff1Bsj@mail.gmail.com>
References: <AANLkTim3XTdrE-y0LHc4J25SqiuU9BnFVq2U7nff1Bsj@mail.gmail.com>
Message-ID: <AANLkTimt-HcJZeHECxrsB6sVV=wCFbZnUSMxbicimESD@mail.gmail.com>

>        http://code.google.com/p/ns3-debian/
>
> I have deleted it. I am using  git on
https://github.com/wzssyqa/ns3-debian

-- 
YunQiang Su

From boyko at iitp.ru  Tue Nov 16 04:34:20 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Tue, 16 Nov 2010 15:34:20 +0300
Subject: [Ns-developers] ns-3 projects on code.google.com
In-Reply-To: <AANLkTim3XTdrE-y0LHc4J25SqiuU9BnFVq2U7nff1Bsj@mail.gmail.com>
References: <AANLkTim3XTdrE-y0LHc4J25SqiuU9BnFVq2U7nff1Bsj@mail.gmail.com>
Message-ID: <1289910860.3126.26.camel@boyko>

On Tue, 2010-11-16 at 13:22 +0100, Mathieu Lacage wrote:
> Some people might be interested in searching for the keyword "ns3" on
> code.google.com. Here is the list of projects I found (many of which I
> had never heard of before):
> 
>        http://code.google.com/p/ns-3-dev-def-routing/
>        http://code.google.com/p/mptcp-ns3/
>        http://code.google.com/p/zepler/
>        http://code.google.com/p/ns3-mpls/
>        http://code.google.com/p/ngpsvcanal/
>        http://code.google.com/p/chord-ns3/
>        http://code.google.com/p/tmix-ns3/
>        http://code.google.com/p/ns3-wireless-planning/
>        http://code.google.com/p/wwplan/
>        http://code.google.com/p/dtnsimulationns3/
>        http://code.google.com/p/ns3/
>        http://code.google.com/p/ns3-debian/

 Cool :)


> --
> Mathieu Lacage <mathieu.lacage at gmail.com>
> 



From boyko at iitp.ru  Tue Nov 16 08:57:46 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Tue, 16 Nov 2010 19:57:46 +0300
Subject: [Ns-developers] Data collection framework API proposal
Message-ID: <1289926666.3126.37.camel@boyko>

  Hi,

  Inspired by last developer meeting discussion we'd like to propose a
vision of Data Collection Framework architecture and proof of concept
implementation. Implementation can be found here:
http://codereview.appspot.com/3105042 and some description is here:
http://www.nsnam.org/wiki/index.php/Data_Collection_Framework#Arch_and_API_Proposal

  We hope that proposed arch is flexible enough to satisfy all known
requirements and user visible API is convenient. We will be happy to see
any comments, suggestions and ideas (and patches). 

  Best regards,
  Pavel and Kirill 


From slonik.az at gmail.com  Mon Nov 15 09:43:13 2010
From: slonik.az at gmail.com (Leo Razoumov)
Date: Mon, 15 Nov 2010 12:43:13 -0500
Subject: [Ns-developers] LTE dev coordination
In-Reply-To: <4CE14D43.8070101@cttc.es>
References: <4CE14D43.8070101@cttc.es>
Message-ID: <AANLkTinbFcBM9DH8NHr6As1BQ8-t47+GTXcvgNu4zWaA@mail.gmail.com>

On Mon, Nov 15, 2010 at 10:09, Nicola Baldo <nbaldo at cttc.es> wrote:
>
> Hi all,
>
> after the successful GSoC work on LTE by Giuseppe, I heard that a few other
> people/groups started working on the LTE code. Also at our institution
> (CTTC) we just started some development. I think it is of great interest for
> all of us working on LTE to coordinate, in order to benefit of each other's
> effort. So I'd like to ask everybody interested in LTE development to speak
> now and briefly describe their interests and activities.
>
> To start with, I will explain what we are working on at CTTC.
> We are interested on distributed Radio Resource Management and Mobility
> Management. To begin with, the development will be done by myself and Marco
> Miozzo, and we will focus on the following enhancements:
> ?- adding UL link adaptation
> ?- modeling inter-cell interference
> ?- reworking the RRM/scheduling API
>
> So, if anyone interested in LTE development could come up with a short
> description on their current or planned activity, similar to what I provided
> above, it would be very much appreciated.
>
> Regards,
>
> Nicola
>

Hi folks,
I am interested in LTE system level performance for both voice and
data. Areas of my contributions could be MIMO, PHY model abstractions,
scheduling models, mobility and traffic models. I have been doing
simulations for more than a decade but I am new to NS-3 (and never
used ns-2).

--Leo--


From tomh at tomh.org  Tue Nov 16 21:17:19 2010
From: tomh at tomh.org (Tom Henderson)
Date: Tue, 16 Nov 2010 21:17:19 -0800
Subject: [Ns-developers] Bug 1012
In-Reply-To: <AANLkTi=S2WS18orZ5xJLkJ-V-xqp_R2EhL6MwZcqre3k@mail.gmail.com>
References: <AANLkTi=S2WS18orZ5xJLkJ-V-xqp_R2EhL6MwZcqre3k@mail.gmail.com>
Message-ID: <4CE3655F.5010004@tomh.org>

On 11/16/2010 01:58 AM, Andrea Sacco wrote:
> Hello everybody,
> I've proposed a patch for the bug 1012. I've posted it to the bugzilla bug
> page.
> If someone can look at the patch (it is a minor change to the code), to let
> me mark the bug as solved, it would be great.
>
> Thanks,
> Andrea


I passed this over to Leonard for review, and I created a new "uan" 
product in the tracker so that these are assigned automatically in the 
future.

- Tom

From g.piro at poliba.it  Wed Nov 17 02:44:54 2010
From: g.piro at poliba.it (Giuseppe Piro)
Date: Wed, 17 Nov 2010 11:44:54 +0100
Subject: [Ns-developers] Ns-developers Digest, Vol 48, Issue 11
In-Reply-To: <mailman.5.1289869202.4074.ns-developers@isi.edu>
References: <mailman.5.1289869202.4074.ns-developers@isi.edu>
Message-ID: <AANLkTi=wEXEBtKuUG1+3sV6KS-X1-K9FAEbhu4XtgKij@mail.gmail.com>

Dear Nicola and all ns-3 users,

I and other people in my istitution (DEE - Politecnico di Bari) are working
on LTE.

We intend to continue the development of the LTE module, focusing mainly on
the MAC layer (RRM, scheduling, AMC etc...). However, other minor important
aspects of LTE can be addressed in the future.

We have matured an high experience on this topics and we think to give an
important contribute to the ns-3 community.

Actually, I'm spending all my efforts to prepare a complete LTE module for
the merging with the ns-3-dev.
After this, I would like to propose myself as maintainer (or one of them) of
this module

Finally, I would like to thank all people that will work on LTE, starting
from Nicola Baldo  and Marco Miozzo (who given me an important support
beginning from the latest GSoC).

Best Reagrds,

Giuseppe






> Hi all,
>
> after the successful GSoC work on LTE by Giuseppe, I heard that a few
> other people/groups started working on the LTE code. Also at our
> institution (CTTC) we just started some development. I think it is of
> great interest for all of us working on LTE to coordinate, in order to
> benefit of each other's effort. So I'd like to ask everybody interested
> in LTE development to speak now and briefly describe their interests and
> activities.
>
> To start with, I will explain what we are working on at CTTC.
> We are interested on distributed Radio Resource Management and Mobility
> Management. To begin with, the development will be done by myself and
> Marco Miozzo, and we will focus on the following enhancements:
>  - adding UL link adaptation
>  - modeling inter-cell interference
>  - reworking the RRM/scheduling API
>
> So, if anyone interested in LTE development could come up with a short
> description on their current or planned activity, similar to what I
> provided above, it would be very much appreciated.
>
> Regards,
>
> Nicola
>
>
>
> ------------------------------
>
> _______________________________________________
> Ns-developers mailing list
> Ns-developers at isi.edu
> http://mailman.isi.edu/mailman/listinfo/ns-developers
>
>
> End of Ns-developers Digest, Vol 48, Issue 11
> *********************************************
>



-- 
Giuseppe Piro
Ph.D. Student
DEE - Politecnico di Bari
v. Orabona 4, 70125 - Bari, Italy
e-mail: g.piro at poliba.it
Phone: +39 0805963301
Web: http://telematics.poliba.it/piro

From fabinader at gmail.com  Wed Nov 17 03:39:50 2010
From: fabinader at gmail.com (Fuad Abinader)
Date: Wed, 17 Nov 2010 07:39:50 -0400
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1289926666.3126.37.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
Message-ID: <AANLkTin_KDg=-mFbqnW-P5horsaWEzrMF_SN_VLpOZRb@mail.gmail.com>

Hi Pavel,

   I was a happy user of ns2measure framework, and I was looking exactly for
a tool like that for ns-3. I saw on your Wiki page that you reference both
ns2measure and previous ns-3 work on statistical framework (i.e.
http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation).
So my questions are a) how similar / complimentary / different to both
ns2measure and previous ns-3 work is your work? and b) would it be correct
to say that your work "fills the gaps" mentioned as "To-Do" in
http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation?

Regards,

Fuad Abinader

2010/11/16 Pavel Boyko <boyko at iitp.ru>

>  Hi,
>
>  Inspired by last developer meeting discussion we'd like to propose a
> vision of Data Collection Framework architecture and proof of concept
> implementation. Implementation can be found here:
> http://codereview.appspot.com/3105042 and some description is here:
>
> http://www.nsnam.org/wiki/index.php/Data_Collection_Framework#Arch_and_API_Proposal
>
>  We hope that proposed arch is flexible enough to satisfy all known
> requirements and user visible API is convenient. We will be happy to see
> any comments, suggestions and ideas (and patches).
>
>  Best regards,
>  Pavel and Kirill
>
>

From boyko at iitp.ru  Thu Nov 18 02:17:58 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Thu, 18 Nov 2010 13:17:58 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <AANLkTin_KDg=-mFbqnW-P5horsaWEzrMF_SN_VLpOZRb@mail.gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTin_KDg=-mFbqnW-P5horsaWEzrMF_SN_VLpOZRb@mail.gmail.com>
Message-ID: <1290075478.23459.32.camel@boyko>

  Hi, Fuad,

>    I was a happy user of ns2measure framework, and I was looking
> exactly for a tool like that for ns-3. I saw on your Wiki page that
> you reference both ns2measure and previous ns-3 work on statistical
> framework (i.e.
> http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation ). So my questions are a) how similar / complimentary / different to both ns2measure and previous ns-3 work is your work? 

  Here we propose a data collection subsystem only. You can treat it as
an advanced analog of Stat singleton of the ns2measure. The rest of
ns2measure functionality is supposed to be implemented on top of data
collection framework, Felipe Perrone leads that work.

  Comparing to ns2measure data collection subsystem we propose much more
flexible solution with emphasis on 
 1) decoupling models, data collection and data storage
 2) flexible on-line data reduction / normalization capabilities
 3) supporting collection of arbitrary typed data (e.g. packets,
headers, routing tables, visualization events, etc.)
 4) supporting several simultaneously running data collectors

  Comparing to current ns-3 stats framework created by Joe Kopena we add
 1) time series collection (actually scalars are treated as a degenerate
case of time series)
 2) capability to stack data reduction / processing modules ("probes")
in trees to implement some complex on-line data reduction. 

> and b) would it be correct to say that your work "fills the gaps"
> mentioned as "To-Do" in
> http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation ?

  Basically yes, except of "Provisions in the data collectors for
terminating runs, i.e. when a threshold or confidence is met" which is
treated as higher level functionality. At the same time we propose a
concept-proof implementation only and for now it lacks many features of
existing stats framework.  

  Best regards,
  Pavel


From fabinader at gmail.com  Thu Nov 18 06:54:41 2010
From: fabinader at gmail.com (Fuad Abinader)
Date: Thu, 18 Nov 2010 10:54:41 -0400
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1290075478.23459.32.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTin_KDg=-mFbqnW-P5horsaWEzrMF_SN_VLpOZRb@mail.gmail.com>
	<1290075478.23459.32.camel@boyko>
Message-ID: <AANLkTimpRf1H_RcQmDL7TB16uyxRJn-WyEtDLyHxSEL_@mail.gmail.com>

Hi Pavel,

   Thank for your prompt answer. I'm definitely going to try it when
it is finished and becomes incorporated to ns-3 code.

   Just one remaining question: do you know if Felipe Perrone's
implementation will be based somehow on Joe Kopena's framework, or
instead will be a completely new one? (I never used Joe Kopena's
framework, I'm just a newbie ns-3 user eager to use any of these)

2010/11/18 Pavel Boyko <boyko at iitp.ru>
>
> ?Hi, Fuad,
>
> > ? ?I was a happy user of ns2measure framework, and I was looking
> > exactly for a tool like that for ns-3. I saw on your Wiki page that
> > you reference both ns2measure and previous ns-3 work on statistical
> > framework (i.e.
> > http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation ). So my questions are a) how similar / complimentary / different to both ns2measure and previous ns-3 work is your work?
>
> ?Here we propose a data collection subsystem only. You can treat it as
> an advanced analog of Stat singleton of the ns2measure. The rest of
> ns2measure functionality is supposed to be implemented on top of data
> collection framework, Felipe Perrone leads that work.
>
> ?Comparing to ns2measure data collection subsystem we propose much more
> flexible solution with emphasis on
> ?1) decoupling models, data collection and data storage
> ?2) flexible on-line data reduction / normalization capabilities
> ?3) supporting collection of arbitrary typed data (e.g. packets,
> headers, routing tables, visualization events, etc.)
> ?4) supporting several simultaneously running data collectors
>
> ?Comparing to current ns-3 stats framework created by Joe Kopena we add
> ?1) time series collection (actually scalars are treated as a degenerate
> case of time series)
> ?2) capability to stack data reduction / processing modules ("probes")
> in trees to implement some complex on-line data reduction.
>
> > and b) would it be correct to say that your work "fills the gaps"
> > mentioned as "To-Do" in
> > http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation ?
>
> ?Basically yes, except of "Provisions in the data collectors for
> terminating runs, i.e. when a threshold or confidence is met" which is
> treated as higher level functionality. At the same time we propose a
> concept-proof implementation only and for now it lacks many features of
> existing stats framework.
>
> ?Best regards,
> ?Pavel
>


From boyko at iitp.ru  Thu Nov 18 07:01:25 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Thu, 18 Nov 2010 18:01:25 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <AANLkTimpRf1H_RcQmDL7TB16uyxRJn-WyEtDLyHxSEL_@mail.gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTin_KDg=-mFbqnW-P5horsaWEzrMF_SN_VLpOZRb@mail.gmail.com>
	<1290075478.23459.32.camel@boyko>
	<AANLkTimpRf1H_RcQmDL7TB16uyxRJn-WyEtDLyHxSEL_@mail.gmail.com>
Message-ID: <1290092485.1743.36.camel@boyko>

On Thu, 2010-11-18 at 10:54 -0400, Fuad Abinader wrote:
> Hi Pavel,
> 
>    Thank for your prompt answer. I'm definitely going to try it when
> it is finished and becomes incorporated to ns-3 code.
> 
>    Just one remaining question: do you know if Felipe Perrone's
> implementation will be based somehow on Joe Kopena's framework, or
> instead will be a completely new one? (I never used Joe Kopena's
> framework, I'm just a newbie ns-3 user eager to use any of these)

  As far as I know currently they work on the brand new python execution
manager + a number of XML based languages for model & experiment
definition. 

  Pavel 




From mathieu.lacage at gmail.com  Fri Nov 19 00:38:02 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Fri, 19 Nov 2010 09:38:02 +0100
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1289926666.3126.37.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
Message-ID: <AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>

pavel,

On Tue, Nov 16, 2010 at 17:57, Pavel Boyko <boyko at iitp.ru> wrote:
> ?Inspired by last developer meeting discussion we'd like to propose a
> vision of Data Collection Framework architecture and proof of concept
> implementation. Implementation can be found here:
> http://codereview.appspot.com/3105042 and some description is here:
> http://www.nsnam.org/wiki/index.php/Data_Collection_Framework#Arch_and_API_Proposal
>
> ?We hope that proposed arch is flexible enough to satisfy all known
> requirements and user visible API is convenient. We will be happy to see
> any comments, suggestions and ideas (and patches).

Felipe and I met this week and dsicussed this topic some more to try
to come up with a proposal. I reviewed quickly your proposed code.
Comments below.

1) We are in violent agreement that the following make sense:
  - a set of data collection objects which derive from ns3::Object to
get attribute configuration.
  - a tree of data collection objects interconnected together so that
data flows from use sources to storage/processing

2) It is unclear to me how you plan to deal with the case where I want
to just collect the data generated by a user trace source. Do you
expect that the probe would store all the user-generated values and
issue them to the Output function upon "Stop" ? Or should it stream
the data through its Output function upon every new sample ?

3) I feel that it would be nice to have a more concrete representation
of the data collection tree (which is inherently static throughout the
simulation). To be more specific, what felipe and I envision is a
Probe class (which we called DataCollector) along the lines of:

class Collector : public Object
{
public:
  typedef std::list<Ptr<Collector> >::const_iterator ChildrenIterator;

  static TypeId GetTypeId () {
    static TypdId tid = TypeIf (...)
      .AddAttribute ("Children", "list of children",
                   ObjectVectorValue (),
                   MakeObjectVectorAccessor (&Collector::m_children),
                   MakeObjectVectorChecker<Collector> ()
     ;
    return tid;
  }
  Collector ();
  void SetParent (Ptr<Collector> collector);
  void AddChild (Ptr<Collector> collector);
  ChildrenIterator BeginChildren (void) const;
  ChildrenIterator EndChildren (void) const;

private:
  virtual void DoDispose (void);
  Ptr<Collector> m_parent;
  std::list<Ptr<Collector> > m_children;
};

i.e., the advantage here is that the data collection tree is encoded
in the metadata database which means that you should be able to write
something like this to configure the size of the averaging window used
by an averaging node in the tree:

Config::Set ("/DataStorage/x/Children/y/Children/z/SampleWindowSize",
StringValue ("10));

4) I see that you have used the trace source/sink mechanism to push
data throughout the collection tree. This is a pretty neat idea but I
feel it is lacking in compile-time checking. i.e., it's going to be
really hard to make sure that you give both the right paths and the
right sink signatures for each source. While this is impossible to
avoid for the 'leaf' nodes (i.e., the nodes that collect data from the
user models through trace sources), we could force a number of basic
data types in the Collector base class:

class Collector : public Object
{
public:
  // called whenever new data is ready.
  virtual void CollectInteger (uint32_t id, int64_t value) = 0;
  virtual void CollectFloat (uint32_t id, double value) = 0;
};

5) Similarly, I see that you have used a start/stop time mechanism to
connect/disconnect to/from the trace sources and avoid an enabled
flag. It seems to me that it would be much simpler to connect all the
time and just enable/disable with a bool whenever you need to. This is
related to item 4) above which attempts to avoid using the source/sink
mechanism except for the leaf nodes.

6) I understand that 'Stop' has extra 'flushing' semantics to make
sure that data that was accumulated/reduced is sent to the storage
collector. It would be nice to separate the 'flushing' from the act of
'stopping' to collect samples so that users who wish to do so can
start/stop collecting, and then when the simulation completes, flush
everything. i.e.,

class Collector
{
public:
  virtual void Flush (void) = 0;
};

The 'storage' collector (i.e., the Csv class you use) would then be
responsible for scheduling an event with Simulator::Destroy to call
flush on all its children recursively.

7) the Example::SetupDataCollection example code looks horrible as a
user interface. We need to come up with a simpler user model but I
don't have any good idea about this right now.

I did not have time to come up with a complete proposal and an actual
implementation but I feel that it was more important to give you early
feedback on what we are converging and diverging upon.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>


From boyko at iitp.ru  Fri Nov 19 02:09:00 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Fri, 19 Nov 2010 13:09:00 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
Message-ID: <1290161340.6749.109.camel@boyko>

  Hi, Mathieu,

> I did not have time to come up with a complete proposal and an actual
> implementation but I feel that it was more important to give you early
> feedback on what we are converging and diverging upon.

  Yes, this is exactly what I am looking for. Thank you!

> 1) We are in violent agreement that the following make sense:
>   - a set of data collection objects which derive from ns3::Object to
> get attribute configuration.
>   - a tree of data collection objects interconnected together so that
> data flows from use sources to storage/processing

  Very good. Next step is to agree on names of these objects (probes vs.
collectors and collectors vs. storage :)

> 2) It is unclear to me how you plan to deal with the case where I want
> to just collect the data generated by a user trace source. Do you
> expect that the probe would store all the user-generated values and
> issue them to the Output function upon "Stop" ? Or should it stream
> the data through its Output function upon every new sample ?

  That depends on "user trace source" signature. If this is signature is
directly supported by used Collector (DataStorage class as you knew it
before ;), e.g. (time, double) pairs, -- user trace source can be
directly connected to the collector avoiding extra objects:

[Model trace source (time, double)] ----> [data collector] --> (DB)

  If user trace source signature is not supported by the collector, say,
(time, Ipv4Header) and I want to store destination addresses -- the
probe object is needed to normalize data: 

[Model trace source (time, Ipv4Header)] --> [probe, Output trace source
(time, string)] ----> [data collector] --> (DB)

  Anyway, probe is not supposed to buffer data, only convert it to the
supported format. 

> 3) I feel that it would be nice to have a more concrete representation
> of the data collection tree (which is inherently static throughout the
> simulation). To be more specific, what felipe and I envision is a
> Probe class (which we called DataCollector) along the lines of:

  I am not sure that restricting to static collection setup is good.

  First, it seems to be convenient to create data collection/reduction
tree runtime, e.g. parsing some user-friendly XML generated by some
user-friednly GUI tool.  

  Second, it can be useful to _modify_ data collection tree runtime,
e.g. FlowMonitor can automatically create new probes detecting new data
flows. This way user can have per-flow data in the output database even
if flows are not known a priori (e.g. some random source/destination
policy). 

  Also note that data collection tree is not necessarily a tree :) In
the example we have published TX and RX counter probes feed output
database _and_ divider probe at the same time -- this is not a tree.

> i.e., the advantage here is that the data collection tree is encoded
> in the metadata database which means that you should be able to write
> something like this to configure the size of the averaging window used
> by an averaging node in the tree:
> 
> Config::Set ("/DataStorage/x/Children/y/Children/z/SampleWindowSize",
> StringValue ("10));

  StringValue("10") looks like a compromise ;)

  Anyway, data collection tree (net?) traversal from Collector to model
trace sources seems to be easy to implement in any approach. 

> 4) I see that you have used the trace source/sink mechanism to push
> data throughout the collection tree. This is a pretty neat idea but I
> feel it is lacking in compile-time checking. i.e., it's going to be
> really hard to make sure that you give both the right paths and the
> right sink signatures for each source. While this is impossible to
> avoid for the 'leaf' nodes (i.e., the nodes that collect data from the
> user models through trace sources), we could force a number of basic
> data types in the Collector base class:

  See above about runtime data collection setup. I don't believe that
static compile time experiment description we use today is a viable
strategy. M.b. we just need better diagnostic messages for runtime
checking?

  Connecting probes using trace sources allows me to restrict data types
(trace source signatures) on the outputs of the data collection tree
only and these restrictions can be different for different collectors
(databases) used.

> 5) Similarly, I see that you have used a start/stop time mechanism to
> connect/disconnect to/from the trace sources and avoid an enabled
> flag. It seems to me that it would be much simpler to connect all the
> time and just enable/disable with a bool whenever you need to. 

  I see no difference, especially If we want to support runtime probe
creation/connection. (And I see no reason to not support this).

> 6) I understand that 'Stop' has extra 'flushing' semantics to make
> sure that data that was accumulated/reduced is sent to the storage
> collector. It would be nice to separate the 'flushing' from the act of
> 'stopping' to collect samples so that users who wish to do so can
> start/stop collecting, and then when the simulation completes, flush
> everything. i.e.,

  Agree.

> The 'storage' collector (i.e., the Csv class you use) would then be
> responsible for scheduling an event with Simulator::Destroy to call
> flush on all its children recursively.

  By the way, it is important for me to have all output data flushed as
much as possible when application crashes (using e.g. NS_FATAL_ERROR).
Can we extend NS_FATAL_ERROR to notify all interested objects to flush
their state?  

> 7) the Example::SetupDataCollection example code looks horrible as a
> user interface. We need to come up with a simpler user model but I
> don't have any good idea about this right now.

  This is supposed to be low level API used by helpers to provide some
user friendly functions. As low level API it does its job: I create,
setup and connect data probes (to models, to other probes and to the
data collector) in few lines of code.  

  Pavel



From mathieu.lacage at gmail.com  Fri Nov 19 04:36:05 2010
From: mathieu.lacage at gmail.com (Mathieu Lacage)
Date: Fri, 19 Nov 2010 13:36:05 +0100
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1290161340.6749.109.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
Message-ID: <AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>

On Fri, Nov 19, 2010 at 11:09, Pavel Boyko <boyko at iitp.ru> wrote:

>> 1) We are in violent agreement that the following make sense:
>> ? - a set of data collection objects which derive from ns3::Object to
>> get attribute configuration.
>> ? - a tree of data collection objects interconnected together so that
>> data flows from use sources to storage/processing
>
> ?Very good. Next step is to agree on names of these objects (probes vs.
> collectors and collectors vs. storage :)

It looks like we don't agree on the tree idea though since you mention
below that you attempt to support a data collection graph instead of a
tree. I am worried this is a bit too complex for the use-cases I have
in mind.

[for the names, I can't care less]

>> 3) I feel that it would be nice to have a more concrete representation
>> of the data collection tree (which is inherently static throughout the
>> simulation). To be more specific, what felipe and I envision is a
>> Probe class (which we called DataCollector) along the lines of:
>
> ?I am not sure that restricting to static collection setup is good.
>
> ?First, it seems to be convenient to create data collection/reduction
> tree runtime, e.g. parsing some user-friendly XML generated by some
> user-friednly GUI tool.

This is exactly the use-case felipe and I discussed: it seems to me
that using trace sources is not sufficient to be able to serialize and
reconstruct the data collection graph later. Using a set of explicit
children and parent attributes allows us to parse easily the tree
automatically to serialize it and reconstruct it later.

> ?Second, it can be useful to _modify_ data collection tree runtime,
> e.g. FlowMonitor can automatically create new probes detecting new data
> flows. This way user can have per-flow data in the output database even
> if flows are not known a priori (e.g. some random source/destination
> policy).

Felipe and I discussed this but we felt that this was a very unlikely
scenario and that it would be ok to tell users to setup the graph
first and to enable/disable collection whenever they want.

> ?Also note that data collection tree is not necessarily a tree :) In
> the example we have published TX and RX counter probes feed output
> database _and_ divider probe at the same time -- this is not a tree.

My feeling is that being able to send the same data to multiple
listeners is useful only at the leaves which indeed is already
supported by the existing trace source framework but I feel that we
should try to come up with something simpler.

> ?Anyway, data collection tree (net?) traversal from Collector to model
> trace sources seems to be easy to implement in any approach.

It does not seem easy to do without explicit pointers from parent to
children. I can see how you could do it without it but it's ... eek...
painful.

>> 4) I see that you have used the trace source/sink mechanism to push
>> data throughout the collection tree. This is a pretty neat idea but I
>> feel it is lacking in compile-time checking. i.e., it's going to be
>> really hard to make sure that you give both the right paths and the
>> right sink signatures for each source. While this is impossible to
>> avoid for the 'leaf' nodes (i.e., the nodes that collect data from the
>> user models through trace sources), we could force a number of basic
>> data types in the Collector base class:
>
> ?See above about runtime data collection setup. I don't believe that
> static compile time experiment description we use today is a viable

Well, our simulation topology is static and this was clearly an
important decision we made a long time ago so, from that perspective,
saying that the data collection tree is static appears fairly
reasonable. So, yes, certain things are not possible or painful to do
with a static tree but this is much simpler to implement, and manage
and should address most use-cases. Do you have a specific scenario in
mind that is critical and that would not work given a static tree ? To
be clear, I suspect that it's always easy to add new nodes to the tree
at runtime (just like it's possible to create new ns3::Node objects at
runtime), but removing them is not so easy.

> strategy. M.b. we just need better diagnostic messages for runtime
> checking?

That is unlikely to happen though given the way C++ works.

> ?Connecting probes using trace sources allows me to restrict data types
> (trace source signatures) on the outputs of the data collection tree
> only and these restrictions can be different for different collectors
> (databases) used.

I understand this but I feel that this is gives too much freedom and
complexifies considerably the overall structure. i.e., this work
started from a simple observation: the trace source/sink thing is very
flexible and allows you to do anything you want (hey, it allowed you
to build the fancy proposal you made) but we would like to make
available something that is easier to use based on the assumption that
those who can't use the simpler thing can always go and use the
low-level trace source/sink facility. So, simplifying the data
collection framework is not taking features away from you: it's merely
trying to optimize for the simple use-cases.

>> 5) Similarly, I see that you have used a start/stop time mechanism to
>> connect/disconnect to/from the trace sources and avoid an enabled
>> flag. It seems to me that it would be much simpler to connect all the
>> time and just enable/disable with a bool whenever you need to.
>
> ?I see no difference, especially If we want to support runtime probe
> creation/connection. (And I see no reason to not support this).

See my comment above.

>
>> The 'storage' collector (i.e., the Csv class you use) would then be
>> responsible for scheduling an event with Simulator::Destroy to call
>> flush on all its children recursively.
>
> ?By the way, it is important for me to have all output data flushed as
> much as possible when application crashes (using e.g. NS_FATAL_ERROR).
> Can we extend NS_FATAL_ERROR to notify all interested objects to flush
> their state?

We already do something like this for pcapwriter so, yes, we should do
it for this too.

>
>> 7) the Example::SetupDataCollection example code looks horrible as a
>> user interface. We need to come up with a simpler user model but I
>> don't have any good idea about this right now.
>
> ?This is supposed to be low level API used by helpers to provide some
> user friendly functions. As low level API it does its job: I create,
> setup and connect data probes (to models, to other probes and to the
> data collector) in few lines of code.

Agreed, but we need to come up with something nicer to use.

>From my perspective, the goal here is not really to provide more
features: it is to make it easier to trace data and store it so, I my
main objective is trying to come up with something that is simple to
understand and reason about from a user perspective.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage at gmail.com>


From gjcarneiro at gmail.com  Fri Nov 19 04:49:42 2010
From: gjcarneiro at gmail.com (Gustavo Carneiro)
Date: Fri, 19 Nov 2010 12:49:42 +0000
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1290161340.6749.109.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
Message-ID: <AANLkTim_4CHr1LHEJ0w8FJ1p-=-LrK2n_yBmn7pRmXN1@mail.gmail.com>

On Fri, Nov 19, 2010 at 10:09, Pavel Boyko <boyko at iitp.ru> wrote:
[...]

>  Second, it can be useful to _modify_ data collection tree runtime,
> e.g. FlowMonitor can automatically create new probes detecting new data
> flows. This way user can have per-flow data in the output database even
> if flows are not known a priori (e.g. some random source/destination
> policy).
>

Since you mention Flow Monitor, a small correction.  Flow Monitor probes are
created a priori, on all nodes.  However, Flow Monitor probes (FlowProbes)
are bound to a certain type of flows, not one flow specifically.  For
instance, Ipv4FlowProbe captures any kind of 5-tuple IP/UDP/TCP flow, but it
does not use one probe per flow.  Thus, Flow Monitor can monitor flows
dynamically of a certain type, but you don't need to tell it beforehand what
are the flow instances of that type, it detects them automatically.  In
retrospect, I still believe it was a very good idea.

I'm a bit biased to say this, but it would be nice if the new data
collection framework could approach the simplicity of use of Flow Monitor.

[...]

-- 
Gustavo J. A. M. Carneiro
INESC Porto, UTM, WiN, http://win.inescporto.pt/gjc
"The universe is always one step beyond logic." -- Frank Herbert

From boyko at iitp.ru  Fri Nov 19 05:03:58 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Fri, 19 Nov 2010 16:03:58 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <AANLkTim_4CHr1LHEJ0w8FJ1p-=-LrK2n_yBmn7pRmXN1@mail.gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
	<AANLkTim_4CHr1LHEJ0w8FJ1p-=-LrK2n_yBmn7pRmXN1@mail.gmail.com>
Message-ID: <1290171838.6749.124.camel@boyko>

On Fri, 2010-11-19 at 12:49 +0000, Gustavo Carneiro wrote:
> On Fri, Nov 19, 2010 at 10:09, Pavel Boyko <boyko at iitp.ru> wrote:
> [...] 
>          Second, it can be useful to _modify_ data collection tree
>         runtime,
>         e.g. FlowMonitor can automatically create new probes detecting
>         new data
>         flows. This way user can have per-flow data in the output
>         database even
>         if flows are not known a priori (e.g. some random
>         source/destination
>         policy).
> 
> 
> Since you mention Flow Monitor, a small correction.  Flow Monitor
> probes are created a priori, on all nodes.  

  We use word "probe" differently. In the context of data collection
"probe" is a single data source (~ time series in the output database)
and if I want to see, say, per-flow delay(time) for all flows I need to
create single data collection probe for every flow. That's why I said
that FlowMonitor "can create new probe" when it detects new flow.    

> I'm a bit biased to say this, but it would be nice if the new data
> collection framework could approach the simplicity of use of Flow
> Monitor.

  I am not sure that this is possible. Data collection framework should
be low level mechanism, I am not sure that it can be simply-used and
flexible enough at the same time. 

  Pavel 



From boyko at iitp.ru  Fri Nov 19 06:13:13 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Fri, 19 Nov 2010 17:13:13 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
	<AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>
Message-ID: <1290175993.6749.194.camel@boyko>

  Hi, Mathieu, 

  It seems that the only thing we really disagree is using trace sources
to pass data between probes and from probes to collectors. Everything
else can be combined. 

  Even this point (trace sources vs. explicit data push) is not very
important, finally this mechanism will be hidden from users. The only
remaining question is the complexity of probes implementations (there
will be dozens of them clearly). Somebody should re-implement our ping
example using explicit parent/child relations and explicit typed data
push in the collection tree. Current trace source based implementation
is extremely compact. 

On Fri, 2010-11-19 at 13:36 +0100, Mathieu Lacage wrote:
> It looks like we don't agree on the tree idea though since you mention
> below that you attempt to support a data collection graph instead of a
> tree. I am worried this is a bit too complex for the use-cases I have
> in mind.

  No, I agree that trees are simpler to use and I didn't try to
explicitly support arbitrary data collection DAG. This comes out for
free if use trace sources. 

> This is exactly the use-case felipe and I discussed: it seems to me
> that using trace sources is not sufficient to be able to serialize and
> reconstruct the data collection graph later. 

  Do we really need a "serialize" part of this? I had a GUI writing XML
and ns-3 application reading them in mind. This is easy.
At the same time I do agree, that _check_ this XML for source/sink
signature match before instantiation is impossible. But you have already
mentioned that we will need to use models trace sources anyway, so data
collection tree can't be checked anyway. 

> Using a set of explicit
> children and parent attributes allows us to parse easily the tree
> automatically to serialize it and reconstruct it later.

  Passing data between probes using trace sources can be combined with
explicit parent/child relations if you need them -- why not? Anyway this
functionality will be hidden in the parent Probe class -- this will just
make it more complex. But this is still simpler than have two data
passing mechanisms: one for model -> probe, and another one for probe ->
probe and probe -> collector data flows. 

> Felipe and I discussed this but we felt that this was a very unlikely
> scenario and that it would be ok to tell users to setup the graph
> first and to enable/disable collection whenever they want.

  In this case you should describe how to collect, say, histogram of
per-flow average packet delay for a priori unknown number of data flows.
Let it be use case "random VoIP flows". 

> My feeling is that being able to send the same data to multiple
> listeners is useful only at the leaves which indeed is already
> supported by the existing trace source framework but I feel that we
> should try to come up with something simpler.

  Do you like an idea to have a dedicated data collector for transient
detection and another one for runtime termination? If yes, it can be
useful to send single data stream to 1) output database 2) moving
average probe -> transient detector 3) stddev probe -> runtime detector.
Let it be use case "on-line transient detection and runtime termination
on top of data collection". 

> Well, our simulation topology is static and this was clearly an
> important decision we made a long time ago so, from that perspective,
> saying that the data collection tree is static appears fairly
> reasonable. So, yes, certain things are not possible or painful to do
> with a static tree but this is much simpler to implement, and manage
> and should address most use-cases. Do you have a specific scenario in
> mind that is critical and that would not work given a static tree ? To
> be clear, I suspect that it's always easy to add new nodes to the tree
> at runtime (just like it's possible to create new ns3::Node objects at
> runtime), but removing them is not so easy.

  I can agree on supporting adding probe runtime and not supporting
remove probe. 

> I understand this but I feel that this is gives too much freedom and
> complexifies considerably the overall structure. i.e., this work
> started from a simple observation: the trace source/sink thing is very
> flexible and allows you to do anything you want (hey, it allowed you
> to build the fancy proposal you made) but we would like to make
> available something that is easier to use based on the assumption that
> those who can't use the simpler thing can always go and use the
> low-level trace source/sink facility. So, simplifying the data
> collection framework is not taking features away from you: it's merely
> trying to optimize for the simple use-cases.

  Agree.

> We already do something like this for pcapwriter so, yes, we should do
> it for this too.

  Good! 

> Agreed, but we need to come up with something nicer to use.

  I see two approaches to user-visible data collection setup. One is to
describe/instantiate whole data collection tree (e.g. using XML, or some
simple code). Another one -- to provide EnableDataCollection
(Ptr<Collector>) methods in existing helpers, much like EnablePcap() is
implemented. E.g. WifiHelper::EnableDataCollection() will add some
default wifi-related data probes to the data collector and
FlowMonitor::EnableDataCollection() will output current flowmon
statistics to the output database. Both approaches can be combined for
sure. 

> >From my perspective, the goal here is not really to provide more
> features: it is to make it easier to trace data and store it so, I my
> main objective is trying to come up with something that is simple to
> understand and reason about from a user perspective.

  Agree, but I also find it important to (try to) design data collection
framework flexible enough to be _the only_ data collection mechanism
used by all users.

  Pavel



From yoshiyaz at gmail.com  Thu Nov 18 20:56:08 2010
From: yoshiyaz at gmail.com (Yoshihiko)
Date: Fri, 19 Nov 2010 13:56:08 +0900
Subject: [Ns-developers] patch of AODV routing protocol
Message-ID: <77CB87A6144B6Fyoshiyaz@gmail.com>

Hello all,

I post patch which corrects some problems of AODV.
I will be glad if this is useful.

Problem is shown below. Patch is against ns-3.9.

(1) MaxQueueLen and MaxQueueTime attributes can't change.
(2) Neighbor's sequence number is always invalid at disabling 
    HELLO.
(3) Intermediate node reply at invalid sequence number.
(4) Route loop is made from RREQ.
(5) First data packet is sent to bad route.

Regards,
Yoshihiko Yazawa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aodv-problem.patch
Type: application/octet-stream
Size: 7471 bytes
Desc: not available
Url : http://mailman.isi.edu/pipermail/ns-developers/attachments/20101119/2e35e929/aodv-problem-0001.obj

From iftee_1234 at yahoo.com  Fri Nov 19 04:13:26 2010
From: iftee_1234 at yahoo.com (Iftekharul Mobin)
Date: Fri, 19 Nov 2010 04:13:26 -0800 (PST)
Subject: [Ns-developers] inject error BER model in wireless network
In-Reply-To: <mailman.0.1290167448.23857.ns-developers@isi.edu>
Message-ID: <474647.63677.qm@web110007.mail.gq1.yahoo.com>

??Hi NS-developers,
?I am trying to inject Bit error model in wireless network 2 nodes node0 source to node1 sink. Problem is that the outputs are coming is quite strange. Then i inserted some print command inside erormodel.cc file and found that the packet size which i am assigning is not used by the program it creates data packet size and control packet size sometimes 0 or sometimes very big number by its own:
?The Tcl script codes is given below:?$ ns research-BER_2_proto_pk-size_data-rate.tcl 2 AODV 100 0.01?
set node_num [lindex $argv 0];set proto_name [lindex $argv 1];set pk_size [lindex $argv 2];set data_rate [lindex $argv 3];set er_rate [lindex $argv 4];set loop_counter [lindex $argv 5];
append file_name $node_num $proto_name ?;set file_name $file_name.$pk_size.$data_rate;set file_name N$file_name.$er_rate.tr;

set val(nn) ? ? ? ? ? ? $node_num ? ? ? ? ? ? ? ? ? ? ? ? ?;# number of mobilenodesset val(rp) ? ? ? ? ? ? $proto_name ? ? ? ? ? ? ? ? ? ? ? ;# routing protocolset val(x) ? ? ? ? ? ? ?1000 ? ? ? ? ? ? ? ? ? ? ? ?;# X dimension of the topographyset val(y) ? ? ? ? ? ? ?1000 ? ? ? ? ? ? ? ? ? ? ? ? ? ;# Y dimension of the topography??# *** Initialize Simulator ***set ns_ ? ? ? ? ? ? ?[new Simulator]

#$ns_ use-newtrace?

# *** Initialize Trace file ***set tracefd ? ? [open $file_name w]$ns_ trace-all $tracefd??# *** set up topography object ***set topo ? ? ? [new Topography]$topo load_flatgrid 1000 1000?# Create ?General Operations Director (GOD) object.?create-god $val(nn)
#random number generator
ns-random 0 ??# configure nodes?? ? ? ?$ns_ node-config -adhocRouting $val(rp) \?? ? ? ? ? ? ? ? ? ? ? ? -llType LL\?? ? ? ? ? ? ? ? ? ? ? ? -macType ? Mac/802_11 ? \?? ? ? ? ? ? ? ? ? ? ? ? -ifqType Queue/DropTail/PriQueue \?? ? ? ? ? ? ? ? ? ? ? ? -ifqLen 500000 \?? ? ? ? ? ? ? ? ? ? ? ? -antType Antenna/OmniAntenna ? \?? ? ? ? ? ? ? ? ? ? ? ? -propType Propagation/TwoRayGround \?? ? ? ? ? ? ? ? ? ? ? ? -phyType Phy/WirelessPhy ?\?? ? ? ? ? ? ? ? ? ? ? ? -channelType Channel/WirelessChannel \?? ? ? ? ? ? ? ? ? ? ? ? -topoInstance $topo \?? ? ? ? ? ? ? ? ? ? ? ? -agentTrace ON \?? ? ? ? ? ? ? ? ? ? ? ? -routerTrace ON \?? ? ? ? ? ? ? ? ? ? ? ? -macTrace OFF \?? ? ? ? ? ? ? ? ? ? ? ? -movementTrace OFF ? ?			?
$ns_ node-config -IncomingErrProc UniformErr -OutgoingErrProc UniformErr

proc UniformErr {} {set err [new ErrorModel] ??$err unit bit$err ranvar [new RandomVariable/Uniform]?
$err set rate_ 0.0005	#$err set rate_ 0.000000022 ?#$err set rate_ 0.05 ?
return $err}
# Create Nodes??? ? ? ?for {set i 0} {$i < $val(nn) } {incr i} {?? ? ? ? ? ? ? ?set node_($i) [$ns_ node]?? ? ? ? ? ? ? ?$node_($i) random-motion 0 ? ? ? ? ? ?;# disable random motion?? ? ? ?}
# Initialize Node Coordinates
for {set i 0} {$i < $val(nn) } {incr i} {	$node_($i) set X_ [expr $i*120];	$node_($i) set Y_ [expr $i*120];	$node_($i) set Z_ 0.0}?
??

# Setup traffic flow between nodes# UDP connections between node_(0) and node_(1)?# Create Constant four Bit Rate Traffic sources?set agent1 [new Agent/UDP]			;# Create UDP Agentset sink [new Agent/Null]			;# Create Loss Monitor Sink in order to be able to trace the number obytes received$ns_ attach-agent $node_(0) $agent1		 ;# Attach Agent to source node$ns_ attach-agent $node_(1) $sink		;# Attach Agent to sink node$ns_ connect $agent1 $sink			;# Connect the nodesset app1 [new Application/Traffic/CBR]		 ;# Create Constant Bit Rate application$app1 set packetSize_ $pk_size			 ? ? ?;# Set Packet Size to 512 bytes#$app1 set rate_ $data_rate			 ? ? ? ?;# Set CBR rate to 200 Kbits/sec$app1 set interval_ $data_rate			 ? ? ? ? ? ;# Set CBR rate to 200 Kbits/sec$app1 attach-agent $agent1			;# Attach Application to agent??? ? ???????# Start Recording at Time 0?$ns_ at 0.1 "$app1 start" ? ? ? ? ? ? ? ? ;# Start transmission at
 time t = 1.4 Sec?# Stop Simulation at Time 80 sec$ns_ at 300.0 "stop"?# Reset Nodes at time 80 sec?for {set i 0} {$i < $val(nn) } {incr i} {?? ?$ns_ at 300.0 "$node_($i) reset";}?# Exit Simulatoion at Time 80.01 sec$ns_ at 300.01 "puts \"NS EXITING...\" ; $ns_ halt"?proc stop {} {?? ? ? ?global ns_ tracefd f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 f11??? ??? ? ? ?# Reset Trace File?? ? ? ?$ns_ flush-trace?? ? ? ?close $tracefd?? ? ???? ? ? ?exit 0}?puts "Starting Simulation..."
$ns_ run
______________________________________________________
The changed code in errormodel.cc is :
int ErrorModel::CorruptBit(Packet* p){	double u, *dptr;	int i;	

	if (firstTime_ && FECstrength_) {		printf("\n\nControl packet size %d and Data packet size %d \n", cntrlpktsize_, datapktsize_ ); // my code		printf("start computing bit error prob for control packet size\n"); // my code						cntrlprb_ = ComputeBitErrProb(cntrlpktsize_);				printf("start computing bit error prob for data packet size\n"); // my code		dataprb_ = ComputeBitErrProb(datapktsize_);		printf("Control pkt probability: %g\n Data pkt probability: %g \n", cntrlprb_, dataprb_ ); // my code						firstTime_ = 0;	}	
	u = ranvar_ ? ranvar_->value() : Random::uniform();
	dptr = (hdr_cmn::access(p)->size() >= datapktsize_) ? dataprb_ : cntrlprb_;?? ? ? ?	int pk_size=hdr_cmn::access(p)->size();
	for (i = 0; i < (FECstrength_ + 2); i++)				if (dptr[i] > u)				{?						break;		}
	return(i);}
double * ErrorModel::ComputeBitErrProb(int size)?{	double *dptr;	int i;
?? ? ? ?dptr = (double *)calloc((FECstrength_ + 2), sizeof(double));
?? ? ? ?for (i = 0; i < (FECstrength_ + 1) ; i++){?		dptr[i] = comb(size, i) * pow(rate_, (double)i) * pow(1.0 - rate_, (double)(size - i));				printf("dptr[%d] = %g , rate = %f and size = %d \n", i, dptr[i],rate_,size);?	}
	// Cumulative probability	for (i = 0; i < FECstrength_ ; i++)?		dptr[i + 1] += dptr[i];		dptr[FECstrength_ + 1] = 1.0;
	//printf("Packet Size = %d\n", size);	for (i = 0; i <(FECstrength_ + 2); i++)		printf("Array values: dptr[%d] = %g\n", i, dptr[i]);?
	return dptr;	}
inline double comb(int n, int k) {	int i;	double sum = 1.0;
	for(i = 0; i < k; i++)?		sum *= (n - i)/(i + 1);
	printf("Value of sum : %f and i=%d and size=%d\n", sum,i,n);
	return sum;}
--------------------------------------------------------------------------
But the output is coming like below:
Control packet size 22993 and Data packet size 0start computing bit error prob for control packet sizeValue of sum : 1.000000 and i=0 and size=22993dptr[0] = 1.01364e-05 , rate = 0.000500 and size = 22993Value of sum : 22993.000000 and i=1 and size=22993dptr[1] = 0.000116592 , rate = 0.000500 and size = 22993Array values: dptr[0] = 1.01364e-05Array values: dptr[1] = 0.000126728Array values: dptr[2] = 1start computing bit error prob for data packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1Array values: dptr[1] = 1Array values: dptr[2] = 1Control pkt probability: 4.83413e-306?Data pkt probability: 3.34433e-306channel.cc:sendUp - Calc highestAntennaZ_ and distCST_highestAntennaZ_ = 1.5, ?distCST_ = 1144.4SORTING LISTS ...DONE!

Control packet size 0 and Data packet size 8902128start computing bit error prob for control packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1Array values: dptr[1] = 1Array values: dptr[2] = 1start computing bit error prob for data packet sizeValue of sum : 1.000000 and i=0 and size=8902128dptr[0] = 0 , rate = 0.000500 and size = 8902128Value of sum : 8902128.000000 and i=1 and size=8902128dptr[1] = 0 , rate = 0.000500 and size = 8902128Array values: dptr[0] = 0Array values: dptr[1] = 0Array values: dptr[2] = 1Control pkt probability: 4.69932e-306?Data pkt probability: 3.70542e-306

Control packet size 0 and Data packet size 0start computing bit error prob for control packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1Array values: dptr[1] = 1Array values: dptr[2] = 1start computing bit error prob for data packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1Array values: dptr[1] = 1Array values: dptr[2] = 1Control pkt probability: 3.75677e-306?Data pkt probability: 1.5855e-306

Control packet size 0 and Data packet size 0start computing bit error prob for control packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1Array values: dptr[1] = 1Array values: dptr[2] = 1start computing bit error prob for data packet sizeValue of sum : 1.000000 and i=0 and size=0dptr[0] = 1 , rate = 0.000500 and size = 0Value of sum : 0.000000 and i=1 and size=0dptr[1] = 0 , rate = 0.000500 and size = 0Array values: dptr[0] = 1			 ? ??Array values: dptr[1] = 1Array values: dptr[2] = 1Control pkt probability: 4.90822e-306?Data pkt probability: 3.72035e-306
?My question is why the data packet and control packet size is coming sometimes 0 or sometimes very big number 8902128 and ?22993. Please help me i am totally lost.
Iftee

--- On Fri, 11/19/10, ns-developers-request at ISI.EDU <ns-developers-request at ISI.EDU> wrote:

From: ns-developers-request at ISI.EDU <ns-developers-request at ISI.EDU>
Subject: confirm 4698b669134ca35ac14459dfe2a577cc00931963
To: iftee_1234 at yahoo.com
Date: Friday, November 19, 2010, 11:50 AM

Mailing list subscription confirmation notice for mailing list
Ns-developers

We have received a request from 138.37.228.36 for subscription of your
email address, "iftee_1234 at yahoo.com", to the ns-developers at isi.edu
mailing list.? To confirm that you want to be added to this mailing
list, simply reply to this message, keeping the Subject: header
intact.? Or visit this web page:

? ? http://mailman.isi.edu/mailman/confirm/ns-developers/4698b669134ca35ac14459dfe2a577cc00931963


Or include the following line -- and only the following line -- in a
message to ns-developers-request at isi.edu:

? ? confirm 4698b669134ca35ac14459dfe2a577cc00931963

Note that simply sending a `reply' to this message should work from
most mail readers, since that usually leaves the Subject: line in the
right form (additional "Re:" text in the Subject: is okay).

If you do not wish to be subscribed to this list, please simply
disregard this message.? If you think you are being maliciously
subscribed to the list, or have any other questions, send them to
ns-developers-owner at isi.edu.



      

From perrone at bucknell.edu  Fri Nov 19 08:51:27 2010
From: perrone at bucknell.edu (Luiz Felipe Perrone)
Date: Fri, 19 Nov 2010 11:51:27 -0500
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1290175993.6749.194.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
	<AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>
	<1290175993.6749.194.camel@boyko>
Message-ID: <B4117406-2187-40DE-A607-8479D3FE0B16@bucknell.edu>

Hi Pavel and Mathieu,

This has been a productive discussion. Thanks to Pavel for getting it moving and to Mathieu for circulating the result of my conversations with him. It's helping a lot to have all this out in the open and documented. I'm just getting back in the swing of things and my time is a bit rushed today, so I'll just leave you with a "shortish" note here. More coming later on after I reflect on what you've both circulated by email. I want to take the time (possibly happening no sooner than Monday) to consolidate all these ideas into a wiki document that presents all options and preliminary conclusions. Once we have managed to have what this document converge, we'll be able to have a concrete guide to support the implementation.

One point I want to talk about at this time: Pavel mentioned something about engineering data collection, steady state detection, and termination detection so that they all work within the larger context of the framework, but also outside it. My comments on covering these use cases appear below.

1) Data collection is something that can clearly get work in a more isolated context: you set up your ns-3 simulation to generate samples of your metrics of interest, you set up some infrastructure to pre-process these samples, and you can determine whether the final data will go into the framework's database or into an output file. The use case that this addresses is a simple one:  I want to collect data, but I don't care much about any more complex processing of it and I don't care about giving this data anything in terms of persistence and/or sharing. The solution to cover this use case doesn't do anything to relate data to the simulation scenario which led to its generation. The user is responsible to handle those issues in the old fashioned (aka. ad hoc) way.

2) Steady state detection: in the local context of one simulation run, this can be done outside the larger scope of the framework. The simulation pushes data out to "something" (some program in C++, Python, whatever) that does statistical analysis to determine if transient is over. No problem.

3) Termination detection: two possible situations here - (a) If you're running ONE single simulation run that needs to be terminated automatically, fine: an external "something" (again, some program in C++, Python, whatever) can determine whether the post-transient samples produced reach the critical mass to achieve coverage of the correct confidence interval for the chosen confidence level. This is fine outside the larger scope of the automation framework. (b) If you're running MULTIPLE independent replications of the same simulation scenario, each sample adds to a larger aggregate body of data. When the number of samples in this aggregate is large enough to satisfy the chosen confidence level, than the independent replications can be terminated. If we're talking about (3b), then I think it makes sense to say that this will NOT be a use case covered outside the larger scope of the automation framework.

As I said, more on the analysis of your comments later on.

Felipe

------------------------------------------------------------
Luiz Felipe Perrone, Associate Professor
Dept. of Computer Science, Breakiron 68
Bucknell University, Lewisburg, PA 17837

Voice: +1-570-577-1687
Fax:   +1-570-577-1258
Skype: luiz.felipe.perrone
Web:   http://www.eg.bucknell.edu/~perrone/
------------------------------------------------------------

On Nov 19, 2010, at 9:13 AM, Pavel Boyko wrote:

>  Hi, Mathieu, 
> 
>  It seems that the only thing we really disagree is using trace sources
> to pass data between probes and from probes to collectors. Everything
> else can be combined. 
> 
>  Even this point (trace sources vs. explicit data push) is not very
> important, finally this mechanism will be hidden from users. The only
> remaining question is the complexity of probes implementations (there
> will be dozens of them clearly). Somebody should re-implement our ping
> example using explicit parent/child relations and explicit typed data
> push in the collection tree. Current trace source based implementation
> is extremely compact. 
> 
> On Fri, 2010-11-19 at 13:36 +0100, Mathieu Lacage wrote:
>> It looks like we don't agree on the tree idea though since you mention
>> below that you attempt to support a data collection graph instead of a
>> tree. I am worried this is a bit too complex for the use-cases I have
>> in mind.
> 
>  No, I agree that trees are simpler to use and I didn't try to
> explicitly support arbitrary data collection DAG. This comes out for
> free if use trace sources. 
> 
>> This is exactly the use-case felipe and I discussed: it seems to me
>> that using trace sources is not sufficient to be able to serialize and
>> reconstruct the data collection graph later. 
> 
>  Do we really need a "serialize" part of this? I had a GUI writing XML
> and ns-3 application reading them in mind. This is easy.
> At the same time I do agree, that _check_ this XML for source/sink
> signature match before instantiation is impossible. But you have already
> mentioned that we will need to use models trace sources anyway, so data
> collection tree can't be checked anyway. 
> 
>> Using a set of explicit
>> children and parent attributes allows us to parse easily the tree
>> automatically to serialize it and reconstruct it later.
> 
>  Passing data between probes using trace sources can be combined with
> explicit parent/child relations if you need them -- why not? Anyway this
> functionality will be hidden in the parent Probe class -- this will just
> make it more complex. But this is still simpler than have two data
> passing mechanisms: one for model -> probe, and another one for probe ->
> probe and probe -> collector data flows. 
> 
>> Felipe and I discussed this but we felt that this was a very unlikely
>> scenario and that it would be ok to tell users to setup the graph
>> first and to enable/disable collection whenever they want.
> 
>  In this case you should describe how to collect, say, histogram of
> per-flow average packet delay for a priori unknown number of data flows.
> Let it be use case "random VoIP flows". 
> 
>> My feeling is that being able to send the same data to multiple
>> listeners is useful only at the leaves which indeed is already
>> supported by the existing trace source framework but I feel that we
>> should try to come up with something simpler.
> 
>  Do you like an idea to have a dedicated data collector for transient
> detection and another one for runtime termination? If yes, it can be
> useful to send single data stream to 1) output database 2) moving
> average probe -> transient detector 3) stddev probe -> runtime detector.
> Let it be use case "on-line transient detection and runtime termination
> on top of data collection". 
> 
>> Well, our simulation topology is static and this was clearly an
>> important decision we made a long time ago so, from that perspective,
>> saying that the data collection tree is static appears fairly
>> reasonable. So, yes, certain things are not possible or painful to do
>> with a static tree but this is much simpler to implement, and manage
>> and should address most use-cases. Do you have a specific scenario in
>> mind that is critical and that would not work given a static tree ? To
>> be clear, I suspect that it's always easy to add new nodes to the tree
>> at runtime (just like it's possible to create new ns3::Node objects at
>> runtime), but removing them is not so easy.
> 
>  I can agree on supporting adding probe runtime and not supporting
> remove probe. 
> 
>> I understand this but I feel that this is gives too much freedom and
>> complexifies considerably the overall structure. i.e., this work
>> started from a simple observation: the trace source/sink thing is very
>> flexible and allows you to do anything you want (hey, it allowed you
>> to build the fancy proposal you made) but we would like to make
>> available something that is easier to use based on the assumption that
>> those who can't use the simpler thing can always go and use the
>> low-level trace source/sink facility. So, simplifying the data
>> collection framework is not taking features away from you: it's merely
>> trying to optimize for the simple use-cases.
> 
>  Agree.
> 
>> We already do something like this for pcapwriter so, yes, we should do
>> it for this too.
> 
>  Good! 
> 
>> Agreed, but we need to come up with something nicer to use.
> 
>  I see two approaches to user-visible data collection setup. One is to
> describe/instantiate whole data collection tree (e.g. using XML, or some
> simple code). Another one -- to provide EnableDataCollection
> (Ptr<Collector>) methods in existing helpers, much like EnablePcap() is
> implemented. E.g. WifiHelper::EnableDataCollection() will add some
> default wifi-related data probes to the data collector and
> FlowMonitor::EnableDataCollection() will output current flowmon
> statistics to the output database. Both approaches can be combined for
> sure. 
> 
>>> From my perspective, the goal here is not really to provide more
>> features: it is to make it easier to trace data and store it so, I my
>> main objective is trying to come up with something that is simple to
>> understand and reason about from a user perspective.
> 
>  Agree, but I also find it important to (try to) design data collection
> framework flexible enough to be _the only_ data collection mechanism
> used by all users.
> 
>  Pavel
> 
> 



From mezzavilla.marco at gmail.com  Fri Nov 19 09:22:02 2010
From: mezzavilla.marco at gmail.com (Marco Mezzavilla)
Date: Fri, 19 Nov 2010 18:22:02 +0100
Subject: [Ns-developers] LTE modules for ns-3
Message-ID: <AANLkTi=BmMzkankXQHY4Fzj=Xjy93iH19fV_Oz-TRbN6@mail.gmail.com>

Hi all,

our research group at the Department of Information Engineering (DEI) -
University of Padova is aiming to develop LTE modules for ns-3 too.

We are carrying out research on protocol design and optimization related to
some european projects, focusing on MAC layer, mobility, traffic
modelization, creation of multimedia applications, MIMO implementation, and
so forth.

We are willing to collaborate and share our progresses with ns-3 community.


Best Regards,

Marco Mezzavilla

From vaguenes at gmail.com  Sun Nov 21 03:34:11 2010
From: vaguenes at gmail.com (Elena Buchatskaya)
Date: Sun, 21 Nov 2010 14:34:11 +0300
Subject: [Ns-developers]  patch of AODV routing protocol
In-Reply-To: <AANLkTint8KEcX=WecbdCwGU58F9c3Hu-uU-45pnOJfL9@mail.gmail.com>
References: <77CB87A6144B6Fyoshiyaz@gmail.com>
	<AANLkTint8KEcX=WecbdCwGU58F9c3Hu-uU-45pnOJfL9@mail.gmail.com>
Message-ID: <AANLkTimRXdiZVwhV_LKReTxTE0TAYdDhBcx_4S0nPdz=@mail.gmail.com>

Hi Yoshihiko,

Thanks for your job. I agree with all these errors and your solutions.


(1) MaxQueueLen and MaxQueueTime attributes can't change.

(2) Neighbor's sequence number is always invalid at disabling
>    HELLO.
> (3) Intermediate node reply at invalid sequence number.
> (4) Route loop is made from RREQ.

(5) First data packet is sent to bad route.
>

Also I think that this patch can significantly improve AODV performance. Did
you compare protocol performance before and after applying patch?

-- 
Best regards,

Elena Buchatskaya

From ruben at net.t-labs.tu-berlin.de  Sun Nov 21 23:38:45 2010
From: ruben at net.t-labs.tu-berlin.de (Ruben Merz)
Date: Mon, 22 Nov 2010 08:38:45 +0100
Subject: [Ns-developers] WNS3 2011 (workshop on ns-3): submission deadline
	is in two days
In-Reply-To: <4C9394BA.10504@cttc.es>
References: <4C919DF1.3030004@tomh.org>
	<4C9328A0.3000904@net.t-labs.tu-berlin.de> <4C9394BA.10504@cttc.es>
Message-ID: <4CEA1E05.5070603@net.t-labs.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear all,

Here is a gentle reminder that the submission deadline is in two days.

Best
Nicola and Ruben


===============================================================
                   The Third Workshop on ns-3
                       March 25th, 2010
                       Barcelona, Spain
                   http://www.wns3.org/2011/
===============================================================



The Workshop on ns-3 (WNS3) is a one day workshop held in conjunction
with the Fourth International Conference on Simulation Tools and
Techniques (SIMUTools 2011).
The workshop will take place on March 25th, 2010, in Barcelona, Spain.
The objective of the workshop is to gather ns-3 users and developers,
together with networking simulation practitioners and users and
developers of other network simulation tools, to discuss about the ns-3
simulator and related activities.


CALL FOR PAPERS

After two successful editions, which gathered users and developers for
highly interactive and lively discussions but without a formal
publication track, this year the workshop will feature a peer-reviewed
paper track, thus allowing presenters to get formal credit for their
contribution.  Papers will be available in the digital library
collection arranged by the main conference track (more details to be
provided at a later date).

Topics of interest include, but are not limited to, the following:

    * new models, devices, protocols and applications for ns-3
    * frameworks for the definition and automation of ns-3 simulations
    * post-processing and statistical analysis tools for ns-3
    * speed and scalability issues for ns-3
    * validation of ns-3 models
    * credibility and reproducibility issues for ns-3 simulations
    * integration of ns-3 with testbeds, emulators, and other
      simulators or tools
    * real code integration with ns-3

As a general rule, papers presenting enhancements to ns-3 and/or
innovative ways of using ns-3 that could be beneficial to the ns-3
community are considered to be within the scope of the workshop. Papers
that just present simulation results obtained without any significant
modification to the ns-3 simulator will be considered out of scope and
rejected. Please do not hesitate to contact the workshop chairs if you
have any question regarding the scope of your submission.


Important dates:

Submission deadline         : November 24, 2010
Notification of acceptance  :  January 19, 2011
Camera-ready deadline       :  February 8, 2011


Paper Submission Guidelines:

Papers must be written in English and must not exceed 8 pages. Authors
should submit papers through EasyChair
(http://www.easychair.org/conferences/?conf=wns3) in PDF format,
complying with the ACM conference proceedings format. Submitted papers
must not have been submitted for review or published (partially or
completely) elsewhere. Every paper will be peer-reviewed. Papers will be
accepted based on relevance, originality and amount of the contribution,
as well as quality of the writing and presentation. At least one author
of each accepted paper must register and present the work at the
conference. Failure to do so will result in the paper not being
published in the conference proceedings and in the digital libraries.
The copyright policy that will be used for accepted papers will be
posted as part of the author's kit at a future date.


SHORT TALKS AND DEMONSTRATIONS

In addition to the regular paper track, WNS3 will also feature sessions
dedicated to short talks and demonstrations not to be published on the
conference proceedings. The aim is to foster interactive discussions on
work in progress, new problem statements and ideas for future
development related to ns-3.  More details will be announced at a future
date (the submission date will be closer to the workshop date).


NS-3 DEVELOPERS' MEETING

In addition, the ns-3 developers' meeting will be co-located with WNS3,
either on Thursday, March 24th or Saturday, March 26th. More details
will be announced in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJM6h4FAAoJEIem9YkUyRjtBIQH/0s1358beSzb7LYLyBS/GV36
gr8KO8Ehpel+06uLpFQTr0PtQIpjIU4IMsYudDKDGRIq49C40ik2Ke1uH3/w6Zvs
5bzmjuOAPB/yMQlXvTDPJ/tB6FXoF7x4RlKR/8StcvNY7bAY+y6m8adzJ0VsGjyZ
WXpWClqHznEBKYYG2z2qj+5Vk+wCacABuytQ141KaV4oFDcnd0yXbxsoleClyfH8
r6eTM8qin+np8SNBScDtL5rOwx5Wb188Am2W/w92zphdc9egRlaf7Raqap7cv73f
MT5qoCJedJXX+mXhFDY1o59Fn+czm0/kfrTI/e9YU9E22kUPNQ59O2/sC0SXjJI=
=KI5c
-----END PGP SIGNATURE-----

From yoshiyaz at gmail.com  Sun Nov 21 16:24:46 2010
From: yoshiyaz at gmail.com (Yoshihiko)
Date: Mon, 22 Nov 2010 09:24:46 +0900
Subject: [Ns-developers] patch of AODV routing protocol
In-Reply-To: <AANLkTimRXdiZVwhV_LKReTxTE0TAYdDhBcx_4S0nPdz=@mail.gmail.com>
References: <77CB87A6144B6Fyoshiyaz@gmail.com>
	<AANLkTint8KEcX=WecbdCwGU58F9c3Hu-uU-45pnOJfL9@mail.gmail.com>
	<AANLkTimRXdiZVwhV_LKReTxTE0TAYdDhBcx_4S0nPdz=@mail.gmail.com>
Message-ID: <78CB89DBAAC7B9yoshiyaz@gmail.com>

Hi,

Thank you for reply and agreement.

> Also I think that this patch can significantly improve AODV performance. Did
> you compare protocol performance before and after applying patch?

I'm sorry, I am not comparing the performance.
But I checked the operation by many nodes, and I also think that 
AODV performance is being improved.

Regards,
Yoshihiko Yazawa

From nbaldo at cttc.es  Tue Nov 23 08:22:34 2010
From: nbaldo at cttc.es (Nicola Baldo)
Date: Tue, 23 Nov 2010 17:22:34 +0100
Subject: [Ns-developers] WNS3 2011 (workshop on ns-3): deadline extended
In-Reply-To: <4C9394BA.10504@cttc.es>
References: <4C919DF1.3030004@tomh.org>
	<4C9328A0.3000904@net.t-labs.tu-berlin.de> <4C9394BA.10504@cttc.es>
Message-ID: <4CEBEA4A.9010504@cttc.es>


Dear all,

due to numerous requests, the submission deadline for WNS3 is extended 
to December 3, 2010. Please note that this deadline is firm (no more 
extensions will be given).

Best regards,

Nicola and Ruben


===============================================================
                    The Third Workshop on ns-3
                        March 25th, 2011
                        Barcelona, Spain
                    http://www.wns3.org/2011/
===============================================================



The Workshop on ns-3 (WNS3) is a one day workshop held in conjunction
with the Fourth International Conference on Simulation Tools and
Techniques (SIMUTools 2011).
The workshop will take place on March 25th, 2011, in Barcelona, Spain.
The objective of the workshop is to gather ns-3 users and developers,
together with networking simulation practitioners and users and
developers of other network simulation tools, to discuss about the ns-3
simulator and related activities.


CALL FOR PAPERS

After two successful editions, which gathered users and developers for
highly interactive and lively discussions but without a formal
publication track, this year the workshop will feature a peer-reviewed
paper track, thus allowing presenters to get formal credit for their
contribution. The papers that are accepted and presented at the workshop 
will appear in CD proceedings, in the ACM DL, and in EU-DL.

Topics of interest include, but are not limited to, the following:

     * new models, devices, protocols and applications for ns-3
     * frameworks for the definition and automation of ns-3 simulations
     * post-processing and statistical analysis tools for ns-3
     * speed and scalability issues for ns-3
     * validation of ns-3 models
     * credibility and reproducibility issues for ns-3 simulations
     * integration of ns-3 with testbeds, emulators, and other
       simulators or tools
     * real code integration with ns-3

As a general rule, papers presenting enhancements to ns-3 and/or
innovative ways of using ns-3 that could be beneficial to the ns-3
community are considered to be within the scope of the workshop. Papers
that just present simulation results obtained without any significant
modification to the ns-3 simulator will be considered out of scope and
rejected. Please do not hesitate to contact the workshop chairs if you
have any question regarding the scope of your submission.


Important dates:

Submission deadline          :  December 3, 2010 (extended)
Notification of acceptance   :  January 19, 2011
Camera-ready deadline        :  February 8, 2011


Paper Submission Guidelines:

Papers must be written in English and must not exceed 8 pages. Authors
should submit papers through EasyChair
(http://www.easychair.org/conferences/?conf=wns3) in PDF format,
complying with the ACM conference proceedings format. Submitted papers
must not have been submitted for review or published (partially or
completely) elsewhere. Every paper will be peer-reviewed. Papers will be
accepted based on relevance, originality and amount of the contribution,
as well as quality of the writing and presentation. At least one author
of each accepted paper must register and present the work at the
conference. Failure to do so will result in the paper not being
published in the conference proceedings and in the digital libraries.
The copyright policy that will be used for accepted papers will be
posted as part of the author's kit at a future date.


SHORT TALKS AND DEMONSTRATIONS

In addition to the regular paper track, WNS3 will also feature sessions
dedicated to short talks and demonstrations not to be published on the
conference proceedings. The aim is to foster interactive discussions on
work in progress, new problem statements and ideas for future
development related to ns-3.  More details will be announced at a future
date (the submission date will be closer to the workshop date).


NS-3 DEVELOPERS' MEETING

In addition, the ns-3 developers' meeting will be co-located with WNS3,
either on Thursday, March 24th or Saturday, March 26th. More details
will be announced in the future.

From elias.weingaertner at cs.rwth-aachen.de  Tue Nov 23 08:45:27 2010
From: elias.weingaertner at cs.rwth-aachen.de (=?ISO-8859-15?Q?Elias_Weing=E4rtner?=)
Date: Tue, 23 Nov 2010 17:45:27 +0100
Subject: [Ns-developers] Synchronized Network Emulation Release
Message-ID: <4CEBEFA7.4080809@cs.rwth-aachen.de>

Hello,

today we're finally releasing our ns-3 implementation of synchronized 
network emulation. It enables network emulation scenarios of any 
complexity to be set-up with ns-3, without requiring the simulation to 
execute in real-time.

We also announce the release of the 802.11 emulation framework we 
presented at the ns-3 workshop earlier this year.

Everything can be found at the project site at the following URL

http://www.comsys.rwth-aachen.de/projects/slicetime/

We welcome any comments and suggestions!

Best regards,

Elias



-- 
Dipl.-Inf. Elias Weingaertner
Research Assistant
Communication Systems Group
RWTH Aachen
Germany
http://www.comsys.rwth-aachen.de/team/elias-weingaertner/

From fabinader at gmail.com  Fri Nov 26 07:00:03 2010
From: fabinader at gmail.com (Fuad Abinader)
Date: Fri, 26 Nov 2010 11:00:03 -0400
Subject: [Ns-developers] ns-3, 802.15.4 + 6LoWPAN
In-Reply-To: <AANLkTiknXRdkgBTf0P3wqAKYEYpVP3zPZfmZ2vjUXDPE@mail.gmail.com>
References: <AANLkTiknXRdkgBTf0P3wqAKYEYpVP3zPZfmZ2vjUXDPE@mail.gmail.com>
Message-ID: <AANLkTik0_vY2PiQmi15hej0Rk6noVNeMFX_Gcb4kU0_7@mail.gmail.com>

Hi Andrea,

   It's been a while since you and Tommaso disclosured you were going
to work on a 802.15.4 implementation for NS-3. As I might be
interested on using it, I'd like to ask you whether you have
progressed on this, and if you intend to disclosure the implementation
to the general  public.

Regards,

Fuad Abinader

2010/9/7 Andrea Sacco <andrea.sacco85 at gmail.com>:
> Hello everybody,
> I just want to let you know I'm going to work on the 802.15.4 implementation
> porting to ns-3. I will work together with Tommaso Pecorella.
> The porting plan is to first look at the ns-2 stack to understand the
> overall organization of the code. Then, basing on that analysis, we will
> design an architecture that fits ns-3 needs. Finally we'll implement the
> 802.15.4 stack according to the derived architecture.
>
> As said from Tommaso, we'd be happy to receive feedback and comments.
> I'll try to send a weekly/biweekly update to the list to keep you updated
> with the project progress.
>
> Regards,
> Andrea
>
> 2010/8/31 <ns-developers-request at isi.edu>
>>
>> Hi all,
>>
>> just a short news: due to a project we're involved with, we'll start
>> developing/porting the 802.15.4 stack support in ns-3. I know there was a
>> quite good 802.15.4 stack for ns-2, so we'll probably start with that one.
>>
>> Right now I can't be totally sure about how far we'll go into it, but the
>> plan (a rather ambitious one considering the amount of people involved, as
>> is always too few) is:
>> 1) 802.15.4 stack
>> 2) 6LoWPAN (not the full stack probably, but the basic support for sure)
>> 3) ?IP (very unsure about it, as "normal" IPv6 stacks might be good enough)
>>
>> To my best knowledge no one is working on it, but I'd be happy to be proven
>> wrong.
>>
>> We do *not* plan to integrate in it fancy stuff like RPL and other routing
>> schemes, or at least we don't plan to do it right now as it's not the focus
>> of the project we're in. Of course this doesn't mean we're not interested in
>> routing, just that we have some time constraints, so we can't fit in also
>> that one.
>>
>> BTW, by "we" I mean our Laboratory, so hopefully I'll not be the one (or
>> not the only one) pestering for code suggestions and reviews.
>>
>>
>> Best regards,
>>
>>
>> Tommaso
>>
>> --------------------------------------------------------------
>>
>> The nice thing about standards is that there are so many to choose from.
>> And if you really don't like all the standards you just have to wait
>> another year until the one arises you are looking for.
>> -- A. Tanenbaum, "Introduction to Computer Networks"
>>
>> --------------------------------------------------------------
>>
>> Tommaso Pecorella - Ph.D.
>>
>> Assistant professor
>> Dpt. Elettronica e Telecomunicazioni
>> Universit? di Firenze
>>
>> CNIT - Universit? di Firenze Unit
>>
>> via di S. Marta 3
>> 50139, Firenze
>> ITALY
>>
>> email: tommaso.pecorella at unifi.it
>> ? ? ? tommaso.pecorella at cnit.it
>>
>> phone : +39-055-4796412
>> mobile: +39-320-4379803
>> fax ? : +39-055-494569
>>
>


From fabinader at gmail.com  Fri Nov 26 07:07:51 2010
From: fabinader at gmail.com (Fuad Abinader)
Date: Fri, 26 Nov 2010 11:07:51 -0400
Subject: [Ns-developers] Synchronized Network Emulation Release
In-Reply-To: <4CEBEFA7.4080809@cs.rwth-aachen.de>
References: <4CEBEFA7.4080809@cs.rwth-aachen.de>
Message-ID: <AANLkTinW-CUyk96veVpVnEfJ1bEK-f0zHNC7wzbTr=3i@mail.gmail.com>

Hi Elias,

   I've given a quick look at your project, and for me it seems really
useful. I'd like to make a few complimentary questions to you:

a) will you update it to the latest NS-3 version?
b) do you intend to merge this code into NS-3 repository?
b) if one would like to use a different OS, e.g. Contiky or TinyOS
(wireless sensor OSes), what kind of changes do you think would need
to be done on these OSes? Also, do you think there will be need for
additional changes on Xen or NS-3 beyond those you already did?

Regards,

Fuad Abinader

2010/11/23 Elias Weing?rtner <elias.weingaertner at cs.rwth-aachen.de>:
> Hello,
>
> today we're finally releasing our ns-3 implementation of synchronized
> network emulation. It enables network emulation scenarios of any complexity
> to be set-up with ns-3, without requiring the simulation to execute in
> real-time.
>
> We also announce the release of the 802.11 emulation framework we presented
> at the ns-3 workshop earlier this year.
>
> Everything can be found at the project site at the following URL
>
> http://www.comsys.rwth-aachen.de/projects/slicetime/
>
> We welcome any comments and suggestions!
>
> Best regards,
>
> Elias
>
>
>
> --
> Dipl.-Inf. Elias Weingaertner
> Research Assistant
> Communication Systems Group
> RWTH Aachen
> Germany
> http://www.comsys.rwth-aachen.de/team/elias-weingaertner/
>


From sh.khalifa at fci-cu.edu.eg  Thu Nov 25 15:34:21 2010
From: sh.khalifa at fci-cu.edu.eg (Shady Khalifa)
Date: Thu, 25 Nov 2010 15:34:21 -0800 (PST)
Subject: [Ns-developers] High Speed Bluetooth Extension
Message-ID: <302243.74535.qm@web36702.mail.mud.yahoo.com>

I would like to contribute an extension to the Bluetooth UCBT extension 
[http://www.cs.uc.edu/~cdmc/ucbt/] to model the new Bluetooth V3.0 standard.


Two Alternative MAC/PHYs are supported : IEEE802.11b/g and UWB (based on 
the  EPFL  UWB NS-2 extension [http://uwb.epfl.ch/ns-2/index.html])

The new extension adds A2MP protocol, 802.11 PAL and UWB PAL and supports 
discovering the remote devices alternative MAC/PHY capabilities and creating 
high speed connections over one of the alternative  MAC/PHYs.

(1) The extension was written for ns-2.29
(2) Extension URL: http://code.google.com/p/hsbt/
(3) Download Link: http://hsbt.googlecode.com/files/HSBT-2.29_WiFi_UWB.tar.gz
(3) A number of ReadMe files can be found 
in: http://code.google.com/p/hsbt/w/list
-> Installation Guide: http://code.google.com/p/hsbt/wiki/Installation_Guide
-> Instructions on how to add a new alternative 
MAC/PHY: http://code.google.com/p/hsbt/wiki/Add_New_Alternative_MACPHY
(4) An example script illustrating the use of the 
extension: http://code.google.com/p/hsbt/wiki/Sample_TCL_Script 
Regards


Shady Khalifa
Wave : khalifa.shady at googlewave.com


      

From nbaldo at cttc.es  Fri Nov 26 10:05:13 2010
From: nbaldo at cttc.es (Nicola Baldo)
Date: Fri, 26 Nov 2010 19:05:13 +0100
Subject: [Ns-developers] LTE dev coordination
In-Reply-To: <4CE14D43.8070101@cttc.es>
References: <4CE14D43.8070101@cttc.es>
Message-ID: <4CEFF6D9.7060009@cttc.es>

Thanks everybody for providing information on the ongoing development 
efforts on LTE. I've summarized the various announcements here:
http://www.nsnam.org/wiki/index.php/Current_Development#LTE

On 11/17/2010 11:44 AM, Giuseppe Piro wrote:
 > I'm spending all my efforts to prepare a complete LTE module
 > for the merging with the ns-3-dev.

Yes I noticed that you recently pushed many modifications to address my 
latest review. Thanks for the good work!

Before merge I think we need the following:
1) at least one final review of the code
2) valgrind tests
3) a repository with a clean history

At CTTC we are willing to help for 1) and 2), but this would require 
that 3) is done first. This because otherwise cleaning the history and 
preserving the proper attribution of changeset attribution would be more 
complicated. So, Giuseppe, could you please provide an lte repository 
with a clean history as soon as possible? If for any reason you can't do 
it, I will do it myself, but in this case I will do it in the easiest 
possible way (one big changeset with all your code), which maybe is not 
what you would like to have.

As for the schedule for the merge, my personal feeling is that it should 
be feasible to merge for ns-3.10.


On 11/17/2010 11:44 AM, Giuseppe Piro wrote:
 > After this, I would like to propose myself as maintainer (or one of
 > them) of this module

Thanks for volunteering, it is very good to have the original author of 
the code as maintainer! I would also like to volounteer for sharing the 
maintainership.


Regards,

Nicola








From tomh at tomh.org  Mon Nov 29 22:04:54 2010
From: tomh at tomh.org (Tom Henderson)
Date: Mon, 29 Nov 2010 22:04:54 -0800
Subject: [Ns-developers] ns-3.10 release plans
Message-ID: <4CF49406.7050707@tomh.org>

Hi all,
Josh and I are planning for an ns-3.10 release on January 5.  To support 
this schedule, we're aiming for a code freeze on Dec. 18.

This wiki page will track the release progress and current open issues:
http://www.nsnam.org/wiki/index.php/Ns-3.10

We are going to work with maintainers and contributors to try to finish 
off those items that are close, and fix as many bugs as we can get to. 
If you would like to elevate priority of something or do not see it on 
the wiki page, please let us know.

Thanks,
Tom

From boyko at iitp.ru  Mon Nov 29 23:33:41 2010
From: boyko at iitp.ru (Pavel Boyko)
Date: Tue, 30 Nov 2010 10:33:41 +0300
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <B60CE6C3-7605-41C5-8882-8FC1B9494A41@gmail.com>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
	<AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>
	<1290175993.6749.194.camel@boyko>
	<B60CE6C3-7605-41C5-8882-8FC1B9494A41@gmail.com>
Message-ID: <1291102421.9053.107.camel@boyko>

  Felipe, Mathieu,

  I am sad to see no [public] progress with data collection framework
design and evaluation. I can spend some more time to enhance proposed
concept-proof implementation with more probes and examples -- would it
be useful? Is anybody ready to write concept-proof implementation with
explicit and typed data flow instead of traced callbacks? 

On Fri, 2010-11-19 at 11:05 -0500, Luiz Felipe Perrone wrote:

> 3) Termination detection: two possible situations here - (a) If you're 
> running ONE single simulation run that needs to be terminated automatically, 
> fine: an external "something" (again, some program in C++, Python, whatever) 
> can determine whether the post-transient samples produced reach the critical 
> mass to achieve coverage of the correct confidence interval for the chosen 
> confidence level. This is fine outside the larger scope of the automation 
> framework. (b) If you're running MULTIPLE independent replications of the 
> same simulation scenario, each sample adds to a larger aggregate body of data. 

  I was always afraid of merging output data from several independent
runs into "a larger aggregate body of data". This is because data
sampled in single run can be badly time correlated while distinct runs
are guaranteed to be uncorrelated. Even infinite correlation time can be
easily observed, e.g. in random static MANET topology single isolated
node will stay isolated forever. In this case termination detection
based on estimated output statistical error seems to be near to
impossible. I propose to divide the tasks of single run termination
detection (a hard one, implemented inside simulator) and replication
termination detection (an easy one, implemented in execution manager). 

  Best regards,
  Pavel


From perrone at bucknell.edu  Tue Nov 30 08:35:03 2010
From: perrone at bucknell.edu (Luiz Felipe Perrone)
Date: Tue, 30 Nov 2010 11:35:03 -0500
Subject: [Ns-developers] Data collection framework API proposal
In-Reply-To: <1291102421.9053.107.camel@boyko>
References: <1289926666.3126.37.camel@boyko>
	<AANLkTinrYCc51m74ucg=1zZXs6kEitcWNAUtA=8n5V=x@mail.gmail.com>
	<1290161340.6749.109.camel@boyko>
	<AANLkTi=WNyak4ZFqOLbn1nUj1iK_DX8pvg23kPjeEgBW@mail.gmail.com>
	<1290175993.6749.194.camel@boyko>
	<B60CE6C3-7605-41C5-8882-8FC1B9494A41@gmail.com>
	<1291102421.9053.107.camel@boyko>
Message-ID: <279D8B53-C7EA-4CAD-9C6F-EB475B4F6B22@bucknell.edu>

Hi Pavel,

Hold on; don't be discouraged just yet. I'm done with traveling now and this week I'm making a push on this front. My contending task right now is preparing some content for my spring classes, but I'm putting that on the back burner after today.

The code you pushed out is helpful and replicates some of the work I did; now I have to merge ideas and put it all in the context that Mathieu and I started developing. To respond to the concern you voiced:

> I propose to divide the tasks of single run termination
> detection (a hard one, implemented inside simulator) and replication
> termination detection (an easy one, implemented in execution manager). 

This is the idea, in fact. Except that rather than implement single run termination detection inside the simulator, I'm pushing for having an external process that analyses the data and then issues a termination signal for the simulator. The rationale for this is that is seems more appropriate to allow for agility in plugging in different methods of detecting termination. Putting this functionality outside will allow for increased flexibility, in my opinion.

Felipe

------------------------------------------------------------
Luiz Felipe Perrone, Associate Professor
Dept. of Computer Science, Breakiron 68
Bucknell University, Lewisburg, PA 17837

Voice: +1-570-577-1687
Fax:   +1-570-577-1258
Skype: luiz.felipe.perrone
Web:   http://www.eg.bucknell.edu/~perrone/
------------------------------------------------------------

On Nov 30, 2010, at 2:33 AM, Pavel Boyko wrote:

>  Felipe, Mathieu,
> 
>  I am sad to see no [public] progress with data collection framework
> design and evaluation. I can spend some more time to enhance proposed
> concept-proof implementation with more probes and examples -- would it
> be useful? Is anybody ready to write concept-proof implementation with
> explicit and typed data flow instead of traced callbacks? 
> 
> On Fri, 2010-11-19 at 11:05 -0500, Luiz Felipe Perrone wrote:
> 
>> 3) Termination detection: two possible situations here - (a) If you're 
>> running ONE single simulation run that needs to be terminated automatically, 
>> fine: an external "something" (again, some program in C++, Python, whatever) 
>> can determine whether the post-transient samples produced reach the critical 
>> mass to achieve coverage of the correct confidence interval for the chosen 
>> confidence level. This is fine outside the larger scope of the automation 
>> framework. (b) If you're running MULTIPLE independent replications of the 
>> same simulation scenario, each sample adds to a larger aggregate body of data. 
> 
>  I was always afraid of merging output data from several independent
> runs into "a larger aggregate body of data". This is because data
> sampled in single run can be badly time correlated while distinct runs
> are guaranteed to be uncorrelated. Even infinite correlation time can be
> easily observed, e.g. in random static MANET topology single isolated
> node will stay isolated forever. In this case termination detection
> based on estimated output statistical error seems to be near to
> impossible. I propose to divide the tasks of single run termination
> detection (a hard one, implemented inside simulator) and replication
> termination detection (an easy one, implemented in execution manager). 
> 
>  Best regards,
>  Pavel
>