Bug 187

Created attachment 136 [details]
implement a God ARP

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)?  

(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.

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.

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.

(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 ?

(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.
> 

I will not work on this.

I would like to work on this issue. Can someone tell me about its current status.

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.

(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.

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.

downgraded to enhancement, listed on wiki

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.

(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.