perfsonar development work

[Jason Zurawski <>]

Szymon;


>> I agree with this. In fact, I think this is more the rule than the
>> exception (that data will be available from more than one location).
>>
>> BTW. This is also what Jason wrote in one of the first responses
>> yesterday. Did no one else see his response? It is in the archive and
>> I saw it, but I'm wondering if no one else did... He is a beta-tester
>> for a new Internet2 mail server, and I'm wondering if that server is
>> black-listed somehow.
>
> Jason,
>
> Could you forward your e-mail to the mailing list once again? I think 
 > it didn't go through.


Attached and also here:

https://mail.internet2.edu/wws/arc/perfsonar-dev/2008-08/msg00058.html

-jason


-------- Original Message --------
Subject: Re: [pS-dev] Multiple homeLS per IP address [Was :Re: [Fwd: Re: 
psUI demo] XQuery for subnet testing]
Date: Thu, 14 Aug 2008 07:24:23 -0400
From: Jason Zurawski 
<>
Reply-To: 

Organization: Internet2
To: Nina Jeliazkova 
<>
CC: 

 
<>
References: <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <> 
<> <>

Nina;

> We had recently a discussion with Szymon and Maciej on the best way to 
> resolve the case, where a query against gLS returns more than one 
> possible homeLS.
>
> The case was first reported for a traceroute Szymon used for a demo
>
> 1    49 ms    48 ms    48 ms  pionier-gw.rt1.poz.pl.geant2.net 
> [62.40.124.182]
>
> PerfsonarUI uses an XQuery (attached) to ask for subnets, matching given 
> IP address and subnet mask (e.g.  62.40.124.182/32 in this case). The
> The IP address (62.40.124.182) matches two home LS - the GN2 one with 
> subnet /23 and Pionier one with /32 . The excerpt of the response is below:
>
> http://loco4.man.poznan.pl:8180/xml-ls-gn2/services/LookupService
>                 <nmtl3:subnet>
>                     <nmtl3:address type="ipv4">62.40.124.0</nmtl3:address>
>                     <nmtl3:netmask>23</nmtl3:netmask>
>                 </nmtl3:subnet>
>                
> http://ls.perfsonar.pionier.net.pl:8080/xml-ls/services/LookupService
>                 <nmtl3:subnet>
>                     <nmtl3:address type="ipv4">62.40.124.182</nmtl3:address>
>                     <nmtl3:netmask>32</nmtl3:netmask>
>                 </nmtl3:subnet>
>
>
> I've updated perfsonarUI to always select most specific subnet, if there 
> are more than one, e.g. if there is /32 and /23 then /32 will allways be 
> selected.   For the use case PerfsonarUI is dealing with, namely looking
> for matches for a list of  IP addresses coming from a traceroute (subnet 
> mask /32 only) , it seems quite reasonable.


This is not a sound heuristic, in the case where multiple results are
returned each hLS should be contacted to ensure that the requested data
does not happen to be there.  This is true even if the summarization was
as tight as possible.  If some other hLS had data for 62.40.124.182/31
or 62.40.124.180/30, there is still a good chance the data could be
there (much better than /23 but still not as good as /32).


> However, Maciej had a different view ( don't restrict the answer to one 
> subnet, present everything to the user, see emails below ), so we 
> thought it will be best to move the discussion into the developers 
> mailing list.
>
> In summary,  my question is as follows (having in mind only the use case 
> when the user is asking for list of IPs coming from a traceroute and a 
> given eventtype, i.e. subnet mask 32 )
>
>     * Is there a chance, that information for a given IP and given
>       eventtype (e.g. utilization) is provided by more than one (MA)
>       service ?  
>     * If yes, how do we visualize that and assure the information is
>       consistent?
>     * If not, what is the reason of looking into multiple options?
>
> Discussion on other use cases are of course welcome :)
>
> Best regards,
> Nina


I can answer your questions with your use case in mind:

 * Dynamic circuits may create a problem when a circuit is allocated
between two domains.  Static monitoring within each domain may always be
watching the end interfaces, but dynamic monitoring started when the
circuit is created could be taken care of by some other service
(possibly in the domains, possibly elsewhere).  A traceroute may return
an IP address that has the potential to be watched by several services
(even if the source of the data is still the same).

 * Visualizing something like utilization is a little easier than an
active measurement in this case (there really can be only one true
source of data).  My opinion is that we shouldn't choose just one from
the possible set of data repos available, there needs to be some form of
correlation and mechanism to validate each of the sources.


For discussion, here are the answers outside of this use case:


 * I think the chances are always very good that data for a given
source and eventType can exist in many locations.  If there are two
sites that are each performing regular bandwidth (BWCTL) tests back and
forth each MA service would contain an endPointPair with IPs for both
domains.

Approaching the problem knowing that measurement data is pervasive is a
lot better than trying to isolate the cases where it may only make sense
to exist in a single location (e.g. an authoritative source for SNMP
data would be the owner of the network device; this doesn't mean that
they haven't handed out SNMP polling access to other folks who may
publish it as well).

 * As for trying to visualize this I do not have a a complete answer as
to what is the proper way to handle multiple sources.  For my bandwidth
example above it would be necessary to correlate the data, especially in
the case where both sites were testing to each other both as senders and
receivers (both sides would have data from both directions for the same
host pairs).

Other options would be to present the graphs as being independent
sources of information, perhaps showing a correlation as well to point
out where clock skew may be present or other forms of observed errors.

 * I think that the extra time spent to check at the hLS layer in
multiple locations when there is doubt is a small price to pay to ensure
data is found.  When we can guarantee that the summarizations are as
close as possible (still a work in progress) this will fade away.


Hope this helps;

-jason


> Maciej Glowiak написа:
> > Nina Jeliazkova wrote:
> > > Szymon,
> > >
> > > I've updated the SVN and the beta version available as Web start to 
> > > handle this issue. The logic is to always select most specific 
> > > subnet, if there are more than one, e.g. if there is /32 and /23 then 
> > > /32 will allways be selected. It doesn't seem likely that there will 
> > > be duplicates with netmask /32, for duplicates of other subnets it 
> > > depends how the summarization is done. Perhaps Maciej can better 
> > > explain if duplicate subnets are to be expected.
> >
> > Nina,
> >
> > Yes, duplicate subnets may occur. I think if there are several matched 
> > subnets all of them should be shown to the user. For instance we ask 
> > for 150.254.160.194
> >
> > There are two LS-es having:
> >
> > 1. http://ls1.perfsonar.net:8080/xmlls
> >       150.254.160.194/32
> >
> > 2. http://ls2.perfsonar.net:8080/xmlls
> >       150.254.160.0/24
> >
> > In fact responding user with only #1 is not so good, because LS1 has 
> > only that one address from the network (or doesn't do summarization) 
> > while the other one (LS2) may have full range of addresses from that 
> > network.
> >
> > I'd respond with both addresses. Then two separate queries should be 
> > done - one to LS1 and the second one to LS2.
> >
> > As far as I remember that way it was described in dLS algorithm. First 
> > we ask dLS (gLS here acts as dLS) for Lookup Services that MAY have 
> > the IP. Then we need to ask all LSes from result set. Of course it 
> > depends on strategy.
> >
> > Maciej 
>
> > Maciej,
> >
> > Maciej Glowiak написа:
> > > Nina,
> > >
> > > > My reasoning was based only for the case, where we are looking for a 
> > > > specific IP address - as in traceroute.  So, if we are looking for 
> > > > 150.254.160.194/32 , the first LS is an exact match and there is no 
> > > > need to respond with the second one.  If we are looking for e.g. 
> > > > 150.254.160.1 , then the first one is not a match at all , and the 
> > > > second (/24) is the only match; no need to respond with the first one.
> > > >
> > > > The logic I've proposed is exactly the one followed by IP 
> > > > forwarding, when the router needs to select the interface where to 
> > > > forward the packets for given destination IP.
> > > > Of course, in other scenarios, where we are interested not in a single
> > > > IP, the logic might be different. Do you have examples of such use 
> > > cases?
> > >
> > >
> > > Yes, but the router must select the path as quick as possible and 
> > > select the shortest path. The narrower mask the better choice it is.
> > >
> > > We have different approach. We want to give a user opportunity to see 
> > > all "sources" that may have information he wants.
> > >
> > > The /32 mask is of course special "use case". I don't have stong 
> > > opinion wheteher we should just response with one LS having /32 mask 
> > > or give all LSes that matche subnet masks. I'd prefer the second choice.
> >
> > Well, I will reformulate the question then, having in mind only the 
> > use case when the user is asking for list of IPs coming from a 
> > traceroute.
> >
> > Is there a chance, that (utilization) information for a given IP is 
> > provided by more than one (MA) service ? 
> > If yes, how do we visualize that and assure the information is 
> > consistent?
> > If not, what is the reason of looking into multiple options?
> >
> >
> > Regards,
> > Nina
> >
> > P.S. I've talked briefly with Michael Bischoff and he told me gLS API 
> > doesn't handle yet the case where more than one hLS are available for 
> > a given IP.
> >
> > > Maciej