Bug 187 - Need 'perfect' ARP
Need 'perfect' ARP
Status: NEW
Product: ns-3
Classification: Unclassified
Component: internet
pre-release
All All
: P3 enhancement
Assigned To: ns-bugs
:
Depends on:
Blocks: 400
  Show dependency treegraph
 
Reported: 2008-05-25 11:10 EDT by Mathieu Lacage
Modified: 2016-03-25 19:57 EDT (History)
5 users (show)

See Also:


Attachments
implement a God ARP (16.15 KB, patch)
2008-05-25 11:35 EDT, Mathieu Lacage
Details | Diff
patch for static population of ARP cache (3.27 KB, patch)
2016-03-25 06:52 EDT, Artem Krasilov
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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.