Bug 187

Summary: Need 'perfect' ARP
Product: ns-3 Reporter: Mathieu Lacage <mathieu.lacage>
Component: internetAssignee: ns-bugs <ns-bugs>
Status: NEW ---    
Severity: enhancement CC: craigdo, frankhelbert82, phani, tomh, tommaso.pecorella
Priority: P3    
Version: pre-release   
Hardware: All   
OS: All   
See Also: https://www.nsnam.org/bugzilla/show_bug.cgi?id=2145
Bug Depends on:    
Bug Blocks: 400    
Attachments: implement a God ARP
patch for static population of ARP cache

Description Mathieu Lacage 2008-05-25 11:10:23 EDT
we need an implementation of ARP which avoids the generation of ARP request/reply packets and assumes a 'perfect' ARP table is always available and up-to-date.
Comment 1 Mathieu Lacage 2008-05-25 11:35:46 EDT
Created attachment 136 [details]
implement a God ARP
Comment 2 Tom Henderson 2008-05-25 23:14:54 EDT
I'm curious about the use cases for this.

Also, when it comes to naming, I prefer to stay away from the heavily overloaded term "God"; can I suggest Oracle ARP, or maybe drop the "protocol" altogether and call it OAR (Oracle Address Resolution) or PAR (Perfect/Precomputed/... Address Resolution)?  
Comment 3 Mathieu Lacage 2008-05-26 12:25:57 EDT
(In reply to comment #2)
> I'm curious about the use cases for this.

I think that the main use-case is modelizing a "stable" state where your devices in the network have filled their resolution tables with valid entries. I personally think that a better way to modelize this would be to ask users to force these entries to contain valid entries by sending a bulk of initial ip packets just for that but it seems that this opinion is not widely shared and I can see how convenient the "dirty" oracle-like behavior could be.

> Also, when it comes to naming, I prefer to stay away from the heavily
> overloaded term "God"; can I suggest Oracle ARP, or maybe drop the "protocol"
> altogether and call it OAR (Oracle Address Resolution) or PAR
> (Perfect/Precomputed/... Address Resolution)?  

OAR or PAR sounds great to me.
Comment 4 Sam Jansen 2008-05-27 14:55:40 EDT
Answering the "use case" question:

ARP is often an annoyance when doing testing at a higher level. It means the first packet gets a longer RTT due to the ARP lookup. Often, when doing real world testing, you just "prime" the ARP cache before doing your testing, to remove this variability.

Example 1: I just want a "ping" application to measure network RTT. I'm not interested in another layer having to do ARP here, I just want to know how long my ping packets take to get through the network. By disabling ARP, we can be sure that there is no variability introduced by the ARP mechanism.

I don't think ARP interactions are always of interest to a researcher. ns-2 didn't even have such interactions and for many studies, this was fine. It is often reasonable to study a "steady state" system.
Comment 5 Tom Henderson 2008-05-27 15:21:03 EDT
So, is adding/aggregating a new ARP implementation the right approach?  Should the existing ARP just have a "disable/enable" attribute flag with default=enable?  (where the "disabled" flag does an on-demand "cheating" by seeding the arp table before it is queried). 

this perfect ARP will also need to be documented that it fails in proxy-arp configurations.
Comment 6 Mathieu Lacage 2008-05-27 15:32:17 EDT
(In reply to comment #5)
> So, is adding/aggregating a new ARP implementation the right approach?  Should
> the existing ARP just have a "disable/enable" attribute flag with
> default=enable?  (where the "disabled" flag does an on-demand "cheating" by
> seeding the arp table before it is queried). 

The above is just an implementation detail. The new ARP implementation is at least nicer than adding another flag.

> this perfect ARP will also need to be documented that it fails in proxy-arp
> configurations.

What are these ?



Comment 7 Tom Henderson 2008-05-28 00:30:24 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > So, is adding/aggregating a new ARP implementation the right approach?  Should
> > the existing ARP just have a "disable/enable" attribute flag with
> > default=enable?  (where the "disabled" flag does an on-demand "cheating" by
> > seeding the arp table before it is queried). 
> 
> The above is just an implementation detail. The new ARP implementation is at
> least nicer than adding another flag.

I do not care strongly either way; was just a suggestion.

> 
> > this perfect ARP will also need to be documented that it fails in proxy-arp
> > configurations.
> 
> What are these ?

when one box is configured to reply for another address, for some reason.  Coincidentally, one use case is when loopback interface is aliased (lo:0, lo:1) so that a server can have multiple IP addresses on the same subnet.  Another one is mobile IP home agent will reply for a roaming node.

It is not a big deal right now but when someone tries to support a proxy arp case such as mobile IP, the perfect ARP would need to be modified to handle that.
> 

Comment 8 Mathieu Lacage 2010-02-20 13:14:52 EST
I will not work on this.
Comment 9 Phani Vadrevu 2010-04-09 06:40:57 EDT
I would like to work on this issue. Can someone tell me about its current status.
Comment 10 Frank Helbert 2012-02-07 08:42:31 EST
Perhaps this is a documentation issue. As the behavior is like the same as the real world. I think this one is almost the case of bug 1109, considering that ns-3 reproduces the real behavior.

We must consider adding a note on the documentation and closing the bug.
Comment 11 Tom Henderson 2012-02-07 13:55:40 EST
(In reply to comment #10)
> Perhaps this is a documentation issue. As the behavior is like the same as the
> real world. I think this one is almost the case of bug 1109, considering that
> ns-3 reproduces the real behavior.
> 
> We must consider adding a note on the documentation and closing the bug.


Hmm, here we have an implementation (for an earlier version of ns-3) and another few people requesting this feature.  

It seems to me that this might be a nice introductory student project to have someone try to complete, if we can agree on the user-level API.

So, I agree about closing this bug, but I suggest we try to create a small student project to finish this off.
Comment 12 Tommaso Pecorella 2012-02-08 15:36:33 EST
I'd leave it open and downgrade it to "enhancement". It could be an useful reading for the implementer.

About the student thing, I do agree. It's a nice class project.

T.
Comment 13 Tom Henderson 2012-02-11 21:25:36 EST
downgraded to enhancement, listed on wiki
Comment 14 Artem Krasilov 2016-03-25 06:52:06 EDT
Created attachment 2352 [details]
patch for static population of ARP cache

A pacth (applicable for ns-3.25) implementing a static function populating ARP cache at all nodes.
Comment 15 Tommaso Pecorella 2016-03-25 19:57:04 EDT
(In reply to Artem Krasilov from comment #14)
> Created attachment 2352 [details]
> patch for static population of ARP cache
> 
> A pacth (applicable for ns-3.25) implementing a static function populating
> ARP cache at all nodes.

The approach is interesting, but it's not "right".
Having a single ArpCache instance in all the nodes and interfaces will cause major issues in two cases:
1) if a node will, by chance, update what it thinks that it's a local cache, and
2) if there are global MAC hardware duplications (that are totally legal).

Point 2 is especially relevant when you have multiple technologies (e.g., part Ethernet, part 802.15.4, part LTE) in a simulation.
Moreover, as mentioned, the MAC address uniqueness is necessary only for on-link NetDevices. Off-link (routed) NetDevices can have duplicate MAC addresses.

Summarizing, any solution will have to populate the ARP cache only with link-locally reachable entries. 
This, as a side note, is a pity, because the proposed solution was elegant and simple. sadly, reality isn't that simple, and even if we assign MAC addresses in an ordered way, we can not assume that this is always true.