perfsonar development work

[Jason Zurawski <>]

Szymon Trocha wrote:
> Nina Jeliazkova pisze:
>
> > 2) PerfsonarUI receives an answer after 60250ms(!!!  - note this is much
> > better than December 2008 tests where same request took up to 5 minutes)
> > that these IP addresses are served by the following MAs: 150.254.185.146
> > > >    Indiana Gigapop SNMP
> > MA,http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/IUsnmpMA,http://schemas.perfsonar.net/2.0,,http://ggf.org/ns/nmwg/characteristic/utilization/2.0 
> >
> >     >>    Internet2 SNMP
> > MA,http://packrat.internet2.edu:2008/perfSONAR_PS/services/snmp/SC08,http://schemas.perfsonar.net/2.0,,http://ggf.org/ns/nmwg/characteristic/utilization/2.0 
> >
> >     >>    Internet2 Network SNMP
> > MA,http://rrdma.net.internet2.edu:8080/perfSONAR_PS/services/snmpMA,http://schemas.perfsonar.net/2.0,,http://ggf.org/ns/nmwg/characteristic/utilization/2.0 
>
> > 212.191.224.74
> >     >>    Internet2 SNMP
> > MA,http://packrat.internet2.edu:2008/perfSONAR_PS/services/snmp/SC08,http://schemas.perfsonar.net/2.0,,http://ggf.org/ns/nmwg/characteristic/utilization/2.0 
>
> None of the above MAs come from PIONIER so they can't provide data about 
> 150.254.185.146 and 212.191.224.74 :( Unless I don't know and you 
> collect our data ;)
> How could they be the results (which are completely wrong) of such query?


This is an excerpt from our December email thread, this is still 
relevant since there has been no alteration to the summarization algorithms.

While I still do not agree that this answer is 'wrong' as described in 
the design documents, it will be necessary to enhance the summarization 
algorithms from the current state to get a more exact result.  The 
section below describes a common case where the hLS will advertise 
ranges that are broad for a given data set.  This is usually made much 
worse when two address ranges are present and the subsequent IP address 
tree is very sparse.


> To answer Nina's specific question, first here is a query that can be sent to 
> an hLS to get the summary set:
>
> <?xml version='1.0' encoding='UTF-8'?>
> <nmwg:message type="LSQueryRequest"
>               id="msg1"
>               xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
>
> xmlns:xquery="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/lookup/xquery/1.0/";>
>
>   <nmwg:metadata id="meta1">
>
>     <xquery:subject id="sub1">
>
> declare namespace nmwg="http://ggf.org/ns/nmwg/base/2.0/";;
> declare namespace perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";;
> declare namespace 
> psservice="http://ggf.org/ns/nmwg/tools/org/perfsonar/service/1.0/";;
>
> /nmwg:store[@type='LSStore-summary']/nmwg:data
>
>     </xquery:subject>
>
> <nmwg:eventType>http://ogf.org/ns/nmwg/tools/org/perfsonar/service/lookup/discovery/xquery/2.0</nmwg:eventType>
>
>     <xquery:parameters id="param.1">
>       <nmwg:parameter name="lsOutput">native</nmwg:parameter>
>     </xquery:parameters>
>
>   </nmwg:metadata>
>
>   <nmwg:data metadataIdRef="meta1" id="d1"/>
>
> </nmwg:message>
>
> I sent this to 'http://ndb1.internet2.edu:9995/perfSONAR_PS/services/hLS' and 
> got back some of the IP address summaries.  Here are some examples of 'tight' 
> ranges:
>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/";>
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">216.249.136.128</nmtl3:address>
>             <nmtl3:netmask>25</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/";>
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">216.27.100.48</nmtl3:address>
>             <nmtl3:netmask>28</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>
> An also some 'not so tight' ranges:
>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/";>
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">10.0.0.0</nmtl3:address>
>             <nmtl3:netmask>8</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/";>
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">64.0.0.0</nmtl3:address>
>             <nmtl3:netmask>2</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>         <nmtl3:network 
> xmlns:nmtl3="http://ogf.org/schema/network/topology/l3/20070828/";>
>           <nmtl3:subnet>
>             <nmtl3:address type="ipv4">160.0.0.0</nmtl3:address>
>             <nmtl3:netmask>4</nmtl3:netmask>
>           </nmtl3:subnet>
>         </nmtl3:network>
>
>
> I am guessing that when Nina searched for 194.141.0.36, it may have been answered by 192.0.0.0/4 or similar (the machine on my desk that runs some services is 192.52.179.211, which is in the 192.52.179.0/24 block). 


I hope this helps, I would like to continue talking about what we can do 
to rectify this both at the client and API level as well as the service 
itself.  I do not think a complete solution is capable without 
everything being in harmony.

Thanks;

-jason