GSoC topic introduction and queries

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC topic introduction and queries

Vivek Jain
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.

Thanks and Regards,
Vivek Jain

[1] https://codereview.appspot.com/319090043/
[2] https://github.com/weiglemc/tmix-ns3
Reply | Threaded
Open this post in threaded view
|

Re: GSoC topic introduction and queries

Tom Henderson-2
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/pipermail/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
Reply | Threaded
Open this post in threaded view
|

Re: GSoC topic introduction and queries

Vivek Jain
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.

Other points:

Existing implementation doesn’t uses block resampling and load scaling
techniques to scale existing connection vector to generate a target load
and replay the trace for a specified duration.

Bugs are observed in the existing code which should be considered while
restructuring, for example: multiple NetDevices in the same node when
multiple applications are configured on it.

Existing implementation of DelayBox and Tmix lacks documentation and
examples which reduces usability. To enhance this, I can develop various
examples with proper documentation of models and examples.

Queries:

Yes, developing a tool to obtain more cvecs from recent traces would be
really nice. But I’m not sure how to go about collecting new traces. Can
you suggest some pointers for this?

Vivek Jain

On Fri, Mar 17, 2017 at 10:49 PM, Tom Henderson <[hidden email]> wrote:

> 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
>