merge

2012-06-08 11:12:00 +02:00
parent f9b92e8212 aac2d538d4
commit fbaeec4a40
35 changed files with 6430 additions and 220 deletions
--- a/.hgtags
+++ b/.hgtags
@@ -61,3 +61,4 @@ e48ed3aabca6ad71c8c49e4604c0f83345eda6a8 ns-3.11-RC3
 19c9e2b33b4a53f200be80cd49810bdfecf76770 ns-3.12-RC1
 167fc2274f53d4d89fdd769e4a7683ad7b6b7157 ns-3.12
 9007193fbb8d18b69a1feb6aec16501dcf138b6f ns-3.13
+ae540de68a2534213342c5e0b12afb47d7518a90 ns-3.14
--- a/21
+++ b/21
@@ -1,4 +1,4 @@
-Alexander Afanasyev <alexander.afanasyev@ucla.edu> 
+Alexander Afanasyev (alexander.afanasyev@ucla.edu)
 Rohit Agarwal (mindprince@gmail.com)
 Kirill Andreev (andreev@iitp.ru)
 Dean Armstrong (deanarm@gmail.com)
@@ -8,7 +8,7 @@ Ramon Bauza (monbauza@gmail.com)
 Mehdi Benamor (mehdi.benamor@telecom-bretagne.eu)
 Raj Bhattacharjea (raj.b@gatech.edu)
 Timo Bingmann (timo.bingmann@student.kit.edu)
-Julien Boite <juboite@gmail.com> 
+Julien Boite (juboite@gmail.com)
 Elena Borovkova (borokovaes@iitp.ru)
 Pavel Boyko (boyko@iitp.ru)
 Dan Broyles (muxman@sbcglobal.net)
@@ -26,18 +26,19 @@ Craig Dowell (craigdo@ee.washington.edu)
 Denis Fakhriev (fakhriev@iitp.ru)
 Jahanzeb Farooq (Jahanzeb.Farooq@inria.fr, Jahanzeb.Farooq@gmail.com)
 Juliana Freitag Borin (juliana.freitag@gmail.com)
+Thomas Geithner (thomas.geithner@dai-labor.de)
 Martin Giachino (martin.giachino@gmail.com,giachino@fing.edu.uy)
-Charline Taibi Guguen (charline.guguen@gmail.com)
 Tom Goff (tgoff@tgoff.net)
 David Gross (gdavid.devel@gmail.com)
+Charline Taibi Guguen (charline.guguen@gmail.com)
 Daniel Halperin (daniel@halper.in)
 Bruno Haick (bghaick@hotmail.com)
 Frank Helbert (frank@ime.usp.br)
 Tom Henderson (tomhend@u.washington.edu)
 Blake Hurd (naimorai@gmail.com)
-ishan <ishan.chhabra@gmail.com>
+ishan (ishan.chhabra@gmail.com)
 Mohamed Amine Ismail (amine.ismail@inria.fr, iamine@udcast.com)
-Atishay Jain <atishayjain25@gmail.com> 
+Atishay Jain (atishayjain25@gmail.com)
 Sascha Alexander Jopen (jopen@informatik.uni-bonn.de)
 Sam Jansen (sam.jansen@gmail.com)
 Liu Jian (liujatp@gmail.com)
@@ -66,11 +67,11 @@ Duy Nguyen (duy@soe.ucsc.edu)
 Tommaso Pecorella (tommaso.pecorella@unifi.it)
 Vikas Pushkar (vikaskupushkar@gmail.com)
 Josh Pelkey (jpelkey@gatech.edu)
-Colin Perkins <csp@csperkins.org> 
+Colin Perkins (csp@csperkins.org) 
 Giuseppe Piro (g.piro@poliba.it)
 Yana Podkosova (yanapdk@rambler.ru)
 Guangyu Pei (guangyu.pei@boeing.com)
-Andrea Ranieri <andreran@uno.it>
+Andrea Ranieri (andreran@uno.it)
 Bruno Ranieri (Yrrsinn@googlemail.com)
 Ken Renard (kenneth.renard@arl.army.mil)
 Manuel Requena (mrequena@cttc.es)
@@ -83,11 +84,11 @@ Florian Schmidt (Florian.Schmidt@cs.rwth-aachen.de)
 Guillaume Seguin (guillaume.seguin@inria.fr)
 Kulin Shah (m.kulin@gmail.com)
 Phillip Sitbon (phillip.sitbon@gmail.com)
-Anirudh Sivaraman <sk.anirudh@gmail.com> 
+Anirudh Sivaraman (sk.anirudh@gmail.com) 
 Ewgenij Starostin (estar@cs.tu-berlin.de)
-YunQiang Su <wzssyqa@gmail.com>
+YunQiang Su (wzssyqa@gmail.com)
 Lalith Suresh  (suresh.lalith@gmail.com)
-Marcos Talau <talau@users.sourceforge.net>
+Marcos Talau (talau@users.sourceforge.net)
 Adrian S. W. Tam (adrian.sw.tam@gmail.com)
 Hajime Tazaki (tazaki@sfc.wide.ad.jp)
 Wilson Thong (wilsonwk@ee.cityu.edu.hk)
--- a/CHANGES.html
+++ b/CHANGES.html
@@ -44,7 +44,30 @@ to this file based on your experience, please contribute a patch or drop
 us a note on ns-developers mailing list.</p>

 <hr>
-<h1>Changes from ns-3.13 to ns-3-dev</h1>
+<h1>Changes from ns-3.14 to ns-3.15</h1>
+
+<h2>New API:</h2>
+<ul>
+<li></li>
+</ul>
+
+<h2>Changes to existing API:</h2>
+<ul>
+<li></li>
+</ul>
+
+<h2>Changes to build system:</h2>
+<ul>
+<li></li>
+</ul>
+
+<h2>Changed behavior:</h2>
+<ul>
+<li></li>
+</ul>
+
+<hr>
+<h1>Changes from ns-3.13 to ns-3.14</h1>

 <h2>New API:</h2>
 <ul>
--- a/61
+++ b/61
@@ -9,36 +9,73 @@ http://www.nsnam.org including tutorials: http://www.nsnam.org/tutorials.html
 Consult the file CHANGES.html for more detailed information about changed
 API and behavior across ns-3 releases.

+Release 3-dev
+============
+
+Availability
+------------
+This release is not yet available.
+
+Supported platforms
+-------------------
+
+New user-visible features
+-------------------------
+
+Bugs fixed
+----------
+
+Known issues
+------------
+In general, known issues are tracked on the project tracker available
+at http://www.nsnam.org/bugzilla/
+
+Release 3.14.1
+==============
+
+Availability
+------------
+This release is available from:
+http://www.nsnam.org/release/ns-allinone-3.14.1.tar.bz2
+
+Bugs fixed
+----------
+This hotfix release contains a fix for the PyViz visualizer and makes it
+easier to add PyViz support to examples; otherwise it is the same as the
+ns-3.14 release.
+
 Release 3.14
 ============

 Availability
 ------------
-This release not yet available.
+This release is available from: 
+http://www.nsnam.org/release/ns-allinone-3.14.tar.bz2

 Supported platforms
 -------------------
 ns-3.14 has been tested on the following platforms.  Not all features are
 available on all platforms; check the Installation page on the project wiki.

- Ubuntu 12.04 (32/64 bit) with g++-4.6.3
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
 - Fedora Core 17 (32/64 bit) with g++-4.7.0
 - Fedora Core 16 (32/64 bit) with g++-4.6.3
 - Fedora Core 15 (64 bit) with g++-4.6.3
+- Ubuntu 12.04 (32/64 bit) with g++-4.6.3
 - Ubuntu 11.10 (32 bit) with g++-4.6.1
- OS X Lion with g++-4.2.1
- OS X Snow Leopard with g++-4.2.1 
+- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
+- OS X Lion 10.7.4 with g++-4.2.1
+- OS X Snow Leopard 10.6.8 with g++-4.2.1 
 - FreeBSD 8.2 (32 bit) with g++-4.2.1
+- Cygwin 1.7.9-1 with g++-4.5.3

 New user-visible features
 -------------------------
 - Transport protocol implementations (TCP, UDP) have been refactored to
  support also IPv6 connections. Dual-stacked IPv6 sockets are implemented. 
-  An IPv6 socket can accept an IPv4 connection, returning the senders 
+  An IPv6 socket can accept an IPv4 connection, returning the sender's 
  address as an IPv4-mapped address (IPV6_V6ONLY socket option is not 
  implemented).
- The LTE code from the LENA project has been merged, bringin in a
+- The LTE code from the LENA project has been merged, bringing in a
  significant redesign of the LTE module as well as many new features.
 - An antenna module is now included, which includes different
  radiation pattern models. See the corresponding new section of the
@@ -50,7 +87,7 @@ New user-visible features
 - The Dynamic Source Routing (DSR) MANET routing protocol for IPv4 was added.
 - A Random Early Detection (RED) queue model has been added.
 - Ipv6RoutingHelper is now in-line with Ipv4RoutingHelper concerning the RT 
-  print functions. Various minor changes made in Ipv6RoutingProtocol and 
+  print functions. Various minor changes were made in Ipv6RoutingProtocol and 
  derived classes to make this possible.
 - New "SendIcmpv6Redirect" attribute (and getter/setter functions) to 
  Ipv6L3Protocol. The behavior is similar to Linux's conf "send_redirects",
@@ -58,12 +95,12 @@ New user-visible features
 - Longer and more descriptive names are used for error units in RateErrorModel
  class and queue mode in Queue class. Attributes in those classes are also
  changed for consistency. See API documentation for details.
- The netanim animator is now included with the release.
+- The netanim animator is now bundled with the release.

 Bugs fixed
 ----------
- - bug 631 - RealtimeSimulatorImpl does not handle Ctrl-C with python bindings
 - bug 603 - Simulator::Next is useless
+ - bug 631 - RealtimeSimulatorImpl does not handle Ctrl-C with python bindings
 - bug 962 - list of paths to reach objects contains bogus entries
 - bug 1000 - Make RealtimeSimulatorImpl last until stop
 - bug 1053 - Need better error diagnostics in ns2-mobility-trace example
@@ -103,10 +140,12 @@ Bugs fixed
 - bug 1393 - IPv6 Routing Helper RT Print functions
 - bug 1395 - AODV DeferredRouteOutputTag missing constructor
 - bug 1396 - ARP with hardware addresses longer than 6 bytes
+ - bug 1399 - TCP not backing off retransmissions properly
 - bug 1404 - Bound user input in tutorial third.cc program
 - bug 1406 - waf exits with maximum recursion depth exceeded 
 - bug 1415 - examples-to-run.py doesn't work with command line arguments
- - bug 1420 - bug 1420: no python bindings for csma-layout
+ - bug 1420 - no python bindings for csma-layout
+ - bug 1441 - IPv4 header length handling
 
 Known issues
 ------------
--- a/doc/models/Makefile
+++ b/doc/models/Makefile
@@ -49,6 +49,7 @@ SOURCES = \
 	$(SRC)/network/doc/packets.rst \
 	$(SRC)/network/doc/sockets-api.rst \
 	$(SRC)/network/doc/simple.rst \
+	$(SRC)/network/doc/queue.rst \
 	$(SRC)/internet/doc/internet-stack.rst \
 	$(SRC)/internet/doc/ipv4.rst \
 	$(SRC)/internet/doc/ipv6.rst \
--- a/doc/models/source/index.rst
+++ b/doc/models/source/index.rst
@@ -40,7 +40,6 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
   openflow-switch
   point-to-point
   propagation
-   simple
   statistics
   topology
   uan
--- a/doc/models/source/network.rst
+++ b/doc/models/source/network.rst
@@ -7,3 +7,4 @@ Network Module
    network-overview
    sockets-api
    simple
+    queue
--- a/doc/release_steps.txt
+++ b/doc/release_steps.txt
@@ -1,93 +1,89 @@
 Steps in doing an ns-3 release

-ns-3-dev preparation
--------------------
+We typically post release candidates for testing at the following URL:
+https://www.nsnam.org/release/ns-allinone-3.X.rcX.tar.bz2

-1. check out a clean ns-3-dev somewhere using ns-3-allinone (you will need it)
-   - hg clone http://code.nsnam.org/ns-3-allinone
-   - ./download.py
-   - ./build.py --enable-examples --enable-tests
-   - try building static, optimized, and debug versions
+This overview covers the following release stages:
+1) new feature additions and bug fixing
+2) preparing release candidates for testing
+3) making the actual release
+4) maintaining the release
+
+1) new feature additions and bug fixing
+---------------------------------------
+
+During the software development phase, it is important for the release
+manager to try to maintain the following files with updated information:
+- AUTHORS
+- RELEASE_NOTES
+- CHANGES.html
+
+otherwise, this becomes painful to edit (and things are forgotten)
+when the release is imminent.
+
+2) preparing release candidates for testing
+-------------------------------------------
+
+This step presumes that you have a reasonably solid ns-3-dev that you
+and/or the buildbots have been testing
+   - building static, optimized, and debug versions
   - try Python visualizer (not tested by buildbots)
      -- ./waf --pyrun src/flow-monitor/examples/wifi-olsr-flowmon.py --vis
-   - cd ns-3-dev
   - ensure that tests pass (./test.py -g) and make sure that the buildbots
-     are reporting greens based on the tip of the repository
-
-2. prepare the source files
-   - revise and check in AUTHORS, if needed
-   - revise and check in RELEASE_NOTES.  Make sure to edit the Availability 
-     section if this is a final release.
-   - DO NOT change VERSION at this time
+     are reporting blue based on the tip of the repository
+   - revise and check in AUTHORS, RELEASE_NOTES, and CHANGES>html
+   - required versions for related libraries (nsc, netanim, pybindgen)
+     are correct
+   - make latexpdf in the doc/manual, doc/models, and doc/tutorial directories 
   - confirm that Doxygen builds cleanly (./waf doxygen), 
-     and check in any necessary changes. Currently, doxygen does not build
-     cleanly, we need to fix this over time.

-At this point, the ns-3-dev should be ready, except for changing the
-name of this repo from "3-dev" to the numbered release.  That will come
-in subsequent steps.
-
-ns-allinone-3.X.tar.bz2 dry run
-------------------------------
-
-This phase is optional to dry-run a tarball before tagging.  You may skip
-to the next phase if you are ready to just make the release or release 
-candidate.  
-
-1. check out a clean ns-3-allinone again
-   - change into the allinone directory
+Check out a clean ns-3-dev somewhere using ns-3-allinone 
+   - hg clone http://code.nsnam.org/ns-3-allinone
   - ./download.py
   - cd ns-3-dev
-   - change VERSION to the appropriate string, either "3.X" (for a release) or
-     "3.X.RC1"  Do not commit this VERSION change to ns-3-dev.  It is used
-     by dist.py script to name the directory properly.
-   - cd into allinone directory and type "./dist.py"; you should see something
-     like this:
+   - edit VERSION such as "ns-3.14.rc1" (DO NOT commit this change to ns-3-dev)
+   - cd ..
+   - ./dist.py

-NS-3 version: '3.12'
-Adding ns-3-dev as ns-allinone-3.12/ns-3.12
-Adding pybindgen as ns-allinone-3.12/pybindgen-0.15.0.795
-Adding nsc as ns-allinone-3.12/nsc-0.5.2
-Adding the build script files
+This should yield a compressed tarfile, such as:  ns-allinone-3.14.rc1.tar.bz2 
+Test this, and when satisfied, upload it to
+www.nsnam.org:/var/www/html/releases/ (with apache:apache file ownership)

-This will create an ns-allinone-3.X.tar.bz2 tarball
+Announce it to ns-developers as:
+https://www.nsnam.org/release/ns-allinone-3.14.rc3.tar.bz2

-2. test tarball on release platforms 
-   - optimized, debug, and static builds
-   - ./test.py -g
-   - make latexpdf in the doc/manual, doc/models, and doc/tutorial directories 
-   - ./waf --doxygen
+Iterate the above as needed during the release testing phase.
+
+Note, in the past we have added mercurial tags to ns-3-dev to denote
+release candidates, but lately we have not been bothering with this.
+If you would like to tag a release candidate, follow these steps
+     -- hg tag "ns-3.X.rcX" (for the appropriate version numbers)
+     -- hg push ssh://code@code.nsnam.org/repos/ns-3-dev
+
+3) making the release
+---------------------
+
+Follow similar steps for creating the release candidate tarballs, except
+we will work off of a release repository.

 At this point, you are ready for final packaging and repository/site work

 tagging ns-3-dev and creating ns-3.X repositories
 -------------------------------------------------

-The steps here involve tagging ns-3-dev, copying over ns-3-dev to ns-3.X 
-on code.nsnam.org, cloning it locally, making changes from "3-dev" to "3.X" 
-in various places, and checking in those changes to the new ns-3.X repository.
+We'll refer to the release number as "X" or "x" below.  The steps here 
+involve tagging ns-3-dev, copying over ns-3-dev to ns-3.X on code.nsnam.org, 
+cloning it locally, making changes from "3-dev" to "3.X" in various places, 
+and checking in those changes to the new ns-3.X repository.

-1. once you are happy with the tarball, tag ns-3-dev
+1. once you are happy with the most recent release candidate tarball and
+do not plan to further touch ns-3-dev, tag ns-3-dev
   - cd into ns-3-dev
-   - if release candidate
-     -- hg tag "ns-3.x-RCy"
-     -- hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev
-   - else if final release
     -- hg tag "ns-3.x"
     -- hg push ssh://code@code.nsnam.org//home/code/repos/ns-3-dev

 2. copy the tagged ns-3-dev and place it on the repository
   - ssh code.nsnam.org; sudo bash; su code;
-   - if release candidate
-     -- cp -r /home/code/repos/ns-3-dev /home/code/repos/ns-3.x-RCy
-     -- cd /home/code/repos/ns-3.x-RCy/.hg and edit the hgrc appropriately:
-       [paths]
-       default = /home/code/repos/ns-3.x-RCy
-       [web]
-       description = ns-3.x-RCy release
-       name = ns-3.x-RCy
-       contact = <ns-developers@isi.edu>
-   - else if final release
     -- cp -r /home/code/repos/ns-3-dev /home/code/repos/ns-3.x
     -- cd /home/code/repos/ns-3.x/.hg and edit the hgrc appropriately:
       [paths]
@@ -97,21 +93,20 @@ in various places, and checking in those changes to the new ns-3.X repository.
       name = ns-3.x
       contact = <ns-developers@isi.edu>

-3. If this is a final release (not RC)
-   - move (mv) ns-3.x RCs in /home/code/archived-repos
+3. check out a clean version of the new release (ns-3.x) 
+   to a scratch directory on your local machine 
+   - hg clone http://code.nsnam.org/ns-3.x

-4. check out a clean version of the new release (ns-3.x) or (ns-3.x-RCy) 
-   to your local machine 
-   - hg clone http://code.nsnam.org/ns-3.x or (-RCy)
-
-5. Update the VERSION for this new release
+5. Update the VERSION for this new release, in the ns-3.x directory (i.e.
+   NOT in ns-3-dev)
   - change the string 3-dev in the VERSION file to the real version 
-     (e.g. 3.7 or 3.7-RC1)  This must agree with the version name you chose in the clone.
+     (e.g. 3.14)  This must agree with the version name you chose in the clone.
   - change the version and release string for the documentation in 
-     doc/manual/source, doc/tutorial/source, and doc/models/source conf.py files
+     doc/manual/source, doc/tutorial/source, doc/tutorial-pt/source, 
+     and doc/models/source conf.py files
     This should hopefully be updated in the future to simply pull from the
     VERSION file.
-   - hg commit -m "update VERSION to ns-3.x" or (-RCy), you get the point
+   - hg commit -m "update VERSION to ns-3.x"
   - hg push ssh://code@code.nsnam.org//home/code/repos/ns-3.x

 creating the distribution tarball
@@ -171,7 +166,7 @@ Documentation)
 4. The main page http://www.nsnam.org should point to
 ns-3.x in the "Download" and "Documentation" boxes

-5. Create blog entry to announce release 
+5. Create a blog entry to announce release 

 ns-3 wiki edits
 ---------------
@@ -198,3 +193,24 @@ Announcing

 2. announce to ns-developers and ns-3-users, with summary of release notes

+
+4) maintaining the release
+--------------------------
+
+First, create skeletal sections in CHANGES.html and RELEASE_NOTES to
+start collecting inputs for the ns-3.(x+1) release.
+
+The project may decide to make incremental, bug-fix releases from
+time to time, with a minor version number (e.g. ns-3.7.1).  To do
+this, changesets may be cherry-picked from ns-3-dev and added to
+ns-3.x repository.  Do not move over changesets that pertain to 
+adding new features, but documentation fixes and bug fixes are good 
+changesets to make available in a minor release.  The same steps
+above for making a release are generally followed, although one
+does not need to create a separate repository, but instead just tags
+the existing ns-3-dev and ns-3.x repositories with a "ns-3.x.1" type
+of tag.
+
+Also, on the main website, make sure that "latest release" points to
+the right page.  See how it was handled for ns-3.12 (which made
+a minor release): https://www.nsnam.org/ns-3.12/
--- a/doc/tutorial/source/conclusion.rst
+++ b/doc/tutorial/source/conclusion.rst
@@ -24,7 +24,7 @@ who want to learn more are encouraged to read the following additional
 documentation:

 * The |ns3| manual
-* The |ns3| model library documentatio
+* The |ns3| model library documentation
 * The |ns3| Doxygen (API documentation)
 * The |ns3| wiki

--- a/doc/tutorial/source/getting-started.rst
+++ b/doc/tutorial/source/getting-started.rst
@@ -9,7 +9,7 @@ Downloading ns-3

 The |ns3| system as a whole is a fairly complex system and has a
 number of dependencies on other components.  Along with the systems you will
-most likely deal with every day (the GNU toolchain, Mercurial, you programmer
+most likely deal with every day (the GNU toolchain, Mercurial, a text
 editor) you will need to ensure that a number of additional libraries are
 present on your system before proceeding.  |ns3| provides a wiki
 for your reading pleasure that includes pages with many useful hints and tips.
--- a/examples/tcp/wscript
+++ b/examples/tcp/wscript
@@ -2,7 +2,7 @@

 def build(bld):
    obj = bld.create_ns3_program('tcp-large-transfer',
-                                 ['visualizer', 'point-to-point', 'applications', 'internet'])
+                                 ['point-to-point', 'applications', 'internet'])
    obj.source = 'tcp-large-transfer.cc'

    obj = bld.create_ns3_program('tcp-nsc-lfn',
--- a/examples/wireless/wscript
+++ b/examples/wireless/wscript
@@ -8,16 +8,16 @@ def build(bld):
    bld.register_ns3_script('mixed-wireless.py', ['core', 'mobility', 'wifi', 'applications', 'point-to-point', 
                                                    'internet', 'csma', 'olsr'])

-    obj = bld.create_ns3_program('wifi-adhoc', ['core', 'mobility', 'wifi', 'applications', 'tools', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-adhoc', ['core', 'mobility', 'wifi', 'applications', 'tools'])
    obj.source = 'wifi-adhoc.cc'

    obj = bld.create_ns3_program('wifi-clear-channel-cmu', ['internet', 'mobility', 'wifi', 'tools'])
    obj.source = 'wifi-clear-channel-cmu.cc'

-    obj = bld.create_ns3_program('wifi-ap', ['core', 'mobility', 'wifi', 'applications', 'config-store', 'tools', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-ap', ['core', 'mobility', 'wifi', 'applications', 'config-store', 'tools'])
    obj.source = 'wifi-ap.cc'

-    bld.register_ns3_script('wifi-ap.py', ['core', 'mobility', 'wifi', 'applications', 'config-store', 'tools', 'visualizer'])
+    bld.register_ns3_script('wifi-ap.py', ['core', 'mobility', 'wifi', 'applications', 'config-store', 'tools'])

    obj = bld.create_ns3_program('wifi-wired-bridging', ['internet', 'mobility', 'wifi', 'csma', 'bridge', 'applications'])
    obj.source = 'wifi-wired-bridging.cc'
@@ -28,16 +28,16 @@ def build(bld):
    obj = bld.create_ns3_program('multirate', ['internet', 'mobility', 'wifi', 'tools', 'flow-monitor', 'olsr', 'applications', 'point-to-point'])
    obj.source = 'multirate.cc'

-    obj = bld.create_ns3_program('wifi-simple-adhoc', ['internet', 'mobility', 'wifi', 'config-store', 'tools', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-simple-adhoc', ['internet', 'mobility', 'wifi', 'config-store', 'tools'])
    obj.source = 'wifi-simple-adhoc.cc'

-    obj = bld.create_ns3_program('wifi-simple-adhoc-grid', ['internet', 'mobility', 'wifi', 'olsr', 'config-store', 'tools', 'point-to-point', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-simple-adhoc-grid', ['internet', 'mobility', 'wifi', 'olsr', 'config-store', 'tools', 'point-to-point'])
    obj.source = 'wifi-simple-adhoc-grid.cc'

-    obj = bld.create_ns3_program('wifi-simple-infra', ['internet', 'mobility', 'wifi','config-store', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-simple-infra', ['internet', 'mobility', 'wifi','config-store'])
    obj.source = 'wifi-simple-infra.cc'

-    obj = bld.create_ns3_program('wifi-simple-interference', ['internet', 'mobility', 'wifi', 'config-store', 'tools', 'visualizer'])
+    obj = bld.create_ns3_program('wifi-simple-interference', ['internet', 'mobility', 'wifi', 'config-store', 'tools'])
    obj.source = 'wifi-simple-interference.cc'

    obj = bld.create_ns3_program('wifi-blockack', ['internet', 'mobility', 'wifi', 'applications'])
--- a/src/aodv/test/tcp-chain-test-0-0.pcap
+++ b/src/aodv/test/tcp-chain-test-0-0.pcap
--- a/src/aodv/test/tcp-chain-test-9-0.pcap
+++ b/src/aodv/test/tcp-chain-test-9-0.pcap
--- a/src/create-module.py
+++ b/src/create-module.py
@@ -230,11 +230,13 @@ Model Description

 The source code for the new module lives in the directory ``src/%(MODULE)s``.

+Add here a basic description of what is being modeled.
+
 Design
 ======

-Add here an overall description of the software design and how it fits
-into the existing ns-3 architecture. 
+Briefly describe the software design of the model and how it fits into 
+the existing ns-3 architecture. 

 Scope and Limitations
 =====================
@@ -252,18 +254,31 @@ Usage
 *****

 This section is principally concerned with the usage of your model, using
-the public API.
+the public API.  Focus first on most common usage patterns, then go
+into more advanced topics.

 Building New Module
 ===================

-Include this section if there are special build instructions.
+Include this subsection only if there are special build instructions or
+platform limitations.

-Helper
-======
+Helpers
+=======

 What helper API will users typically use?  Describe it here.

+Attributes
+==========
+
+What classes hold attributes, and what are the key ones worth mentioning?
+
+Output
+======
+
+What kind of data does the model generate?  What are the key trace
+sources?   What kind of logging output can be enabled?
+
 Advanced Usage
 ==============

@@ -275,6 +290,11 @@ Examples

 What examples using this new code are available?  Describe them here.

+Troubleshooting
+===============
+
+Add any tips for avoiding pitfalls, etc.
+
 Validation
 **********

--- a/src/dsr/doc/dsr.rst
+++ b/src/dsr/doc/dsr.rst
@@ -3,8 +3,8 @@
 DSR Routing
 -----------

-Dynamic Source Routing (DSR) protocol is a reactive routing protocol designed specifically for use in multi-hop 
-wireless ad hoc networks of mobile nodes.
+Dynamic Source Routing (DSR) protocol is a reactive routing protocol designed 
+specifically for use in multi-hop wireless ad hoc networks of mobile nodes.

 This model was developed by 
 `the ResiliNets research group <http://www.ittc.ku.edu/resilinets>`_
@@ -13,83 +13,87 @@ at the University of Kansas.
 DSR Routing Overview
 ********************
 
- This model implements the base specification of the Dynamic Source Routing (DSR)
- protocol. Implementation is based on RFC4728.
+This model implements the base specification of the Dynamic Source Routing 
+(DSR) protocol. Implementation is based on RFC4728.

- Class dsr::DsrRouting implements all functionality of service packet exchange and inherits IpL4Protocol.
+* ``Class dsr::DsrRouting`` implements all functionality of service packet exchange and inherits IpL4Protocol.
+* ``Class dsr::DsrOptions`` implements functionality of packet processing and talks to DsrRouting to send/receive packets
+* ``Class dsr::DsrFsHeader`` defines the fixed-size header and identifies the up-layer protocol
+* ``Class dsr::DsrOptionHeader`` takes care of different dsr options and processes different header according to the specification from the RFC 
+* ``Class dsr::DsrSendBuffer`` is a buffer to save data packets and route error packets when there is no route to forward the packets
+* ``Class dsr::DsrMaintainBuffer`` is a buffer to save data packets for next-hop notification when the data packet has already been sent out of send buffer
+* ``Class dsr::RouteCache`` is the essential part to save routes found for data packets.  DSR responds to several routes for a single destination
+* ``Class dsr::RreqTable`` implements the functions to avoid duplicate route requests and control route request rate for a single destination
+ 
+Protocol operation depends on many adjustable parameters.  We support parameters, with their default values, from RFC and parameters that enable/disable 
+protocol features or tune for specific simulation scenarios, such as the max 
+size of the send buffer and its timeout value. The full parameter list is 
+found in the dsr-routing.cc file.

- Class dsr::DsrOptions implements functionality of packet processing and talk to DsrRouting to send/receive packets
+DSR discovers routes on-demand. Therefore, our DSR model buffers all packets, 
+while a route request packet (RREQ) is disseminated. We implement a packet 
+buffer in dsr-rsendbuff.cc. The packet queue implements garbage collection 
+of old packets and a queue size limit. When the packet is sent out from the 
+send buffer, it will be queued in maintenance buffer for next hop 
+acknowledgment.

- Class dsr::DsrFsHeader defines the fixed-size header and identify the up-layer protocol
+The Route Cache implementation support garbage collection of old entries 
+and state machine, as defined in the standard.  It implements as a STL 
+map container. The key is the destination IP address.

- Class dsr::DsrOptionHeader takes care of different dsr options and process different header according to specification from rfc
+Protocol operation strongly depends on broken link detection mechanism. 
+We implement the three heuristics recommended.
+    
+First, we use layer 2 feedback when possible. A link is considered to be 
+broken if frame transmission results in a transmission failure for all 
+retries. This mechanism is meant for active links and works much faster than 
+in its absence.  Layer 2 feedback implementation relies on TxErrHeader trace 
+source, currently it is supported in AdhocWifiMac only.

- Class dsr::DsrSendBuffer is a buffer to save data packet as well as route error packet when there is no route to forward the packet
+Second, passive acknowledgment should be used whenever possible. The node 
+turns on "promiscuous" receive mode, in which it can receive packets not 
+destined for itself, and when the node assures the delivery of that data 
+packet to its destination, it cancels the passive acknowledgment timer.

- Class dsr::DsrMaintainBuffer is a buffer to save data packet for next-hop notification when the data packet has already sent out of send buffer
+Last, we use a network layer acknowledge scheme to notify the receipt of 
+a packet. Route request packet will not be acknowledged or retransmitted.

- Class dsr::RouteCache is the essential part to save routes found for data packet, dsr responds to several routes for a single destination
+The following optional protocol optimizations aren't implemented:

- Class dsr::RreqTable implements the functionalities to avoid duplicate route requests and control route request rate for a single destination
-
- Protocol operation depends on the many adjustable parameters. We support parameters, with their default values, from
- RFC and parameters that enable/disable protocol features or tune for specific simulation scenarios, such as the max size
- of send buffer and its timeout value. The full parameter list is in DsrRouting.cc file.
-
- DSR discovers routes totally on demand. Therefore, our DSR model buffers all packets, while a route request packet (RREQ)
- is disseminated. We implement a packet buffer in dsr-rsendbuff.cc. The packet queue implements garbage collection of old
- packets and a queue size limit. When the packet is sent out from the send buffer, it will be queued in maintenance buffer for
- next hop acknowledgment
-
- Route Cache implementation support garbage collection of old entries and state machine, defined in standard.
- It implements as a STL map container. The key is the destination IP address.
-
- Protocol operation strongly depends on broken link detection mechanism. We implement all the three heuristics.
-    First, we use layer 2 feedback when possible. Link considered to be broken, if frame transmission results in a transmission
-    failure for all retries. This mechanism meant for active links and work much more faster, than first method.
-    Layer 2 feedback implementation relies on TxErrHeader trace source, currently it is supported in AdhocWifiMac only.
-
-    Second, passive acknowledgment should be used whenever possible. The node turns on "promiscuous" receive mode, in which it can receive
-    packet not destined for itself, and when the node assures the delivery of that data packet to its destination, it cancels the passive
-    acknowledgment timer.
-
-    Last, we use network layer acknowledge scheme to notify the receipt of a packet. Route request packet will not
-    be acknowledge or retransmitted.
-
- Following optional protocol optimizations aren't implemented:
-  - Flow state
-  - First Hop External (F), Last Hop External (L) flags
-  - Handling unknown DSR options
-  - Two types of error headers:
+* Flow state
+* First Hop External (F), Last Hop External (L) flags
+* Handling unknown DSR options
+* Two types of error headers:
     1. flow state not supported option
     2. unsupported option (not going to happen in simulation)

- DSR operates with direct access to IP header, and operates between network and transport layer.
+DSR operates with direct access to IP header, and operates between 
+network and transport layer.

- Implementation changes
-  - The DsrFsHeader has added 3 fields: message type, source id, destination id, and these changes only for post-processing
-      - message type is used to identify the data packet from control packet
-      - source id is used to identify the real source of the data packet since we have to deliver the packet hop-by-hop and the ipv4header
-        is not carrying the real source and destination ip address as needed
-      - destination id is for same reason of above
+Implementation changes
+======================

- Changes:
-   - Route Reply header is not word-aligned in DSR rfc, change it to word-aligned in implementation
-   - DSR works as a shim header between transport and network protocol, it needs its own forwarding mechanism,
-     we are changing the packet transmission to hop-by-hop delivery, so we added two fields in dsr fixed header
-     to notify packet delivery
+* The DsrFsHeader has added 3 fields: message type, source id, destination id, 
+and these changes only for post-processing
+** message type is used to identify the data packet from control packet
+** source id is used to identify the real source of the data packet since we have to deliver the packet hop-by-hop and the ipv4header is not carrying the real source and destination ip address as needed
+** destination id is for same reason of above
+* Route Reply header is not word-aligned in DSR rfc, change it to word-aligned in implementation
+* DSR works as a shim header between transport and network protocol, it needs its own forwarding mechanism, we are changing the packet transmission to hop-by-hop delivery, so we added two fields in dsr fixed header to notify packet delivery
     1. message type to notify the type of this packet: data packet or control one
     2. source id to identify the real source address of this packet
     3. destination id to identify the real destination

- Current Route Cache implementation:
-   - This implementation used "path cache", which is simple to implement and ensures loop-free
-      - the path cache has automatic expire policy
-      - the cache saves multiple route entries for a certain destination and sort the entries based on hop counts
-      - the MaxEntriesEachDst can be tuned to change the maximum entries saved for a single destination
-      - when adding mulitiple routes for one destination, the route is compared based on hop-count and expire time, the one with less hop count
-        or relatively new route is favored
-   - Future implementation may include "link cache" as another possibility
+Current Route Cache implementation
+==================================
+
+This implementation used "path cache", which is simple to implement and ensures loop-free paths:
+
+* the path cache has automatic expire policy
+* the cache saves multiple route entries for a certain destination and sort the entries based on hop counts
+* the MaxEntriesEachDst can be tuned to change the maximum entries saved for a single destination
+* when adding mulitiple routes for one destination, the route is compared based on hop-count and expire time, the one with less hop count or relatively new route is favored
+* Future implementation may include "link cache" as another possibility

 DSR Instructions
 ****************
@@ -103,14 +107,15 @@ The following should be kept in mind when running DSR as routing protocol:
 Helper
 ******

-To have a node run DSR, the easiest way would be to use the ClickInternetStackHelper
-class in your simulation script. For instance::
+To have a node run DSR, the easiest way would be to use the DsrHelper
+and DsrMainHelpers in your simulation script. For instance::

  DsrHelper dsr;
  DsrMainHelper dsrMain;
  dsrMain.Install (dsr, adhocNodes);

-The example scripts inside ``src/dsr/examples/`` demonstrate the use of DSR based nodes
+The example scripts inside ``src/dsr/examples/`` demonstrate the use of 
+DSR based nodes
 in different scenarios. The helper source can be found inside ``src/dsr/helper/dsr-main-helper.{h,cc}`` 
 and ``src/dsr/helper/dsr-helper.{h,cc}``

@@ -120,10 +125,9 @@ Examples
 The example can be found in ``src/dsr/examples/``:

 * dsr.cc use DSR as routing protocol within a traditional MANETs environment[3]. 
-
 DSR is also built in the routing comparison case in ``examples/routing/``:

-* manet-routing-compare.cc is a comparison case with built in MANET routing protocols and can generate its own results.
+* ``manet-routing-compare.cc`` is a comparison case with built in MANET routing protocols and can generate its own results.

 Validation
 **********
@@ -133,10 +137,14 @@ This model has been tested as follows:
 * Unit tests have been written to verify the internals of DSR. This can be found in ``src/dsr/test/dsr-test-suite.cc``. These tests verify whether the methods inside DSR module which deal with packet buffer, headers work correctly.
 * Simulation cases similar to [3] have been tested and have comparable results.
 * manet-routing-compare.cc has been used to compare DSR with three of other routing protocols.
+
+A paper was presented on these results at the Workshop on ns-3 in 2011.
  
 References
 **********

-[1] Link for the original paper: www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf
-[2] Link for RFC 4728: http://www6.ietf.org/rfc/rfc4728.txt
-[3] Link for the broch's comparison paper: http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps
+[1] Link for the `original paper: <http://www.monarch.cs.rice.edu/monarch-papers/dsr-chapter00.pdf>`_
+
+[2] Link for `RFC 4728: <http://www6.ietf.org/rfc/rfc4728.txt>`_
+
+[3] Link for the `Broch's comparison paper: <http://www.monarch.cs.rice.edu/monarch-papers/mobicom98.ps>`_
--- a/src/dsr/examples/dsr.cc
+++ b/src/dsr/examples/dsr.cc
@@ -50,14 +50,15 @@ main (int argc, char *argv[])
  //
 #if 0
  LogComponentEnable ("Ipv4L3Protocol", LOG_LEVEL_ALL);
-  LogComponentEnable ("Ipv4L4Protocol", LOG_LEVEL_ALL);
  LogComponentEnable ("UdpL4Protocol", LOG_LEVEL_ALL);
+  LogComponentEnable ("UdpSocketImpl", LOG_LEVEL_ALL);
  LogComponentEnable ("NetDevice", LOG_LEVEL_ALL);
  LogComponentEnable ("Ipv4EndPointDemux", LOG_LEVEL_ALL);
 #endif

 #if 0
  LogComponentEnable ("DsrOptions", LOG_LEVEL_ALL);
+  LogComponentEnable ("DsrHelper", LOG_LEVEL_ALL);
  LogComponentEnable ("DsrRouting", LOG_LEVEL_ALL);
  LogComponentEnable ("DsrOptionHeader", LOG_LEVEL_ALL);
  LogComponentEnable ("DsrFsHeader", LOG_LEVEL_ALL);
--- a/src/dsr/examples/wscript
+++ b/src/dsr/examples/wscript
@@ -1,6 +1,6 @@
 ## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-

 def build(bld):
-    obj = bld.create_ns3_program('dsr', ['core', 'simulator', 'node', 'internet-stack'])
+    obj = bld.create_ns3_program('dsr', ['core', 'network', 'internet', 'applications', 'mobility', 'config-store', 'wifi', 'dsr'])
    obj.source = 'dsr.cc'

--- a/src/internet/model/icmpv4-l4-protocol.cc
+++ b/src/internet/model/icmpv4-l4-protocol.cc
@@ -57,7 +57,7 @@ Icmpv4L4Protocol::NotifyNewAggregate ()
      if (node != 0)
        {
          Ptr<Ipv4L3Protocol> ipv4 = this->GetObject<Ipv4L3Protocol> ();
-          if (ipv4 != 0)
+          if (ipv4 != 0 && m_downTarget.IsNull ())
            {
              this->SetNode (node);
              ipv4->Insert (this);
--- a/src/internet/model/icmpv6-l4-protocol.cc
+++ b/src/internet/model/icmpv6-l4-protocol.cc
@@ -112,7 +112,7 @@ void Icmpv6L4Protocol::NotifyNewAggregate ()
      if (node != 0)
        {
          Ptr<Ipv6L3Protocol> ipv6 = this->GetObject<Ipv6L3Protocol> ();
-          if (ipv6 != 0)
+          if (ipv6 != 0 && m_downTarget.IsNull ())
            {
              SetNode (node);
              ipv6->Insert (this);
--- a/src/internet/model/ipv4-header.cc
+++ b/src/internet/model/ipv4-header.cc
@@ -40,7 +40,8 @@ Ipv4Header::Ipv4Header ()
    m_flags (0),
    m_fragmentOffset (0),
    m_checksum (0),
-    m_goodChecksum (true)
+    m_goodChecksum (true),
+    m_headerSize(5*4)
 {
 }

@@ -339,7 +340,8 @@ Ipv4Header::Print (std::ostream &os) const
 uint32_t 
 Ipv4Header::GetSerializedSize (void) const
 {
-  return 5 * 4;
+  //return 5 * 4;
+	return m_headerSize;
 }

 void
@@ -414,6 +416,7 @@ Ipv4Header::Deserialize (Buffer::Iterator start)
  /* i.Next (2); // checksum */
  m_source.Set (i.ReadNtohU32 ());
  m_destination.Set (i.ReadNtohU32 ());
+  m_headerSize = headerSize;

  if (m_calcChecksum) 
    {
--- a/src/internet/model/ipv4-header.h
+++ b/src/internet/model/ipv4-header.h
@@ -244,6 +244,7 @@ private:
  Ipv4Address m_destination;
  uint16_t m_checksum;
  bool m_goodChecksum;
+  uint16_t m_headerSize;
 };

 } // namespace ns3
--- a/src/internet/model/nsc-tcp-l4-protocol.cc
+++ b/src/internet/model/nsc-tcp-l4-protocol.cc
@@ -196,7 +196,7 @@ NscTcpL4Protocol::NotifyNewAggregate ()
      if (node != 0)
        {
          Ptr<Ipv4L3Protocol> ipv4 = this->GetObject<Ipv4L3Protocol> ();
-          if (ipv4 != 0)
+          if (ipv4 != 0 && m_downTarget.IsNull ())
            {
              this->SetNode (node);
              ipv4->Insert (this);
--- a/src/internet/model/rtt-estimator.cc
+++ b/src/internet/model/rtt-estimator.cc
@@ -279,25 +279,17 @@ void RttMeanDeviation::Measurement (Time m)
 Time RttMeanDeviation::RetransmitTimeout ()
 {
  NS_LOG_FUNCTION (this);
-  // If not enough samples, just return 2 times estimate
-  //if (nSamples < 2) return est * 2;
-  Time retval (Seconds (0));
-  double var = m_variance.ToDouble (Time::S);
-  NS_LOG_DEBUG ("RetransmitTimeout:  var " << var << " est " << m_currentEstimatedRtt.ToDouble (Time::S) << " multiplier " << m_multiplier);
-  if (var < (m_currentEstimatedRtt.ToDouble (Time::S) / 4.0) )
+  NS_LOG_DEBUG ("RetransmitTimeout:  var " << m_variance.GetSeconds () << " est " << m_currentEstimatedRtt.GetSeconds () << " multiplier " << m_multiplier);
+  // RTO = srtt + 4* rttvar
+  int64_t temp = m_currentEstimatedRtt.ToInteger (Time::MS) + 4 * m_variance.ToInteger (Time::MS);
+  if (temp < m_minRto.ToInteger (Time::MS))
    {
-      for (uint16_t i = 0; i < 2* m_multiplier; i++)
-        {
-          retval += m_currentEstimatedRtt;
-        }
-    }
-  else
-    {
-      int64_t temp = m_currentEstimatedRtt.ToInteger (Time::S) + 4 * m_variance.ToInteger (Time::S);
-      retval = Time::FromInteger (temp, Time::S);
-    }
-  NS_LOG_DEBUG ("RetransmitTimeout:  return " << (retval > m_minRto ? retval.GetSeconds () : m_minRto.GetSeconds ()));
-  return (retval > m_minRto ? retval : m_minRto);  // return maximum
+      temp = m_minRto.ToInteger (Time::MS);
+    } 
+  temp = temp * m_multiplier; // Apply backoff
+  Time retval = Time::FromInteger (temp, Time::MS);
+  NS_LOG_DEBUG ("RetransmitTimeout:  return " << retval.GetSeconds ());
+  return (retval);  
 }

 Ptr<RttEstimator> RttMeanDeviation::Copy () const
--- a/src/internet/model/tcp-l4-protocol.cc
+++ b/src/internet/model/tcp-l4-protocol.cc
@@ -132,12 +132,12 @@ TcpL4Protocol::NotifyNewAggregate ()
  // need to keep track of whether we are connected to an IPv4 or
  // IPv6 lower layer and call the appropriate one.
  
-  if (ipv4 != 0)
+  if (ipv4 != 0 && m_downTarget.IsNull ())
    {
      ipv4->Insert(this);
      this->SetDownTarget(MakeCallback(&Ipv4::Send, ipv4));
    }
-  if (ipv6 != 0)
+  if (ipv6 != 0 && m_downTarget6.IsNull ())
    {
      ipv6->Insert(this);
      this->SetDownTarget6(MakeCallback(&Ipv6L3Protocol::Send, ipv6));
--- a/src/internet/model/udp-l4-protocol.cc
+++ b/src/internet/model/udp-l4-protocol.cc
@@ -88,6 +88,7 @@ UdpL4Protocol::SetNode (Ptr<Node> node)
 void
 UdpL4Protocol::NotifyNewAggregate ()
 {
+  NS_LOG_FUNCTION (this);
  Ptr<Node> node = this->GetObject<Node> ();
  Ptr<Ipv4> ipv4 = this->GetObject<Ipv4> ();
  Ptr<Ipv6L3Protocol> ipv6 = node->GetObject<Ipv6L3Protocol> ();
@@ -108,12 +109,12 @@ UdpL4Protocol::NotifyNewAggregate ()
  // need to keep track of whether we are connected to an IPv4 or
  // IPv6 lower layer and call the appropriate one.
  
-  if (ipv4 != 0)
+  if (ipv4 != 0 && m_downTarget.IsNull())
    {
      ipv4->Insert (this);
      this->SetDownTarget (MakeCallback (&Ipv4::Send, ipv4));
    }
-  if (ipv6 != 0)
+  if (ipv6 != 0 && m_downTarget6.IsNull())
    {
      ipv6->Insert (this);
      this->SetDownTarget6 (MakeCallback (&Ipv6L3Protocol::Send, ipv6));
@@ -499,6 +500,7 @@ UdpL4Protocol::Send (Ptr<Packet> packet,
 void
 UdpL4Protocol::SetDownTarget (IpL4Protocol::DownTargetCallback callback)
 {
+  NS_LOG_FUNCTION (this);
  m_downTarget = callback;
 }

@@ -511,6 +513,7 @@ UdpL4Protocol::GetDownTarget (void) const
 void
 UdpL4Protocol::SetDownTarget6 (IpL4Protocol::DownTargetCallback6 callback)
 {
+  NS_LOG_FUNCTION (this);
  m_downTarget6 = callback;
 }

--- a/src/network/doc/queue.rst
+++ b/src/network/doc/queue.rst
@@ -0,0 +1,165 @@
+Queues
+------
+
+.. heading hierarchy:
+   ------------- Chapter
+   ************* Section (#.#)
+   ============= Subsection (#.#.#)
+   ############# Paragraph (no number)
+
+This section documents a few queue objects, typically associated with
+NetDevice models, that are maintained as part of the ``network`` module:
+
+* DropTail
+* Random Early Detection 
+
+Model Description
+*****************
+
+The source code for the new module lives in the directory ``src/network/utils``.
+
+ns-3 provides a couple of classic queue models and the ability to
+trace certain queue operations such as enqueuing, dequeuing, and dropping.
+These may be added to certain NetDevice objects that take a Ptr<Queue>
+pointer.
+
+Note that not all device models use these queue models.  
+In particular, WiFi, WiMax, and LTE use specialized device queues.
+The queue models described here are more often used with simpler ns-3 
+device models such as PointToPoint and Csma.
+
+Design
+======
+
+An abstract base class, class Queue, is typically used and subclassed
+for specific scheduling and drop policies.  Common operations
+include:
+
+* ``bool Enqueue (Ptr<Packet> p)``:  Enqueue a packet
+* ``Ptr<Packet> Dequeue (void)``:  Dequeue a packet
+* ``uint32_t GetNPackets (void)``:  Get the queue depth, in packets
+* ``uint32_t GetNBytes (void)``:  Get the queue depth, in packets
+
+as well as tracking some statistics on queue operations.
+
+There are three trace sources that may be hooked:
+
+* ``Enqueue``
+* ``Dequeue``
+* ``Drop``
+
+DropTail
+########
+
+This is a basic first-in-first-out (FIFO) queue that performs a tail drop
+when the queue is full.
+
+Random Early Detection
+######################
+
+Random Early Detection (RED) is a queue variant that aims to provide
+early signals to transport protocol congestion control (e.g. TCP) that
+congestion is imminent, so that they back off their rate gracefully
+rather than with a bunch of tail-drop losses (possibly incurring
+TCP timeout).  The model in ns-3 is a port of Sally Floyd's ns-2
+RED model.
+
+Scope and Limitations
+=====================
+
+The RED model just supports default RED.  Adaptive RED is not supported.
+
+References
+==========
+
+The RED queue aims to be close to the results cited in:
+S.Floyd, K.Fall http://icir.org/floyd/papers/redsims.ps
+
+Usage
+*****
+
+Helpers
+=======
+
+A typical usage pattern is to create a device helper and to configure
+the queue type and attributes from the helper, such as this example
+from ``src/network/examples/red-tests.cc``:
+
+:: 
+
+  PointToPointHelper p2p;
+
+  p2p.SetQueue ("ns3::DropTailQueue");
+  p2p.SetDeviceAttribute ("DataRate", StringValue ("10Mbps"));
+  p2p.SetChannelAttribute ("Delay", StringValue ("2ms"));
+  NetDeviceContainer devn0n2 = p2p.Install (n0n2);
+
+  p2p.SetQueue ("ns3::DropTailQueue");
+  p2p.SetDeviceAttribute ("DataRate", StringValue ("10Mbps"));
+  p2p.SetChannelAttribute ("Delay", StringValue ("3ms"));
+  NetDeviceContainer devn1n2 = p2p.Install (n1n2);
+
+  p2p.SetQueue ("ns3::RedQueue", // only backbone link has RED queue
+                "LinkBandwidth", StringValue (redLinkDataRate),
+                "LinkDelay", StringValue (redLinkDelay));
+  p2p.SetDeviceAttribute ("DataRate", StringValue (redLinkDataRate));
+  p2p.SetChannelAttribute ("Delay", StringValue (redLinkDelay));
+  NetDeviceContainer devn2n3 = p2p.Install (n2n3);
+
+
+Attributes
+==========
+
+The RED queue contains a number of attributes that control the RED
+policies:
+
+* Mode (bytes or packets)
+* MeanPktSize
+* IdlePktSize
+* Wait (time)
+* Gentle mode
+* MinTh, MaxTh
+* QueueLimit
+* Queue weight
+* LInterm
+* LinkBandwidth
+* LinkDelay
+
+Consult the ns-3 documentation for explanation of these attributes.
+
+Output
+======
+
+The ns-3 ascii trace helpers used by many of the NetDevices will hook
+the Enqueue, Dequeue, and Drop traces of these queues and print out 
+trace statements, such as the following from ``examples/udp/udp-echo.cc``:
+
+::
+
+  + 2 /NodeList/0/DeviceList/1/$ns3::CsmaNetDevice/TxQueue/Enqueue ns3::EthernetHeader 
+  ( length/type=0x806, source=00:00:00:00:00:01, destination=ff:ff:ff:ff:ff:ff) 
+  ns3::ArpHeader (request source mac: 00-06-00:00:00:00:00:01 source ipv4: 10.1.1.1 
+  dest ipv4: 10.1.1.2) Payload (size=18) ns3::EthernetTrailer (fcs=0)
+  - 2 /NodeList/0/DeviceList/1/$ns3::CsmaNetDevice/TxQueue/Dequeue ns3::EthernetHeader 
+  ( length/type=0x806, source=00:00:00:00:00:01, destination=ff:ff:ff:ff:ff:ff) 
+  ns3::ArpHeader (request source mac: 00-06-00:00:00:00:00:01 source ipv4: 10.1.1.1 
+  dest ipv4: 10.1.1.2) Payload (size=18) ns3::EthernetTrailer (fcs=0)
+
+which shows an enqueue "+" and dequeue "-" event at time 2 seconds.
+
+Users are, of course, free to define and hook their own trace sinks to
+these trace sources.
+
+Examples
+========
+
+The drop-tail queue is used in several examples, such as 
+``examples/udp/udp-echo.cc``.  The RED queue example is found at
+``src/network/examples/red-tests.cc``.
+
+Validation
+**********
+
+The RED model has been validated and the report is currently stored
+at: https://github.com/downloads/talau/ns-3-tcp-red/report-red-ns3.pdf 
+
--- a/src/virtual-net-device/bindings/callbacks_list.py
+++ b/src/virtual-net-device/bindings/callbacks_list.py
@@ -0,0 +1,6 @@
+callback_classes = [
+    ['bool', 'ns3::Ptr<ns3::NetDevice>', 'ns3::Ptr<ns3::Packet const>', 'unsigned short', 'ns3::Address const&', 'ns3::Address const&', 'ns3::NetDevice::PacketType', 'ns3::empty', 'ns3::empty', 'ns3::empty'],
+    ['bool', 'ns3::Ptr<ns3::NetDevice>', 'ns3::Ptr<ns3::Packet const>', 'unsigned short', 'ns3::Address const&', 'ns3::empty', 'ns3::empty', 'ns3::empty', 'ns3::empty', 'ns3::empty'],
+    ['bool', 'ns3::Ptr<ns3::Packet>', 'ns3::Address const&', 'ns3::Address const&', 'unsigned short', 'ns3::empty', 'ns3::empty', 'ns3::empty', 'ns3::empty', 'ns3::empty'],
+    ['void', 'ns3::Ptr<ns3::NetDevice>', 'ns3::Ptr<ns3::Packet const>', 'unsigned short', 'ns3::Address const&', 'ns3::Address const&', 'ns3::NetDevice::PacketType', 'ns3::empty', 'ns3::empty', 'ns3::empty'],
+]
--- a/src/virtual-net-device/bindings/modulegen__gcc_ILP32.py
+++ b/src/virtual-net-device/bindings/modulegen__gcc_ILP32.py
--- a/src/virtual-net-device/bindings/modulegen__gcc_LP64.py
+++ b/src/virtual-net-device/bindings/modulegen__gcc_LP64.py
--- a/src/virtual-net-device/wscript
+++ b/src/virtual-net-device/wscript
@@ -14,3 +14,5 @@ def build(bld):

    if bld.env['ENABLE_EXAMPLES']:
        bld.add_subdirs('examples')
+
+    bld.ns3_python_bindings()
--- a/src/visualizer/model/pyviz.cc
+++ b/src/visualizer/model/pyviz.cc
@@ -265,8 +265,11 @@ void
 PyViz::CallbackStopSimulation ()
 {
  NS_LOG_FUNCTION_NOARGS ();
-  Simulator::Stop (Seconds (0)); // Stop right now
-  m_stop = true;
+  if (m_runUntil <= Simulator::Now ())
+    {
+      Simulator::Stop (Seconds (0)); // Stop right now
+      m_stop = true;
+    }
 }

 void
@@ -316,9 +319,9 @@ PyViz::SimulatorRunUntil (Time time)
  // sure we stop at the right time.  Otherwise, simulations with few
  // events just appear to "jump" big chunks of time.
  NS_LOG_LOGIC ("Schedule dummy callback to be called in " << (time - Simulator::Now ()));
+  m_runUntil = time;
  m_stop = false;
-  Simulator::Cancel (m_stopCallbackEvent);
-  m_stopCallbackEvent = Simulator::Schedule (time - Simulator::Now (), &PyViz::CallbackStopSimulation, this);
+  Simulator::ScheduleWithContext (0xffffffff, time - Simulator::Now (), &PyViz::CallbackStopSimulation, this);

  Ptr<SimulatorImpl> impl = Simulator::GetImplementation ();
  Ptr<VisualSimulatorImpl> visualImpl = DynamicCast<VisualSimulatorImpl> (impl);
--- a/src/visualizer/model/pyviz.h
+++ b/src/visualizer/model/pyviz.h
@@ -220,7 +220,7 @@ private:
  void DoPause (std::string const &message);

  bool m_stop;
-  EventId m_stopCallbackEvent;
+  Time m_runUntil;
  void CallbackStopSimulation ();
 };

--- a/src/visualizer/visualizer/base.py
+++ b/src/visualizer/visualizer/base.py
@@ -43,8 +43,8 @@ netdevice_traits = {
    ns.mesh.MeshPointDevice: NetDeviceTraits(is_virtual=True),
    ns.wimax.SubscriberStationNetDevice: NetDeviceTraits(is_wireless=True),
    ns.wimax.BaseStationNetDevice: NetDeviceTraits(is_wireless=True),
-    ns.lte.UeNetDevice: NetDeviceTraits(is_wireless=True),
-    ns.lte.EnbNetDevice: NetDeviceTraits(is_wireless=True),
+    ns.lte.LteUeNetDevice: NetDeviceTraits(is_wireless=True),
+    ns.lte.LteEnbNetDevice: NetDeviceTraits(is_wireless=True),
 }

 def lookup_netdevice_traits(class_type):
--- a/3
+++ b/3
@@ -823,6 +823,9 @@ def build(bld):
        # nothing more; this greatly speeds up compilation when all you
        # want to do is run a test program.
        Options.options.targets += ',' + os.path.basename(program_name)
+        if getattr(Options.options, "visualize", False):
+            program_obj = wutils.find_program(program_name, bld.env)
+            program_obj.use.append('ns3-visualizer')
        for gen in bld.all_task_gen:
            if type(gen).__name__ in ['ns3header_taskgen', 'ns3moduleheader_taskgen']:
                gen.post()