GSoC 2017: Project Idea "ns-2 ports to ns-3”

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

GSoC 2017: Project Idea "ns-2 ports to ns-3”

Isha Tarte
Hello everyone,

I am Isha Tarte, junior year undergrad in the Dept. of Computer Science and
Engineering at NITK Surathkal, India. I am interested to apply for the GSoC
project idea "ns-2 ports to ns-3".

I have one year of experience with network simulation. Initially, I used
ns-2 and have some experience with OTcl. Currently, I'm working on ns-3 in
my project where one major part is to port Random Exponential Algorithm
(REM) from ns-2 to ns-3.

I am interested to implement "Rate Based Pacing(RBP) for TCP" in ns-3
during GSoc time frame. Rate based pacing addresses the slow-start restart
problem when the connection goes idle. Some TCP implementations force
slow-start again. Other implementations do not detect this idle time and
thus use the old value of the congestion window. Rate based pacing send
segments at a certain pace until we get the ACK clock running again. This
pace or rate should be based on a fraction of prior estimates of data
transfer rate, since that is the closest estimate of available bandwidth.

RBP is implemented in ns-2 (/tcp/tcp-rbp.cc) for TCP Reno and TCP Vegas.

I plan to implement RBP for TCP NewReno and TCP Vegas in ns-3.

Rate based pacing requires the following changes to TCP:

   1.

   Idle time detection and indication that RBP needs to be started.
   2.

   Bandwidth estimation.
   3.

   Calculation of the window that we expect to send in RBP and the timing
   between segments in that window.
   4.

   A mechanism that clocks the segments sent in RBP.


Reference:

Rate Based Pacing for TCP -

http://www.isi.edu/lsam/publications/rate_based_pacing/index.html



Thanks,

Isha Tarte
Reply | Threaded
Open this post in threaded view
|

Fwd: [Ns-developers] GSoC 2017: Project Idea "ns-2 ports to ns-3”

Natale Patriciello
I'm sorry, the GMail web interface is something that goes agains more than
40 years of email evolution.

---------- Forwarded message ----------
From: Natale Patriciello <[hidden email]>
Date: 2017-03-17 9:32 GMT+01:00
Subject: Re: [Ns-developers] GSoC 2017: Project Idea "ns-2 ports to ns-3”
To: Isha Tarte <[hidden email]>


2017-03-15 5:53 GMT+01:00 Isha Tarte <[hidden email]>:

> Hello everyone,
>
> I am Isha Tarte, junior year undergrad in the Dept. of Computer Science and
> Engineering at NITK Surathkal, India. I am interested to apply for the GSoC
> project idea "ns-2 ports to ns-3".
>
> I have one year of experience with network simulation. Initially, I used
> ns-2 and have some experience with OTcl. Currently, I'm working on ns-3 in
> my project where one major part is to port Random Exponential Algorithm
> (REM) from ns-2 to ns-3.
>
> I am interested to implement "Rate Based Pacing(RBP) for TCP" in ns-3
> during GSoc time frame. Rate based pacing addresses the slow-start restart
> problem when the connection goes idle. Some TCP implementations force
> slow-start again. Other implementations do not detect this idle time and
> thus use the old value of the congestion window. Rate based pacing send
> segments at a certain pace until we get the ACK clock running again. This
> pace or rate should be based on a fraction of prior estimates of data
> transfer rate, since that is the closest estimate of available bandwidth.
>
> RBP is implemented in ns-2 (/tcp/tcp-rbp.cc) for TCP Reno and TCP Vegas.
>
> I plan to implement RBP for TCP NewReno and TCP Vegas in ns-3.
>
> Rate based pacing requires the following changes to TCP:
>
>    1.
>
>    Idle time detection and indication that RBP needs to be started.
>    2.
>
>    Bandwidth estimation.
>    3.
>
>    Calculation of the window that we expect to send in RBP and the timing
>    between segments in that window.
>    4.
>
>    A mechanism that clocks the segments sent in RBP.
>
>
> Reference:
>
> Rate Based Pacing for TCP -
>
> http://www.isi.edu/lsam/publications/rate_based_pacing/index.html
>

Hello Isha,

 While you are free to submit your proposal on the Google web page (and
mentors will take care of reviewing and selecting projects), I would like
to state that what you have written here is not very interesting for a
GSoC. In 2017, you are proposing to implement something born in 1997 (20
years ago) without any practical purpose. Moreover, your changes are so
invasive that I don't think you can do them in the time span of three
months. Honestly, I do not doubt your skill, but I'm inviting you to
re-think your proposal in the light of the following:

*) In the Linux kernel, TCP pacing is done through the FQ scheduler family.
The TCP could influence the scheduler through some variables in the socket,
for example suggesting the right pacing value. In ns-3 we already have the
infrastructure, but we miss many of the FQ-family schedulers as well as the
API to make the two layer communicate. This would be a great addition, in
line with current times, that is proven to work better than the 1997
proposal.

*) We simply miss IDLE time in TCP, for all the TCP. If we have no data to
send, the TCP will wait, and when the buffer is ready again, we use the old
cWnd value (as you suggested). Another superb idea would be to implement
the idle/start mechanism (your first point) but then do as in the Linux
kernel (with an API to manage such events). Moreover, we miss applications
that generate bulk of data in a user-friendly way. OnOffApplication is too
hard to use when a researcher just wants to model an HTTP connection.
Around here there are some proposals, you could take a loot to some of then
and check/verify the TCP idle/start with these. It's not as appealing as
the first one, but still could be an excellent addition.

Thank you for taking the time to examine these two points. As I said
before, I'm not involved in the selection of the projects, so be free to
submit your proposals as you wrote.

Nat
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2017: Project Idea "ns-2 ports to ns-3”

Isha Tarte
In reply to this post by Isha Tarte
Hello everyone, In light of the previous mail sent by Natale Patriciello, I
studied and considered the ideas suggested by him. As Ankit has already
implemented TCP Pacing, I discussed with him regarding implementation of
scheduling algorithms in ns-3. I am still inclined to work on “ns-2 ports
to ns-3” project and would like to implement “Deficit Round Robin”
scheduling algorithm in ns-3 during the GSoC time frame. It is a widely
used queuing discipline, also being used in the upcoming Cake queue disc
for Linux. It is already implemented in ns-2. DRR is a modification of
round robin algorithm where each queue is assigned a weight called quantum.
In each round, a queue can send maximum quantum number of bytes. The only
difference is that if a queue was not able to send a packet in the previous
round because its packet size was too large, the remainder from the
previous quantum is added to the quantum for the next round. A variable
deficit counter is used to keep track of the amount of bytes sent by a
queue. It uses hashing to determine the queue to which a flow has to be
assigned. I have the following tentative plan for GSoC: Phase 1: Getting a
thorough understanding of implementation of DRR in ns-2 and Linux. Gaining
familiarity with traffic control model in ns-3 Put up a skeleton for
implementing DRR in ns-3 Phase 2: Implementing DRR in ns-3 Writing test
cases and example program for DRR Addressing the comments for Phase 1 task
Phase 3: Comparing DRR with other scheduling models and providing an
example for same. Verification and documentation of the implemented model.
Addressing the comments for Phase 2 task. Get the final code ready to merge
Please let me know your suggestions. Thanks, Isha Tarte
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2017: Project Idea "ns-2 ports to ns-3”

Isha Tarte
Hello everyone,

In light of the previous mail sent by Natale Patriciello, I studied and
considered the ideas suggested by him. As Ankit has already implemented TCP
Pacing, I discussed with him regarding implementation of scheduling
algorithms in ns-3.

I am still inclined to work on "ns-2 ports to ns-3" project and would like
to implement “Deficit Round Robin” scheduling algorithm in ns-3 during the
GSoC time frame. It is a widely used queuing discipline, also being used in
the upcoming Cake queue disc for Linux. It is already implemented in ns-2.

DRR is a modification of round robin algorithm where each queue is assigned
a weight called quantum. In each round, a queue can send maximum quantum
number of bytes. The only difference is that if a queue was not able to
send a packet in the previous round because its packet size was too large,
the remainder from the previous quantum is added to the quantum for the
next round. A variable deficit counter is used to keep track of the amount
of bytes sent by a queue. It uses hashing to determine the queue to which a
flow has to be assigned.

I have the following tentative plan for GSoC:

Phase 1:
- Getting a thorough understanding of implementation of DRR in ns-2 and
Linux.
- Gaining familiarity with traffic control model in ns-3.
- Put up a skeleton for implementing DRR in ns-3.

Phase 2:
- Implementing DRR in ns-3.
- Writing test cases and example program for DRR
- Addressing the comments for Phase 1 task

Phase 3:
- Comparing DRR with other scheduling models and providing an example for
same.
- Verification and documentation of the implemented model.
- Addressing the comments for Phase 2 task.
- Get the final code ready to merge.

Please let me know your suggestions.

Thanks,
Isha Tarte

On Fri, Mar 31, 2017 at 3:10 PM, Isha Tarte <[hidden email]> wrote:

> Hello everyone, In light of the previous mail sent by Natale Patriciello,
> I studied and considered the ideas suggested by him. As Ankit has already
> implemented TCP Pacing, I discussed with him regarding implementation of
> scheduling algorithms in ns-3. I am still inclined to work on “ns-2 ports
> to ns-3” project and would like to implement “Deficit Round Robin”
> scheduling algorithm in ns-3 during the GSoC time frame. It is a widely
> used queuing discipline, also being used in the upcoming Cake queue disc
> for Linux. It is already implemented in ns-2. DRR is a modification of
> round robin algorithm where each queue is assigned a weight called quantum.
> In each round, a queue can send maximum quantum number of bytes. The only
> difference is that if a queue was not able to send a packet in the previous
> round because its packet size was too large, the remainder from the
> previous quantum is added to the quantum for the next round. A variable
> deficit counter is used to keep track of the amount of bytes sent by a
> queue. It uses hashing to determine the queue to which a flow has to be
> assigned. I have the following tentative plan for GSoC: Phase 1: Getting a
> thorough understanding of implementation of DRR in ns-2 and Linux. Gaining
> familiarity with traffic control model in ns-3 Put up a skeleton for
> implementing DRR in ns-3 Phase 2: Implementing DRR in ns-3 Writing test
> cases and example program for DRR Addressing the comments for Phase 1 task
> Phase 3: Comparing DRR with other scheduling models and providing an
> example for same. Verification and documentation of the implemented model.
> Addressing the comments for Phase 2 task. Get the final code ready to merge
> Please let me know your suggestions. Thanks, Isha Tarte
>
>
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2017: Project Idea "ns-2 ports to ns-3”

Stefano Avallone
Hello Isha,

I have no previous experience as a GSoC mentor, but my impression is that a
proposal only based on DRR might be a bit "light". Perhaps you might target a
couple of schedulers, like DRR and FQ.

Regards,
Stefano


On venerdì 31 marzo 2017 12:33:15 CEST Isha Tarte wrote:

> Hello everyone,
>
> In light of the previous mail sent by Natale Patriciello, I studied and
> considered the ideas suggested by him. As Ankit has already implemented TCP
> Pacing, I discussed with him regarding implementation of scheduling
> algorithms in ns-3.
>
> I am still inclined to work on "ns-2 ports to ns-3" project and would like
> to implement “Deficit Round Robin” scheduling algorithm in ns-3 during the
> GSoC time frame. It is a widely used queuing discipline, also being used in
> the upcoming Cake queue disc for Linux. It is already implemented in ns-2.
>
> DRR is a modification of round robin algorithm where each queue is assigned
> a weight called quantum. In each round, a queue can send maximum quantum
> number of bytes. The only difference is that if a queue was not able to
> send a packet in the previous round because its packet size was too large,
> the remainder from the previous quantum is added to the quantum for the
> next round. A variable deficit counter is used to keep track of the amount
> of bytes sent by a queue. It uses hashing to determine the queue to which a
> flow has to be assigned.
>
> I have the following tentative plan for GSoC:
>
> Phase 1:
> - Getting a thorough understanding of implementation of DRR in ns-2 and
> Linux.
> - Gaining familiarity with traffic control model in ns-3.
> - Put up a skeleton for implementing DRR in ns-3.
>
> Phase 2:
> - Implementing DRR in ns-3.
> - Writing test cases and example program for DRR
> - Addressing the comments for Phase 1 task
>
> Phase 3:
> - Comparing DRR with other scheduling models and providing an example for
> same.
> - Verification and documentation of the implemented model.
> - Addressing the comments for Phase 2 task.
> - Get the final code ready to merge.
>
> Please let me know your suggestions.
>
> Thanks,
> Isha Tarte
>
> On Fri, Mar 31, 2017 at 3:10 PM, Isha Tarte <[hidden email]> wrote:
> > Hello everyone, In light of the previous mail sent by Natale Patriciello,
> > I studied and considered the ideas suggested by him. As Ankit has already
> > implemented TCP Pacing, I discussed with him regarding implementation of
> > scheduling algorithms in ns-3. I am still inclined to work on “ns-2 ports
> > to ns-3” project and would like to implement “Deficit Round Robin”
> > scheduling algorithm in ns-3 during the GSoC time frame. It is a widely
> > used queuing discipline, also being used in the upcoming Cake queue disc
> > for Linux. It is already implemented in ns-2. DRR is a modification of
> > round robin algorithm where each queue is assigned a weight called
> > quantum.
> > In each round, a queue can send maximum quantum number of bytes. The only
> > difference is that if a queue was not able to send a packet in the
> > previous
> > round because its packet size was too large, the remainder from the
> > previous quantum is added to the quantum for the next round. A variable
> > deficit counter is used to keep track of the amount of bytes sent by a
> > queue. It uses hashing to determine the queue to which a flow has to be
> > assigned. I have the following tentative plan for GSoC: Phase 1: Getting a
> > thorough understanding of implementation of DRR in ns-2 and Linux. Gaining
> > familiarity with traffic control model in ns-3 Put up a skeleton for
> > implementing DRR in ns-3 Phase 2: Implementing DRR in ns-3 Writing test
> > cases and example program for DRR Addressing the comments for Phase 1 task
> > Phase 3: Comparing DRR with other scheduling models and providing an
> > example for same. Verification and documentation of the implemented model.
> > Addressing the comments for Phase 2 task. Get the final code ready to
> > merge
> > Please let me know your suggestions. Thanks, Isha Tarte