CBR (constant bit-rate) application and advanced funtionality for OnOffApplication

Added a new CBR (constant bit-rate) application and advanced functionality for OnOffApplication. 

- CBR application generates constant-sized packets at a constant interval. The functionality is pretty much the same as in old version of OnOffApplication, but data rate is configured by using attributes "PacketSize" and "Interval" rather than data rate. 

- OnOff application has a few new attributes: "AdvancedMode", "AdvancedPacketSize" and "AdvancedPacketInterval". "AdvancedMode" attribute is a flag enabling the use of random variable streams as sources for generated packet sizes and packet intervals rather than constant packet size integer and constant data rate. Advanced mode also disables the effect of "DataRate" attribute. Default functionality of OnOffApplication is left untouched, so it can be configured just as before. 

TrafficTimeTag is also included into stats module to enable extraction of delay statistics in a simple manner. Perhaps adding the TrafficTimeTag caused a slight issue with default src/stats/examples/wscript, or it may have been there before: the time-probe-example caused a dependency problem during compilation, since it did not have 'network' module listed as a dependency. 

There is also an issue with src/traffic-control/examples/red-vs-ared tests run by test.py: due to initialization of new random variable streams "AdvancedPacketSize" and "AdvancedPacketInterval", the default values given by random variables "OnTime" and "OffTime" are altered and the tests fail. This has been verified by commenting out the new attributes in OnOffApplication, effectively removing the initialization of new random variable streams, and the tests passing as usual.

[Tom Henderson, 2017-01-16 00:42:39]

There are three proposals in this patch set:

1) extend OnOffApplication to include an advanced mode
2) add a CBR application/helper (simplified generator restricted to CBR)
3) add a Tag for sender timestamping of packets

Regarding AdvanceMode, I support the idea but would like to suggest splitting
the single Mode to two optional features (RandomSize and RandomInterval) which
may be separately enabled.  I left a patch in tracker issue 2571 for this patch.

Regarding a CBR application/helper, I wonder if we just could use here a new
helper and not an application, since the application mainly duplicates
OnOffApplication functionality?  Could a new CbrHelper simply configure the
OnOffApplication (and replace OnOffHelper::SetConstantRate())?  Or is
OnOffHelper::SetConstantRate() sufficient?  Also, 'Rate' seems a more natural
configuration parameter to support than 'Interval' since people often talk about
a CBR source of some data rate, not a CBR source with a particular packet
interval.

Regarding TrafficTimeTag, we already have SeqTs tag and have a proposal to have
a Seq+two Ts tag (bug 2111), so do we need a third Ts-only tag type?

[lauri.sormunen, 2017-01-16 14:09:28]

On 2017/01/16 00:42:39, Tom Henderson wrote:
> There are three proposals in this patch set:
> 
> 1) extend OnOffApplication to include an advanced mode
> 2) add a CBR application/helper (simplified generator restricted to CBR)
> 3) add a Tag for sender timestamping of packets
> 
> Regarding AdvanceMode, I support the idea but would like to suggest splitting
> the single Mode to two optional features (RandomSize and RandomInterval) which
> may be separately enabled.  I left a patch in tracker issue 2571 for this
patch.
> 
> Regarding a CBR application/helper, I wonder if we just could use here a new
> helper and not an application, since the application mainly duplicates
> OnOffApplication functionality?  Could a new CbrHelper simply configure the
> OnOffApplication (and replace OnOffHelper::SetConstantRate())?  Or is
> OnOffHelper::SetConstantRate() sufficient?  Also, 'Rate' seems a more natural
> configuration parameter to support than 'Interval' since people often talk
about
> a CBR source of some data rate, not a CBR source with a particular packet
> interval.
> 
> Regarding TrafficTimeTag, we already have SeqTs tag and have a proposal to
have
> a Seq+two Ts tag (bug 2111), so do we need a third Ts-only tag type?

1) Splitting the advanced mode functionality is fine. 

2) The CBR helper is enough, even OnOffHelper could suffice, as long as CBR
functionality 
is easily configurable. 

3) Other tags are fine, as long as they include the possibility to save 
time stamp values and extract them later. Current SeqTsHeader is not preferred,
since 
it adds additional overhead, but a Tag with the same functionality suffices. 
The usage of the Tag should be restricted to application layer only, to make
sure 
that no lower-layer object removes it.

[Tommaso Pecorella, 2017-03-01 23:36:52]

On 2017/01/16 14:09:28, lauri.sormunen wrote:
> On 2017/01/16 00:42:39, Tom Henderson wrote:
> > There are three proposals in this patch set:
> > 
> > 1) extend OnOffApplication to include an advanced mode
> > 2) add a CBR application/helper (simplified generator restricted to CBR)
> > 3) add a Tag for sender timestamping of packets
> > 
> > Regarding AdvanceMode, I support the idea but would like to suggest
splitting
> > the single Mode to two optional features (RandomSize and RandomInterval)
which
> > may be separately enabled.  I left a patch in tracker issue 2571 for this
> patch.
> > 
> > Regarding a CBR application/helper, I wonder if we just could use here a new
> > helper and not an application, since the application mainly duplicates
> > OnOffApplication functionality?  Could a new CbrHelper simply configure the
> > OnOffApplication (and replace OnOffHelper::SetConstantRate())?  Or is
> > OnOffHelper::SetConstantRate() sufficient?  Also, 'Rate' seems a more
natural
> > configuration parameter to support than 'Interval' since people often talk
> about
> > a CBR source of some data rate, not a CBR source with a particular packet
> > interval.
> > 
> > Regarding TrafficTimeTag, we already have SeqTs tag and have a proposal to
> have
> > a Seq+two Ts tag (bug 2111), so do we need a third Ts-only tag type?
> 
> 1) Splitting the advanced mode functionality is fine. 
> 
> 2) The CBR helper is enough, even OnOffHelper could suffice, as long as CBR
> functionality 
> is easily configurable. 
> 
> 3) Other tags are fine, as long as they include the possibility to save 
> time stamp values and extract them later. Current SeqTsHeader is not
preferred,
> since 
> it adds additional overhead, but a Tag with the same functionality suffices. 
> The usage of the Tag should be restricted to application layer only, to make
> sure 
> that no lower-layer object removes it.

My 2 cents:

TrafficTimeTag: I have no strong opinions, but I'm kinda against adding stuff
that is not used. I'd not add this right now, and I'd delay it to a well defined
example and use-case.
As a side note, I understand that TrafficTimeTag could be shorter than SeqTs,
but remember that SeqTs is an header, not a tag - wth all the consequences.

Application: I agree with Tom, a "simple" change in the helper (or a new helper)
should be enough.
Probably with the right choice of attributes we could even not need a new helper
at all (but I like the idea to have a CBR helper, it's more intuitive than an
OnOff "tweaked").
However, I'd be more radical with the changes:
- Deprecate the old attributes, only have new ones (fixed size is a
ConstantRandom).
- In the application check if a deprecated attribute has a changed value, and
gracefully print a warning and convert it to the new format.

In this way we'll not need to add flags to use the new features.