GSoC topic introduction and queries

GSoC topic introduction and queries

Hello all,

I am Vivek Jain, Masters student at NITK Surathkal, India and have been
working with ns-3 from past few months. I completed the implementation BLUE
queue disc (currently under review [1]), and as a part of my current course
work, I am in the process of implementing TCP-Jersey in ns-3.

I'm interested to participate in GSoC 2017 by applying for the project
named "ns-2 ports to ns-3". In particular, I wish to port Tmix module of
ns-2 to ns-3.

I noticed that Tmix is used for generating realistic TCP traffic and is
available in the mainline of ns-2. Although one implementation exists for
Tmix in ns-3 [2], I observed the following:

1. Many features are pending. (the code contains many //ToDo and
//FIXMEs)
2. In the current form, its implementation differs from that of ns-2.
I'm preparing a list of the differences and will be sharing the same here
soon.

Re: GSoC topic introduction and queries

On 03/15/2017 11:59 PM, Vivek Jain wrote:

> Hello all,
>
> I am Vivek Jain, Masters student at NITK Surathkal, India and have been
> working with ns-3 from past few months. I completed the implementation BLUE
> queue disc (currently under review [1]), and as a part of my current course
> work, I am in the process of implementing TCP-Jersey in ns-3.
>
> I'm interested to participate in GSoC 2017 by applying for the project
> named "ns-2 ports to ns-3". In particular, I wish to port Tmix module of
> ns-2 to ns-3.
>
> I noticed that Tmix is used for generating realistic TCP traffic and is
> available in the mainline of ns-2. Although one implementation exists for
> Tmix in ns-3 [2], I observed the following:
>
> 1. Many features are pending. (the code contains many //ToDo and
> //FIXMEs)
> 2. In the current form, its implementation differs from that of ns-2.
> I'm preparing a list of the differences and will be sharing the same here
> soon.
>
> I look forward to know your insights over this.

I believe that work on progressing the Tmix implementation would be
useful, but my thoughts on this are as follows. The basic port of this
is already done, but as you point out, many features/issues are pending,
including DelayBox which would be a useful capability.

I don't think that preserving the ns-2 implementation structure is
necessarily important. I would not focus on trying to make the ns-3
version as much aligned as possible to ns-2 and reproducing ns-2
results. Instead, please consider to look forward as to how to make it
useful to future research.

For example, the existing connection vectors (from traces) are over a
decade old; should they be refreshed? Should some effort be expended to
write a tool to generate updated connection vectors from more current
traces?

Since Tmix was published, how has the field of open source traffic
generators evolved, and are there any developments that Tmix should try
to align to?

How can ns-3 users easily configure Tmix and DelayBox and also easily
obtain performance data from those components or from the flows involved?

Re: GSoC topic introduction and queries

Hello,

Thanks for your suggestions.

I have prepared the following points for the GSoC project:

DelayBox implementation as plugin on NetDevice Model:

Existing implementation of DelayBox is available as template class which
takes NetDevice model as it’s input datatype. In my opinion, implementing
DelayBox as a plugin on NetDevice will be more simpler because the existing
implementation requires a user to use DelayBox as separate object. With my
proposed approach, a user can choose to use DelayBox or not by simply
enabling or disabling a flag.

Restructuring the Tmix implementation:

Restructuring of Tmix implementation is required as there are many ToDos
and FixMes. For example, the values of delay and bandwidth are hard coded
in Tmix Topology. Instead, this should be user configurable. Also, some of
the methods are not yet implemented, for example, SerializeToXmlStream ( )
under TcpFlowClassifier class to serialize tcp flows into xml file. This
can be implemented using FlowMon.

Support for both types connection vector (cvecs) in Tmix for ns-3:

ns-2 supports two types of cvecs format: original and alternate. Existing
implementation of Tmix for ns-3 supports only the alternate format. It
would be better to provide support for both types of cvecs.

> On 03/15/2017 11:59 PM, Vivek Jain wrote:
>
>> Hello all,
>>
>> I am Vivek Jain, Masters student at NITK Surathkal, India and have been
>> working with ns-3 from past few months. I completed the implementation
>> BLUE
>> queue disc (currently under review [1]), and as a part of my current
>> course
>> work, I am in the process of implementing TCP-Jersey in ns-3.
>>
>> I'm interested to participate in GSoC 2017 by applying for the project
>> named "ns-2 ports to ns-3". In particular, I wish to port Tmix module of
>> ns-2 to ns-3.
>>
>> I noticed that Tmix is used for generating realistic TCP traffic and is
>> available in the mainline of ns-2. Although one implementation exists for
>> Tmix in ns-3 [2], I observed the following:
>>
>> 1. Many features are pending. (the code contains many //ToDo and
>> //FIXMEs)
>> 2. In the current form, its implementation differs from that of ns-2.
>> I'm preparing a list of the differences and will be sharing the same
>> here
>> soon.
>>
>> I look forward to know your insights over this.
>>
>
> Hi Vivek,
> Dharmendra Mishra was looking into Tmix improvements last year in the
> context of the TCP evaluation suite; have you checked with him about any
> progress? See for instance: http://mailman.isi.edu/piperma> il/ns-developers/2016-July/013644.html
>
> I believe that work on progressing the Tmix implementation would be
> useful, but my thoughts on this are as follows. The basic port of this is
> already done, but as you point out, many features/issues are pending,
> including DelayBox which would be a useful capability.
>
> I don't think that preserving the ns-2 implementation structure is
> necessarily important. I would not focus on trying to make the ns-3
> version as much aligned as possible to ns-2 and reproducing ns-2 results.
> Instead, please consider to look forward as to how to make it useful to
> future research.
>
> For example, the existing connection vectors (from traces) are over a
> decade old; should they be refreshed? Should some effort be expended to
> write a tool to generate updated connection vectors from more current
> traces?
>
> Since Tmix was published, how has the field of open source traffic
> generators evolved, and are there any developments that Tmix should try to
> align to?
>
> How can ns-3 users easily configure Tmix and DelayBox and also easily
> obtain performance data from those components or from the flows involved?
>
> - Tom
>