[rbridge] Max Network size / ARP servers

[Guillermo Ibáñez]

Guillermo Ibañez wrote:

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Guillermo Ibáñez wrote:
>...
>  
>
>>We must be aware of the high cost of ARP processing cost in hosts of a 
>>big network under the basic broadcast ARP approach.
>>    
>>
>
>It's a question of what BIG means. First, broadcast is the backup
>anyway. Second, caching at endhosts and snooping of broadcast responses
>reduces request load.
>  
>
I would consider big  a network (single broadcast domain) with  25.000 
-100.000 hosts. But this could fall short.
As stated in the paper,  the ARP cache policy in hosts (Windows) is as 
follows:  unused entries in last two minutes expire, the refreshed ones 
are allowed a maximum of 10 minutes, then a new  ARP request will be 
sent. Measurements, (see below at the end of mail) are based on the 
current caching at endhosts, so the caching effect  is already included. 
Regarding snooping, I agree that snooping of broadcast responses at 
proxy-ARPs will reduce the load.

>Finally, I may be in the minority here, but this has nothing to do with
>RBridge. I don't see the primary benefit of RBridge to support scaling
>to millions of nodes on an L2 net, nor do I see it as an opportunity to
>rewrite how ARP is implemented.
>
>Knwon optimizations can always be applied, but the core of its operation
>in this regard is to support conventional broadcast services. ARP is no
>different than any other broadcast service in that regard.
>  
>
Conventional broadcast services must be supported. The difference of ARP 
vs other broadcast services I see is the load imposed to hosts in big 
networks.

>...
>  
>
>>ARP servers can support replication. The point is whether it is an
>>objective to improve ARP security or the current situation is acceptable 
>>in the foreseable big networks.
>>    
>>
>
>RBridges are designed to replace bridges to improve routing, not to
>improve ARP security - the latter of which needs its own solution. Given
>that solution, it can certainly be supported in an RBridge, but I don't
>see why we would consider RBridges to uniqely enable or require it.
>
>  
>
I agree ARP is a side  issue for Rbridges, but as Rbridges usage may 
increase sharply the broadcast domain size, they are indirectly the 
cause of the load to hosts, so it can not be ignored.

>...
>  
>
>>>>What does the ARP server do with a request of the destination if it
>>>>hasn't seen any communication from that host before?
>>>>        
>>>>
>>Flooding, of course. Flooding is unavoidable at the end, but must be
>>kept to a minimum for big networks to not use up hosts processing power.
>>    
>>
>...
>  
>
>>>>What I would like to see is a comparison between  the cachés 
>>>>(distributed server/register) approach  with the current ARP proxy 
>>>>approach considering all aspects: engineering, security, broadcast 
>>>>volume, etc
>>>>        
>>>>
>>>See LANE and other NBMA literature. There are benefits, but there are
>>>also substantial robustness issues. Note that we can do NOTHING to avoid
>>>flooding when speaking to systems that haven't spoken yet - we won't
>>>find them at all unless the ARP emerges at the right egress link (L2
>>>network), and there's no way to know a-priori which one that will be.
>>>
>>>      
>>>
>>I will look at it, but I do not think it is the same thing.
>>    
>>
>
>Both use the same solution to avoiding broadcast - a centralized ARP server.
>
>  
>
Not exactly one centralized server. There would be  multiple servers 
with distributed load (by IP hashing), each of partial servers may  have 
replication. An specific protocol  would be required for it. We can 
think also on Distributed Hash Tables but performance does not seem 
adequate.

>>>Some measurements on ARP load are available at:   
>>>http://100x100network.org/papers/myers-hotnets2004.pdf
>>>      
>>>
>
>That paper has some interesting positions, but that would be open
>research. When a solution has been developed and tested, it might be
>considered for standardization. Since this is not an IRTF effort,
>though, that would be future work, IMO.
>
>Joe
>  
>
I did not refer to this paper to support the solution proposed, but only 
as reference for the ARP measurements provided. Results were:  89 ARPs 
per second on average in a 2.456 hosts network, with peak load of 1150 
ARPs/second. For a network with 25.000 hosts (ten times size), this 
means  900 ARPs /second on average and 11.500 ARPs packets (peak) to 
process on every  host.

Guillermo

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFCgQJUE5f5cImnZrsRAnCTAKD5v0cnZuarZZrNnn673nsNYQzZzACcCMz1
>nDUUaT/jinVhlwJxYltXwq4=
>=G783
>-----END PGP SIGNATURE-----
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>