Brief Self Intro + GSoC 2017 Project Ideas discussion.

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Brief Self Intro + GSoC 2017 Project Ideas discussion.

Surya Seetharaman
Hello all,

I am Surya (a CS engineer pursuing my master's in network services and
systems with passion for problem solving using programming (C, C++, Python)
); new to the ns-development group. As the ns-3 project aligns with my
filed of interest and study, I am planning to apply for GSoC this year by
contributing to ns-3 which would also enable me to get more proficient with
the simulator (
​want
 to
​ work with​

 ns-3
​;​ as
 I have so far used OMNET++ for most of my work and
​now wanted to try out something new
).

I went through the proposals here : https://www.nsnam.org/wiki/G
SOC2017Projects#Project_Ideas
<https://www.nsnam.org/wiki/GSOC2017Projects#Project_Ideas> and I was
particularly interested in the following ideas (stated in order of
interest) :

   1. *Implementation of realistic traffic shaping algorithms in ns-3*
(motivation
   - came across the packet shaping concept some time back in one of my
   courses and am interested in gaining hands-on experience)* :- * I went
   through the recommended reading. So basically we are looking at
   implementing some traffic control solutions for IP networks like TBF (
   link
   <http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html#qs-tbf>)
   and HBT (link
   <http://tldp.org/HOWTO/Traffic-Control-HOWTO/classful-qdiscs.html#qc-htb>)
   as used in Linux kernel in ns-3 just like we have the other queuing
   disciplines under src/traffic-control/model/. I have talked about this
   project on the IRC with Mohil Tahiliani and I need to do more research on
   which specific algorithm I need to choose to implement based on the demands.
   2. *Linux-like Proportional Rate Reduction (PRR) for ns-3 TCP* (motivation
   - have studied TCP congestion control) *:-* I scanned through the
   reading material and as I understand there are lots of congestion
   avoidance/control algorithms in /src/internet/model/ and this project aims
   to implement the PRR (used as default in recent Linux kernels) using this
    link
   <https://www.nsnam.org/docs/models/html/tcp.html#writing-a-new-congestion-control-algorithm>;
   - something similar like Reno in tcp-congestion-ops.cc ? Also, while going
   through the algorithm in the RFC
   <https://tools.ietf.org/html/rfc6937#page-6> and Linux
   <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>
    implementation; I saw little discrepancies in terms of the way* sndcnt* is
   calculated if the *ssthresh* is exceeded in the recovery phase. The
   confusion for me is with regards to the addition and later division of
   * prior_cwnd* in the linux implementation as opposed to the way
   *RecoverFS* is calculated and used for division in RFC.
   3. *Freshen ns-3/Click integration *(motivation - have worked with Click
   in the past for NFV and have knowledge regarding IPv4 and IPv6)* : - * For
   starters, I was researching on points 1 and 3 about refactoring the ipv4
   integration done in the past and doing it for ipv6 as well. I was going
   through the src/click/model/ipv4-l3-click-protocol(.cc/.h) and
   src/internet/model/ipv4-l3-protocol(.cc/.h). What sort of code
   refactoring is expected - removing redundant parts to have "limited click
   pieces" kind of thing? Would be nice to gain more insight or some example
   on that so that I look into the code with the right perspective.

​Most of my above
doubts
 are more like clarifications to see if I have

 underst
​oo​
d
​ the above projects

​correctly in context of the proposal and expectations​
 before choosing the one on which I would be making the proposal. Any
help/pointers/suggestions on the above
​ stated questions​

​(or any other related stuff) ​
will be appreciated.
​​

I am looking forward to contributing to ns-3 in view of which I have built
the ns-3 project (having gone through the ns-3 tutorial) and run some
examples in my system. Currently I am trying to get familiar with the
project and it's code base and am working on the patch requirement/any
possible bug fixes.

Regards,
Surya.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Tom Henderson-2
Hi Surya,
I'll let other mentors respond to your other questions, but address this
one below.

> 3. *Freshen ns-3/Click integration *(motivation - have worked with
> Click in the past for NFV and have knowledge regarding IPv4 and
> IPv6)* : - * For starters, I was researching on points 1 and 3 about
> refactoring the ipv4 integration done in the past and doing it for
> ipv6 as well. I was going through the
> src/click/model/ipv4-l3-click-protocol(.cc/.h) and
> src/internet/model/ipv4-l3-protocol(.cc/.h). What sort of code
> refactoring is expected - removing redundant parts to have "limited
> click pieces" kind of thing? Would be nice to gain more insight or
> some example on that so that I look into the code with the right
> perspective.
>

We are looking for a more maintainable design for these classes.
ipv4-l3-click-protocol.cc is mostly a copy of a (much older) version of
ipv4-l3-protocol.cc, and there is no IPv6 equivalent.  Why can we not
simply reuse ipv4-l3-protocol.cc and ipv6-l3-protocol.cc and remove
ipv4-l3-click-protocol?

- Tom
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Surya Seetharaman
Hi Tom,

On Mon, Mar 13, 2017 at 6:58 AM, Tom Henderson <[hidden email]> wrote:
>
>
> We are looking for a more maintainable design for these classes.
> ipv4-l3-click-protocol.cc is mostly a copy of a (much older) version of
> ipv4-l3-protocol.cc, and there is no IPv6 equivalent.  Why can we not
> simply reuse ipv4-l3-protocol.cc and ipv6-l3-protocol.cc and remove
> ipv4-l3-click-protocol?
>
>
​Okay got it! Although I have decided to go ahead with implementing traffic
shaping algorithms project, if time permits, I will look into this too.
Thank you for clearing my doubt.


Regards,
Surya.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Viyom Mittal
Hi Surya,

Regarding the discrepancy you observed in calculation of *sndcnt* when
*ssthresh*
is exceeded in the recovery phase, if we simplify the linux code, the
sndcnt is calculated in following manner:

*sndcnt = ((ssthresh * prr_delivered+RecoverFS - 1)/RecoverFS) - prr_out*

The highlighted part above is used to provide the functionality of CEIL
which is same as in the rfc (shown below):

*sndcnt = CEIL(ssthresh * prr_delivered/RecoverFS) - prr_out*

So in my opinion, both the formulas are same but the way of representation
is different.

Please look into it and let me know if the above seems correct.

Thanks and Regards,
Viyom

On Sat, Mar 18, 2017 at 9:08 PM, Surya Seetharaman <
[hidden email]> wrote:

> Hi Tom,
>
> On Mon, Mar 13, 2017 at 6:58 AM, Tom Henderson <[hidden email]> wrote:
> >
> >
> > We are looking for a more maintainable design for these classes.
> > ipv4-l3-click-protocol.cc is mostly a copy of a (much older) version of
> > ipv4-l3-protocol.cc, and there is no IPv6 equivalent.  Why can we not
> > simply reuse ipv4-l3-protocol.cc and ipv6-l3-protocol.cc and remove
> > ipv4-l3-click-protocol?
> >
> >
> ​Okay got it! Although I have decided to go ahead with implementing traffic
> shaping algorithms project, if time permits, I will look into this too.
> Thank you for clearing my doubt.
>
>
> Regards,
> Surya.
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Natale Patriciello
In reply to this post by Surya Seetharaman
2017-03-12 18:20 GMT+01:00 Surya Seetharaman <[hidden email]>:

>
>    2. *Linux-like Proportional Rate Reduction (PRR) for ns-3 TCP*
> (motivation
>    - have studied TCP congestion control) *:-* I scanned through the
>    reading material and as I understand there are lots of congestion
>    avoidance/control algorithms in /src/internet/model/ and this project
> aims
>    to implement the PRR (used as default in recent Linux kernels) using
> this
>     link
>    <https://www.nsnam.org/docs/models/html/tcp.html#writing-a-
> new-congestion-control-algorithm>;
>    - something similar like Reno in tcp-congestion-ops.cc ? Also, while
> going
>    through the algorithm in the RFC
>    <https://tools.ietf.org/html/rfc6937#page-6> and Linux
>    <http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux
> .git/commit/?id=a262f0cdf1f2916ea918dc329492abb5323d9a6c>
>     implementation; I saw little discrepancies in terms of the way*
> sndcnt* is
>    calculated if the *ssthresh* is exceeded in the recovery phase. The
>    confusion for me is with regards to the addition and later division of
>    * prior_cwnd* in the linux implementation as opposed to the way
>    *RecoverFS* is calculated and used for division in RFC.
>

Hello,

I am sorry to have replied with so much delay, but as a partial excuse your
email is badly formatted, and in both mutt and gmail web interface is not
clearly viewable. This has decreased a lot my interest in reading it with
attention. Regarding this option, I would say that PRR *is not* a
congestion control algorithm, so it must not be implemented as a new
congestion control algorithm. My view is supported by the fact that in
linux you don't have the prr module, but instead this is merged in the
socket code, as it should be done in ns-3, with a proper boolean to
enable/disable it.
Even better, we have now modularized the congestion avoidance part of the
TCP, it would be awesome to modularize also the fast recovery part. In this
view, the PRR would be an add-on to any fast recovery algorithm (as well as
rate halving, etc..).

Nat
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Fwd: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Surya Seetharaman
Hi Natale,

On Mon, Mar 20, 2017 at 2:26 PM, Natale Patriciello <
[hidden email]> wrote:

> Hello,
>
> I am sorry to have replied with so much delay, but as a partial excuse your
> email is badly formatted, and in both mutt and gmail web interface is not
> clearly viewable. This has decreased a lot my interest in reading it with
> attention.
>

​I am extremely sorry for this, I was not aware that the formatting
appeared bad although I have no idea why it went bad (it looked fine in my
gmail web interface).


> Regarding this option, I would say that PRR *is not* a
> congestion control algorithm, so it must not be implemented as a new
> congestion control algorithm. My view is supported by the fact that in
> linux you don't have the prr module, but instead this is merged in the
> socket code, as it should be done in ns-3, with a proper boolean to
> enable/disable it.
> Even better, we have now modularized the congestion avoidance part of the
> TCP, it would be awesome to modularize also the fast recovery part. In this
> view, the PRR would be an add-on to any fast recovery algorithm (as well as
> rate halving, etc..).
>
> Nat
>

​Thank you for the insight! I will ​look at it again from the above angle.


Regards,
Surya.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Brief Self Intro + GSoC 2017 Project Ideas discussion.

Surya Seetharaman
In reply to this post by Viyom Mittal
Hi Viyom,


On Mon, Mar 20, 2017 at 1:53 PM, Viyom Mittal <[hidden email]> wrote:

> Hi Surya,
>
> Regarding the discrepancy you observed in calculation of *sndcnt* when *ssthresh*
> is exceeded in the recovery phase, if we simplify the linux code, the
> sndcnt is calculated in following manner:
>
> *sndcnt = ((ssthresh * prr_delivered+RecoverFS - 1)/RecoverFS) - prr_out*
>
> The highlighted part above is used to provide the functionality of CEIL
> which is same as in the rfc (shown below):
>
> *sndcnt = CEIL(ssthresh * prr_delivered/RecoverFS) - prr_out*
>
> So in my opinion, both the formulas are same but the way of representation
> is different.
>
> Please look into it and let me know if the above seems correct.
>
>
​Yes! Now I get it. Thanks for clearing out this point.​

Note: Regarding the formatting, I checked the archives and realized how bad
it looks. Again apologizing for the inconvenience caused to all of them who
had to read it like that. In my inbox it looked fine (attaching
screenshot).



Regards,
Surya.

mail.png (212K) Download Attachment
Loading...