1. PERFSONAR LS SCALABILITY ISSUES 1

2. Common LS queries The most common LS query will likely be: – “find me the service_accesspoint for X” Samples: –Find me the topology server for ESnet –Find me all pSB MAs for community “LHC” –Find me all pSB MAs with throughput data for host X Currently the last 2 queries all need to hit many hLSes. –This fundamentally can not scale! –Issues: Some hLS will be down, when to timeout?, very high latency to hLS on the other side of the planet, etc. 2

3. Sample Performance Results Find the topology server for ESnet –Queries only 1 hLS –Query time = 14 seconds Find all pSB MAs with throughput data for host albu-pt1.es.net –Queries a total of 12 hLS –Total Query time = 110 seconds Find all pSB MAs for community “LHC” –Queries a total of 26 hLS –Query time = 179 seconds 3

4. Solution? More data needs to be in (or “next to”) the gLS –See Martin’s proposed solution I think it should be easy to answer queries like this using the gLS only: –Find all pSB MAs for community “LHC” Other queries will be trickier, but should still be possible? –Find all pSB MAs with throughput data for host albu- pt1.es.net 4

5. Fixing things gLS architecture is fine and works for summarization and scalability The problem is that the gLS doesn’t have service access points, which necessitates contacting each hLS in the current implementation Putting SAPs in the gLS would reduce available summarization 5

6. Solution Direction The original model included other layers of LSes Automatic creation of hierarchy is difficult –that’s basically why it was dropped in the evolution of the dLS architecture We need a way to discover services without touching all hLSes –especially by each node 6

7. Solution Space Two solutions: Index Services –Gather relevant information (servicing a particular query) and keep it up to date –Ex: All pSB MPs, all North American MPs –This would talk to all hLSs and refresh fairly periodically (pull model) Domain Lookup Services –Large domains host DomLS 7