Outline of proposed tutorial extension

Queues in ns-3
--------------

The selection of queueing disciplines in |ns3| can have a large impact
on performance, and it is important for users to understand what is installed
by default and how to change the defaults and observe the performance.

Architecturally, |ns3| separates the device layer from the IP layers 
or traffic control layers of an Internet host.  Since recent releases
of |ns3|, outgoing packets traverse two queueing layers before reaching
the channel object.  The first queueing layer encountered is what is
called the 'traffic control layer' in |ns3|; here, active queue management
(RFC7567) and prioritization due to quality-of-service (QoS) takes place
in a device-independent manner.  The second queueing layer is typically
found in the NetDevice objects.   Different devices (e.g. LTE, Wi-Fi)
have different implementations of these queues.  This two-layer approach
mirrors what is found in practice, (software queues providing prioritization,
and hardware queues specific to a link type).  In practice, it may be
even more complex than this.  For instance, address resolution protocols
have a small queue.  Wi-Fi in Linux has four layers of queueuing
(https://lwn.net/Articles/705884/).

Queues by default in |ns3| are not autotuned for the configured link
properties (bandwidth, delay), and are typically the simplest variants
(e.g. FIFO scheduling with drop-tail behavior).  

Available queueing models in |ns3|
----------------------------------

At the traffic-control layer, these are the options:

* pfifo_fast
* red
* adaptive red
* codel
* fq_codel
* (mention bql)

Mention that default configuration of traffic control provides the default
pfifoFast...

At the device layer, there are device specific queues:

* Point-To-Point: The default configuration is ...
* Csma:  ...
* Wi-Fi: ...
* LTE: ...
* (others?)

Changing from the defaults
--------------------------

* How to change a P-to-p or CSMA queue mode or limit from the default
* How to change Pfifo-fast to Codel at the tc layer
* (others?)

Tracing
-------

(there are a lot of trace hooks.  It probably would be useful to revisit
the queues after tracing is later introduced in the tutorial, and show how
e.g. BytesInQueue may be traced and plotted.)

(specifically, I can imagine a new tutorial example specifically tailored
to trace end-to-end latency, and showing how substitution of different
configurations and AQMs affects performance, but this is different than
second.cc which uses a very trivial application with very low data rate).