BACKGROUND
==========
host 10.0.0.1 is trying to ping 10.0.0.2. The two hosts are connected to the mininet simulated on the same machine where controller is running. 10.0.0.1 and 10.0.0.2 don't yet know each other MAC address. The first ping between 10.0.0.1 and 10.0.0.2 takes more than 1 second consistently.

ROOT CAUSE SUMMARY
==================
When 10.0.0.1 issues the broadcast ARP request in order to find 10.0.0.2 MAC address, the controller takes the charge of doing the job simulating a traditional broadcast medium IP subnet. As soon as the controller finds out that 10.0.0.2 is associated to MAC address 00:00:00:00:00:02 instead to inform 10.0.0.1, it actually wait for the next broadcast from 10.0.0.1 to find 10.0.0.2 to tells about it. The second broadcast request from 10.0.0.1 to find 10.0.0.2 is 1 second after the first one and that cause the delay of 1+ seconds consistently seen and reported.
The issue is caused by a lack in the ARP handler of proactively informing 10.0.0.1 of 10.0.0.2 MAC address as soon it's learned.

SOLUTION SUMMARY
================
ARP handler should keep track of the broadcast ARP requests and as soon as the MAC for the target of the request is learned controller should send a reply to the request.

DETAILS OF THE SUMMARY AS SEEN FROM PACKET CAPTURE
==================================================
Referring to packet capture in:

https://docs.google.com/file/d/0B0XCPCWCfzpyWThiaTJxR3FHMUE/edit?usp=sharing

host 10.0.0.1 is trying to ping 10.0.0.2 so before pinging the ARP processing is in the picture and it goes like this:

sample #23) the ARP request from the host 10.0.0.1 searching for 10.0.0.2 got into the system.
sample #24) it came to the controller.
sample #76) host 10.0.0.2 replies with it's MAC

Now the controller should somehow send an answer to sample #23 but it doesn't because it actually waits for the next request from the host 10.0.0.1 seeking for 10.0.0.2. Now the story continues as:

sample #197) again host 10.0.0.1 search for 10.0.0.2
sample #201) this time the controller proxy arp for it
sample #202) at this point the ICMP requests gets out
sample #206) 10.0.0.2 search for 10.0.0.1 MAC by issuing an ARP
sample #209) controller proxies for it because it's known
sample #211) the ICMP reply goes on.

So the inefficiency is caused by the fact that the proxy ARP implemented by ARP handler doesn't proactively tell to 10.0.0.1 that it has found the host 10.0.0.2 but waits for the next request from 10.0.0.1 to find 10.0.0.2. The second request is 1 second a part from the first one.