Network Coding (inter and intra-flow) on ns-3

[dgomez]

Hi all,

I open this thread in order to present the work we've been carrying out at our research group (University of Cantabria) during the last years. We are following a clear open-source policy, hence we are really happy to share it with everybody.

In a nutshell, the stuff you can find there is listed below (please note that the current version of the code works with ns-3.13):

1. A fully-fledged Network Coding module, which introduces two different solutions. For this purpose, we have placed a Network Coding layer that sits between the transport and network layer, aiming to boost the performance achieved by TCP over wireless networks.
2. An scenario creator based on a naive configuration file. You can find it in the "scenario-creator" module. It is worth highlighting that we have focused it on IEEE 802.11 lower layers.
3. IEEE 802.11b channel models (BEAR and HMP). They can be found in "bear-model" and "hidden-markov-model", respectively. Besides, these models have been almost ported to the newest version of the code (ns-3.19).

For any further details, please take a look at the repository (GitHub Network Coding repo) and its documentation therein. We sincerely look forward to finding people interested in our work, so don't hesitate and ask us if you have any question.

Best regards,

David 

-------------------------------------------
David Gómez Fernández
PhD student

Communications Engineering Department
Edificio Prof. José Ángel García
Plaza de la Ciencia S/N
39005 Santander- Spain

Tel.: +34 942 20 09 19 (ext. 504)
Fax: +34 942 20 14 88

www.tlmat.unican.es
-------------------------------------------

[Konstantinos]

Hi David,

First of all, I would like to thank you for sharing your core.
However, I would strongly suggest to port your models in the new ns-3 release which will make is much more useful for other people. There are a lot of bug fixed since that release and other updates.

Porting the new modules should be relatively easy, but I can understand that it would take some time to port code within existing modules. However, as I can see you have properly identified with the following statement, so it should not be very difficult.

////David/Ramón

NEW PROPRIETARY CODE

////End David/Ramón

Regards,
Konstantinos

[Olfa ben Rhayem]

HEllo;

I want to thank you for sharing your code

I want to ask you, what is the difference between Intra and Inter flow
 Network Coding?

looking forward to hearing from you.

[dgomez]

Hello Konstantinos,

Thank you for your quick reply.

Regarding your advice, we're currently porting all the code to ns-3.19, but it's not fully operational yet. You're right, the port is not being so tough, but I prefer to have a stable version before uploading it. And, of course, we should remove the labels.

BR,

David

[dgomez]

Hi Olfa,

We are very happy to share the code; I think it is much more useful than having it kept under lock...

If you follow the link I put in the previous message (this one), you can find in the README file a brief description of the two Network Coding solutions. As a hint, the inter flow Network Coding (NC) protocol is a free-interpretation of COPE [1], one of the most famous Network Coding-related contributions. On the other hand, the intra flow NC protocol, based on MORE [2], does not "mix" the information belonging to different flows (as the inter flow scheme does), but it just encodes all the packets belonging to a same transport level session. I must remark that the first option works together with TCP, aiming to boost its performance, but the second case relies on UDP as the transport level solution, because we are able (through this whole solution) to provide a reliable communication between two endpoints (that is to say, guarantee that the application layer will receive all the information sent the the source).

References:

 [1] Katti et al., XORs in the air. Practical Wireless Network Coding (IEEE Transactions on Networking 2008)

 [2] Chachulski et al., MORE. A Network Coding Approach to Opportunistic Routing (MIT Technical Report)

Hope to have helped you.

Regards,

David

[Olfa ben Rhayem]

thank you for your response

another question please, is it possible to simulate video transmission over ( NS-3+ your module for network coding ) ??

[Tommaso Pecorella]

Hi David,

very good news it's definitely something that will be useful. It will be even more useful once forward-ported to recent ns-3. Mind that the latest stable is 3.19, but we're working toward 3.20 (the main APIs between L3 and L4 shouldn't change much).

I'd encourage you to forward the mails also to ns-dev mailing list, and to have your code listed in the ns-3 wiki. Also, if you need any assistance on the forward-port, don't hesitate to write on the ns-dev mailing list.

Cheers,

T.

[Ivo Calado]

Hi David,

   it is a very interesting feature for ns-3. Just a doubt, are you considering to implement other NC-based approaches for TCP like CTCP or TCP/NC?

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--
Ivo Calado

Quidquid latine dictum sit, altum viditur

Putt's Law:
       Technology is dominated by two types of people:
               Those who understand what they do not manage.
               Those who manage what they do not understand.

[dgomez]

Hi all,

I'll answer your comments in order:

1. Olfa: I think there's no problem with that; the NC module is completely independent from the application layer, hence you can choose whatever you want. Of course, the behavior would be different (for instance, the inter-flow yields a better performance with more synchronized flows). Namely, we have chosen the duple OnOffApplication-PacketSink as the application level instances. If I have understood correctly, you want to inject the traffic belonging to a real application (i.e. video transmission) to the simulator, Regarding this topic, I'm sorry but I can't help you at all. I'd take a look to the DCE module , but I have no idea about how to implement it. Besides, you should wait till I update the code to the last version of the simulator (I'll have it by the end of this month, if everything goes well).
2. Tommaso: I'm dealing with the port (3.19) and, as you mention, it's quite easy to adapt the code (I think the number of modifications that might harm us is not too high). As far as I have a decent version to share, I'll post it here (and, following your advice, I'll send a mail to the ns-dev mailing list and generate a new entry in the wiki).
3. Ivo: I'm afraid we won't implement (by the moment) any additional solution. We have these ones, and we have to squeeze them before implementing others. 

Last, but not least, I must thank you again for your interest. We're really glad to have this quick feedback.

BR,

David

[Ivo Calado]

Hi David, I'm performing a study about the NC-based TCP approaches. So, I have a special interest on this topic. Due to that, I'm considering to contribute implementing those "flavors" of TCP as an extension of your code. If possible, could you give some tips about the steps required to add a new NC-based flavor of TCP on your module?


best regards,

   Ivo

[]'s

--

You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[dgomez]

Hi Ivo,

If I have understood correctly, you actually want to assess the behavior of the NC module under different TCP "flavors" (among which you can use the following ones supported by the simulator: RFC 793, Reno, New Reno, Tahoe and Westwood). It's a nice idea (I haven't had the time to carry out such campaign). If so, you just need to change one single line of the code (if you want to use the example provided: "scratch/test-scenario.cc", which makes use of our "scenario-creator" module). Namely, you must explicitly set the type of TCP socket you want at the application definition (through the OnOffApplicationHelper and PacketSinkHelper declarations). You can add this to the meber function Configure::Scneario::SetUpperLayer.

By the way, I must highlight now two points:

- The version of the code is not 100% stable. We've ported the code from a much more uglier version, but we leaked some bugs that we're not been able yet to eliminate. Until we do this, the Inter Flow Network Coding protocol is not very reliable.

- We have only tested the operation of this module over canonical scenarios (line of three nodes, butterfly topology, etc.). The use upon different solution has not been assessed yet.

If you need something else, please don't hesitate and ask whatever you want.

Cheers,

David

[Ivo Calado]

Hi David

On Fri, Apr 11, 2014 at 2:45 PM, dgomez <gener...@gmail.com> wrote:

Hi Ivo,

If I have understood correctly, you actually want to assess the behavior of the NC module under different TCP "flavors" (among which you can use the following ones supported by the simulator: RFC 793, Reno, New Reno, Tahoe and Westwood). It's a nice idea (I haven't had the time to carry out such campaign). If so, you just need to change one single line of the code (if you want to use the example provided: "scratch/test-scenario.cc", which makes use of our "scenario-creator" module). Namely, you must explicitly set the type of TCP socket you want at the application definition (through the OnOffApplicationHelper and PacketSinkHelper declarations). You can add this to the meber function Configure::Scneario::SetUpperLayer.

Although it is a interesting idea it wasn't what I wanted to meant. I'm trying to compare the approaches that improve the TCP protocol through Network Coding. So, I want to know how difficult is to extending your module to implement approaches such as CTCP or TCP/NC.

 

By the way, I must highlight now two points:

- The version of the code is not 100% stable. We've ported the code from a much more uglier version, but we leaked some bugs that we're not been able yet to eliminate. Until we do this, the Inter Flow Network Coding protocol is not very reliable.

- We have only tested the operation of this module over canonical scenarios (line of three nodes, butterfly topology, etc.). The use upon different solution has not been assessed yet.

Ok, I'll take this in consideration
 

If you need something else, please don't hesitate and ask whatever you want.

Thank you very much for your attention.

Cheers,

David

Ivo

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[dgomez]

Ok Ivo, 

Thank you for the clarification. If you want to implement another NC implementation, you can use our framework, of course. For that purpose, you can create a new model within the network-coding module, asserting that your new protocol inherits from the base class NetworkCodingL4Protocol. Anyway, make sure your solutions are between IP and TCP levels (IIRC, CTP and TCP/IP fullfill this condition.

With the module (raw) that we provide you have the following stuff:

- A new layer between IP and transport layers. That means that a packet will follow the flow: Application -> TCP -> NC -> IP ... (at transmitter entities). On the other hand, if the IP header has the NC protocol put in the upper protocol field, the flow (in reception) would be: ... -> IP -> NC -> TCP-> Application

- If you want to handle the packets at relay nodes, you may need to add your own code to the function Ipv4L3Protocol::IpForward, and redirect the packet to the function you want.

- We provide as well promiscuous reception mechanisms, where a packet might get the NC layer of an arbitrary even if the MAC destination address does not correspond with the node's address. Upon a legacy operation, the MAC-level mechanisms would simply discard these packets.

There are of course additional issues that I could append, but I should need more details about your goals before (for instance, are you starting those protocols from scratch?).

Hope to be helpful.

Regards,

David

[mrs.ja...@gmail.com]

Hi  dear friend, I would like to thank you for sharing your core. I have installed ns3.13. Full install and run another programs.but How can I build your file? What changes should I get ns? do i have replace your ns3.13 folder with my ns3.13 folder?I do int but not build. Is this your code relate with kodo library?or no?I read all the files and instructions you have. I send email for you and your friend but unfortunately even  not answer  I desperately need your help,Thanks for you  if help me.

best regard

[Mrs Jsnnesary]

Re greeting 

I want to write a new algorithm that determines the amount of redandancy packet in times of congestion, to improve tcp throughput. I want implement my algoritm code on your protocol (inter-flow-network coding).  I add my algoritm code on Which file ? on main protocol cod?(inter-flow -network-coding?) I really do not know Ns3 very good and I am a  beginner in ns3.please help me.very thanks.Best regard.

On Monday, April 7, 2014 8:27:46 PM UTC+4:30, dgomez wrote: