Subject: [Crisp] Nesting queries redux

From: Tim Christensen <[email-masked]>
Date: Tue, 05 Oct 2004 07:54:10 -0400

All,

Here is another thought about rounding out the nested queries set.

Recall this diagram:

0                                                                   255
|----------------------------A----------------------------------------|

     32                    127 128                           239240  255
     |-----------B-----------| |-----------------C-------------||---J--|

     32       63     80   95   128                           239
     |----D----|     |--E--|   |-----------------F-------------|

     32 35 60 63      83 87                           216            255
     |-G-| |-H-|      |-I-|                           |--------K-------|

I previously made a case for the utility of a 'Lowest Level of Authority" 
query which would return, essentially, the first-line-responsible 
network(s) for a given query (or range).

My rationale was that it was useful for the server to provide a query that 
returns all "exposed-at-the-leaf-or-branch" networks for a range (looking 
from the bottom up).  If a client wanted to get that information and a 
query that returns something like my proposal isn't available at the 
server, then it creates a multi-round-trip problem that will create too 
much back-and-forth between client and server to answer the question, "what 
network(s) are the first-line authority for network range x -> 
y".  Specifically, the number of round trips varies, and increases, 
consistent with the depth of re-subdelegation in the tree (deeper trees 
create many, many round trips to answer the question.)

The following proposal is another approach to that same problem.

Today, we have a "less specific" query, which essentially returns 
(mathematically) "higher" networks in a network hierarchy.  This query 
however is constrained to return only networks which fully contain the 
query (range).  Using the example above, if a query were [start=34, 
end=61], the query would return networks D, B, and A (since they all fully 
enclose the range) but not G or H, because they do not fully enclose the 
range; indeed, G and H "overlap" the range, in that with G starting at 32, 
it has nodes outside the starting point of 34, etc.

If this "less specific" query were expressed with a modifier that would 
make non-fully-enclosed networks (or, networks that overlap the beginning 
or end of the query range) appear in the result set as well, then we'd have 
(at least) all the components of the original LLA query but without the 
(perhaps difficult?) server-side work.  For discussion, I will use the 
modifier "overlaps/no-overlaps", although feel free to use some other 
verbage (inclusive/exclusive, etc.)

In a "less specific overlaps" query for 34 -> 61, the server would return 
D, B, and A, because they fully enclose the query range, AND, G and H, 
because they partially-enclose (or, overlap) the range.

If the client gets A, B, D, G, and H all back in this type of query, it's 
now simple math to determine which networks are 'exposed' at the lowest 
level of the hierarchy.  Server does easier work, Client does a little more 
work, but only 1 network trip is required.   The client would be able to 
figure out that:

G is the first-line-authority for the network part from 34 to 35
D is the first-line-authority for the network part from 36 to 59
H is the first-line-authority for the network part from 60 to 61

and that A and B can be 'discarded' by the client as extraneous server 
results because they have no leaf-or-branch 'exposure' and aren't 
first-line-authoritative for any portion of the query range.  That's easily 
mathematically determined.

This technique would (also) be able to remove higher-in-hierarchy 
exact-matches by examining the parentage (where parentage exists, dependent 
on registry).

It seems to me that "less specific no-overlaps" still has good utility 
since the lowest-level network returned in such a query is the original 
"most specific" as proposed by Engin originally, which has usefulness as 
discussed previously on-list and in session.  Thus the suggestion for 
adding the overlaps/no-overlaps modifier rather than changing the default 
behavior of "less specific".

Feedback invited.  Thanks to Andy, Shane, Engin, and David for their 
thoughts on this idea.

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: David Blacka <[email-masked]>
Date: Wed, 13 Oct 2004 13:41:52 -0400

Tim Christensen wrote:
> I previously made a case for the utility of a 'Lowest Level of 
> Authority" query which would return, essentially, the 
> first-line-responsible network(s) for a given query (or range).

First, I would like to say that I continue to think that this (LLA) is a 
very useful query.

To help clarify my comments, I would like to try and put your original 
"LLA" query in more mathematical terms.  I see the LLA query as 
equivalent to:

    UNION( Q(one-level-less, qstart..qend) )

That is, the union of the results of "one-level-less" queries for each 
of the individual addresses contained between the query start address 
and the query end address, inclusive.

So, using your diagram, the LLA for qstart=32, qend=85, would be (G, D, 
H, B, E, and I).  The LLA for your example below, qstart=34, qend=61 
would be (G, D, H).

> The following proposal is another approach to that same problem.

To my mind, the only reason for attempting another approach is to 
attempt to get a query that is easier to implement that your original 
LLA query.  Is that correct?

Clearly, my mathematical description of LLA does not lend itself to an 
efficient solution, on either the client or server side.  However, that 
doesn't mean that there is no efficient way to implement this query. 
But no one has described one yet.

> end=61], the query would return networks D, B, and A (since they all 
> fully enclose the range) but not G or H, because they do not fully 
> enclose the range; indeed, G and H "overlap" the range, in that with G 
> starting at 32, it has nodes outside the starting point of 34, etc.
> 
> make non-fully-enclosed networks (or, networks that overlap the 
> beginning or end of the query range) appear in the result set as well, 
> then we'd have (at least) all the components of the original LLA query 
> but without the (perhaps difficult?) server-side work.  For discussion, 
> I will use the modifier "overlaps/no-overlaps", although feel free to 
> use some other verbage (inclusive/exclusive, etc.)

I would not want to make this a modifier unless it makes sense to use 
with all specificities.  If it only makes sense for the "less" 
specificity, then it should probably be a separate specificity scope 
(say, "less-with-overlaps", to be ugly and verbose).

> In a "less specific overlaps" query for 34 -> 61, the server would 
> return D, B, and A, because they fully enclose the query range, AND, G 
> and H, because they partially-enclose (or, overlap) the range.

This only gets you what you want because your query range is small 
enough that their aren't any more specific networks for that range.

Take my other example, above: 32 -> 85.  "less specific overlaps" would 
return B, I, and E.  It would not return G, H, or D because they are 
neither overlaps nor less specific (they are more specific).

I believe that you are correct in thinking that this is easier to 
implement on the server side than LLA.  You can (I believe) express this 
  "less specific overlaps" operation as returning all network blocks 
that contain either qstart, qend, or both, which at minimum, means that 
it is:  UNION(Q(less, qstart), Q(less, qend)).  Only two queries.

> If the client gets A, B, D, G, and H all back in this type of query, 
> it's now simple math to determine which networks are 'exposed' at the 
> lowest level of the hierarchy.  Server does easier work, Client does a 
> little more work, but only 1 network trip is required.   The client 
> would be able to figure out that:
> 
> first-line-authoritative for any portion of the query range.  That's 
> easily mathematically determined.
> 
> exact-matches by examining the parentage (where parentage exists, 
> dependent on registry).

As a matter of principle, if there is a discard process that you know 
that client will do, then doing it on the server makes more sense (well, 
as long as it isn't terribly expensive).

> adding the overlaps/no-overlaps modifier rather than changing the 
> default behavior of "less specific".

The only time that "less specific no-overlaps" (i.e., "less") will 
return the "most specific" network is when your query range just happens 
to have no actual more specific networks.  This is, of course, always 
true when qstart == qend.

-- 
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Engin Gunduz <[email-masked]>
Date: Thu, 14 Oct 2004 17:40:41 +0200

Hi,

> But no one has described one yet.

Let me try:

All networks that satisfy the following criteria:

  ( start(network) >= start(query)) AND ( end(network)) >= end(query) )
                                    OR
  ( start(query) >= start(network)) AND ( end(query)) >= end(network) )

If we take the union of the above networks, all less specifics, and
all more specifics, then we will need to delete the ones that are
not exposed looking from the bottom up. That last bit I'm not sure
how to do right now :)

[...]
> (say, "less-with-overlaps", to be ugly and verbose).

I agree that it must be yet another specificity scope, mainly because
it actually does not fit into the logic of "less specifics", but it is
something else by itself...

[...] 
> as long as it isn't terribly expensive).

I agree again. None of the other specificity scopes require the client
to do any filtering, so when possible, the server would do any processing.
-engin

---

From: David Blacka <[email-masked]>
Date: Thu, 14 Oct 2004 12:39:35 -0400

> not exposed looking from the bottom up. That last bit I'm not sure

I may be misunderstanding your notation, but wouldn't your query terms 
return networks that have nothing to do with your query?  That is (to 
take the first term) if a result network's start address is greater than 
your query start address, is also may be greater than your query end 
address, and thus be utterly irrelevant to your query.

Actually, I think that your query returns every network that isn't a 
more specific network than the query, which is a bit much.

I think what you are getting at is to first assemble all the networks 
that are less specific, more specific and overlap the query range. 
(Basically all networks that contains any of the IP address in the query 
range).  A possibly more compact way to get this is to union the results 
of: Q(all-less-specific, qstart), Q(all-less-specific, qend), 
Q(all-more-specific, qstart -> qend).

(Note that the all of the results returned by Q(all-less-specific, 
qstart -> qend) will be included in the above union, as those networks 
are the ones in the results of both of the two all-less-specific queries).

The hard part is seeing how to efficiently winnow down this list into 
the correct subset.  Tim's description is essentially a paper 
description, and I haven't figured out how to do this computationally. 
Ideally it should be at least O(n) + O(nlog(n)) (n being the number of 
results).

---

From: Tim Christensen <[email-masked]>
Date: Thu, 14 Oct 2004 13:45:01 -0400

At 10/13/2004 01:41 PM, David Blacka wrote:
>"LLA" query in more mathematical terms.  I see the LLA query as equivalent to:
>
>That is, the union of the results of "one-level-less" queries for each of 
>the individual addresses contained between the query start address and the 
>query end address, inclusive.

Yes, it can certainly be approached that way, and that's accurate.

>So, using your diagram, the LLA for qstart=32, qend=85, would be (G, D, H, 
>B, E, and I).  The LLA for your example below, qstart=34, qend=61 would be 
>(G, D, H).

Correct.

>To my mind, the only reason for attempting another approach is to attempt 
>to get a query that is easier to implement that your original LLA 
>query.  Is that correct?

Yes, which grew out of concerns of the LLA query's inability to be 
implemented without great network cost, for various values of 
great.  Similar to what you state below, I have server-side cost concerns 
about the "look up every /32 or /128" appraoch.

>efficient solution, on either the client or server side.
>   However, that doesn't mean that there is no efficient way to implement 
> this query. But no one has described one yet.
>
>>or end of the query range) appear in the result set as well, then we'd 
>>have (at least) all the components of the original LLA query but without 
>>the (perhaps difficult?) server-side work.  For discussion, I will use 
>>the modifier "overlaps/no-overlaps", although feel free to use some other 
>I would not want to make this a modifier unless it makes sense to use with 
>all specificities.  If it only makes sense for the "less" specificity, 
>then it should probably be a separate specificity scope (say, 
>"less-with-overlaps", to be ugly and verbose).

Ew, but, I definitely see that point... okay.

>This only gets you what you want because your query range is small enough 
>that their aren't any more specific networks for that range.
>

Yes, that would be correct, they are 'more specific' than the query, and 
would not be included. Mea culpa in my description, and you are correct to 
think that they SHOULD appear in the result set.  I intended them to be but 
described it incorrectly.

>implement on the server side than LLA.  You can (I believe) express 
>this  "less specific overlaps" operation as returning all network blocks 
>that contain either qstart, qend, or both

Yes, that's what we really want... minus any "fully subdelegated" 
less-specific blocks (such as, not returning "C" if you're returning "F", 
since C's space is fully subdelegated) as you perceive correctly below...

>which at minimum, means that it is:  UNION(Q(less, qstart), Q(less, 
>qend)).  Only two queries.
>
>>level of the hierarchy.  Server does easier work, Client does a little 
>>more work, but only 1 network trip is required.   The client would be 
>>able to figure out that:
>As a matter of principle, if there is a discard process that you know that 
>client will do, then doing it on the server makes more sense (well, as 
>long as it isn't terribly expensive).

Agreed, if we can derive no other usefulness for knowing "ALL" networks 
that touch a range (as opposed to the LLA concept).  I don't really see 
usefulness for an "ALL" at this point. Does anyone else?

>The only time that "less specific no-overlaps" (i.e., "less") will return 
>the "most specific" network is when your query range just happens to have 
>no actual more specific networks.  This is, of course, always true when 
>qstart == qend.

Correct.

Tim

---

From: Tim Christensen <[email-masked]>
Date: Thu, 14 Oct 2004 14:01:40 -0400

At 10/14/2004 12:39 PM, David Blacka wrote:
>>>doesn't mean that there is no efficient way to implement this query. But 
>>>no one has described one yet.
>>
>>Let me try:
>return networks that have nothing to do with your query?  That is (to take 
>the first term) if a result network's start address is greater than your 
>query start address, is also may be greater than your query end address, 
>and thus be utterly irrelevant to your query.
>Actually, I think that your query returns every network that isn't a more 
>specific network than the query, which is a bit much.

That's what I see, too.  Commonly we accomplish the first part (before the 
"OR") with

start(network) >= start(query) AND
start(network) <= end(query) AND
end(network) >= start(query) AND
end(network) <= end(query)

which yields all the networks that match or fully enclose the query string
and then we could union that with the concept of overlaps by asking for 
networks that contain the exact start point or end point in their network:

...
UNION
start(query) >= start(network) AND
start(query) <= end(network)
UNION
end(query) >= start(network) AND
end(query) <= end(network)

there are networks that will fall into more than one of these query 
subcomponents but those are easily eliminated.

>I think what you are getting at is to first assemble all the networks that 
>are less specific, more specific and overlap the query range. (Basically 
>all networks that contains any of the IP address in the query range).  A 
>possibly more compact way to get this is to union the results of: 
>Q(all-less-specific, qstart), Q(all-less-specific, qend), 

Same thing, correct?

Tim

---

From: David Blacka <[email-masked]>
Date: Thu, 14 Oct 2004 23:41:46 -0400

>> take the first term) if a result network's start address is greater 
>> than your query start address, is also may be greater than your query 
>> end address, and thus be utterly irrelevant to your query.
> That's what I see, too.  Commonly we accomplish the first part (before 
> the "OR") with
> 

>> (Basically all networks that contains any of the IP address in the 
>> query range).  A possibly more compact way to get this is to union the 
>> results of: Q(all-less-specific, qstart), Q(all-less-specific, qend), 

Correct.

We've both described the query that will give us all of the networks 
that contain any address that is part of the query range, which is a 
superset of the LLA query.  We can call this the "all" query.

I don't think that you will get a large number of duplicates with this 
query.  Networks that will appear more than once will be networks that 
are properly less specific than the query range (i.e., qstart and qend 
both are within the result network).  The number of these for any 
particular query will be limited by the depth of the allocation hierarchy.

There may be plenty of networks in this result that are not part of the 
LLA query result, however.

Now we just need to figure out how to get from the results of this query 
to the results of the LLA query.

My current guess is that it can be done relatively efficiently by 
ordering the "all" results by start address, ascending, and end address 
ascending.  This will give you the networks in sort of left-to-right 
order (looking at the diagram), sorting shorter, more specific networks 
before larger networks with the same start address.  As you iterate over 
this sorted list, you can assign address ranges to each network, 
occasionally backtracking to the previous network to shorten its range 
(or eliminate it) in favor of a smaller network.  I *think* that you 
will only have to backtrack one position, but I'm not positive.

-- 
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Tim Christensen <[email-masked]>
Date: Fri, 15 Oct 2004 07:28:58 -0400

At 10/14/2004 11:41 PM, David Blacka wrote:
><snip>
>We've both described the query that will give us all of the networks that 
>contain any address that is part of the query range, which is a superset 
>of the LLA query.  We can call this the "all" query.

Ok, dead horse beaten. :)

>My current guess is that it can be done relatively efficiently by ordering 
>the "all" results by start address, ascending, and end address 
>ascending.  This will give you the networks in sort of left-to-right order 
>(looking at the diagram), sorting shorter, more specific networks before 
>larger networks with the same start address.  As you iterate over this 
>sorted list, you can assign address ranges to each network, occasionally 
>backtracking to the previous network to shorten its range (or eliminate 
>it) in favor of a smaller network.  I *think* that you will only have to 
>backtrack one position, but I'm not positive.

One thing I see as a (minor) challenge in your current 'guess' is that, at 
a registry that permits full subdelegation (e.g. full-on duplicates of 
start/end), you need to look at the parentage to determine which network is 
the child (and therefore, the first-line authority for the number 
resource).  This can't really be accomplished mathematically, unless you 
start making assumptions about things like the block's create-date or 
something like that (which is not a good assumption).

I have come up with scenarios which require more work than just one 
backtrack, but I am working on some kind of approach (which admittedly is 
an implementation detail, but a proof-of-concept would be useful before we 
run headlong down this path).

My intuition is that this would be relatively efficient for any reasonable 
query.  The numbers are all at hand once you've done the 'all' query.

Tim

---

From: Engin Gunduz <[email-masked]>
Date: Fri, 15 Oct 2004 14:13:38 +0200

> more specific network than the query, which is a bit much.

Oops, right. The above criteria was supposed to find the overlapping
networks. It is missing two expressions.  It should have been
this:

( start(network) >= start(query)) AND ( end(network)) >= end(query)
   AND (end(query) >= start(network) )
                                  OR
( start(query) >= start(network)) AND ( end(query)) >= end(network) 
   AND (end(network) >= start(query) )

> Q(all-more-specific, qstart -> qend).

Yes, I think this would be more compact.  Although it contains more
than only the overlapping networks(*), I would get a union of these
with  Q(all-less-specific, qstart -> qend) and Q(all-more-specific, qstart -> qend)
so the end result would be the same.

> are the ones in the results of both of the two all-less-specific queries).

Right.
-engin

(*)What I mean with overlapping is this:

     Network   |---------------------------|
     Query        |---------------------------|

   But NOT
     Network   |---------------------------|
     Query        |------|

   NOR
     Network   |---------------------------|
     Query   |--------------------------------|

---

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Oct 2004 15:44:26 -0400

First, thanks to Shane, Engin, David, and Tim for working through this 
problem.  I think we are almost there with AREG.

However, this discussion of how to implement the LLA query has made me 
start thinking about the use case for it.  Specifically, the 
description of looking at every /32 or /128 made me think about how a 
network administrator gathers the input for such a query.  In San Diego 
we discussed the need for this query, but I don't think the use case 
for it was ever defined.

Having spent last weekend grepping through my logs to eliminate some 
blog-referer-spam,  I must admit that it never once occurred to me to 
issue a query on a range of IP addresses even though there were clearly 
ranges in the data.  I certainly issued the equivalent of the one-level 
less specific on a single /32.

Furthermore, I think there may actually be a downside to this query we 
have not understood.  Let's say that I pluck two IPs from my logs - one 
that is in network A and one that is in network C.  If I perform this 
query, I may end up with network B in the result set even though I 
never once saw anything from that network space in my logs.  In short, 
I think there is a danger of assuming that all LLA space is responsible 
just because a network falls in between two other networks from which 
I've defined my lower and upper bounds.

Do I have a fundamental misunderstanding of the need for this query?

-andy

---

From: Shane Kerr <[email-masked]>
Date: Mon, 18 Oct 2004 12:45:21 +0200

Andrew Newton wrote:
> query, I may end up with network B in the result set even though I never 
> once saw anything from that network space in my logs.  In short, I think 
> there is a danger of assuming that all LLA space is responsible just 
> because a network falls in between two other networks from which I've 
> defined my lower and upper bounds.
> 

I don't think so. To me it seems like the sort of thing that you would want 
to do, but since no user has asked for it (AFAIK) perhaps it isn't really 
needed. :)

I agree with the basic premise - trying to make it easier for people to find 
  information about abusers - but I think that ultimately for users to track 
down abusers:

1. they need to understand the relationship between the various ranges
2. they need to know the organisations that use the space they respresent

Maybe we should look at the use case that this LLA really represents: I have 
a list of IP addresses and I want to find out information about these addresses.

Maybe what we really want is to modify the <findNetworksByAddress> query to 
allow a multiple <ipv[46]Address> entries, and allow the server to return 
the smallest set <ipv[46]Network> results that match all of these.

Having this query would result in less network traffic than the LLA, as 
clients wouldn't have to get network details that they don't really care 
about (but can't know they don't care about until the query is done).

-- 
Shane Kerr
RIPE NCC

---

From: David Blacka <[email-masked]>
Date: Thu, 21 Oct 2004 12:14:32 -0400

Shane Kerr wrote:
>> issue a query on a range of IP addresses even though there were 
>> clearly ranges in the data.  I certainly issued the equivalent of the 
>> one-level less specific on a single /32.
>>
>> have not understood.  Let's say that I pluck two IPs from my logs - 
>> one that is in network A and one that is in network C.  If I perform 
>> this query, I may end up with network B in the result set even though 
>> I never once saw anything from that network space in my logs.  In 
>> short, I think there is a danger of assuming that all LLA space is 
>> responsible just because a network falls in between two other networks 
>> from which I've defined my lower and upper bounds.
>>
> I don't think so. To me it seems like the sort of thing that you would 
> want to do, but since no user has asked for it (AFAIK) perhaps it isn't 
> really needed. :)

I think that the point raised in SD was something like: No user has 
asked for it maybe because no user has realized that it was possible or 
that they *could* ask for it.

It very well may be that by making this query possible, we change the 
way your users work in a positive way.

A more pertinent question is probably: does this query work better for 
the given use case that what we have now with WHOIS?

> I agree with the basic premise - trying to make it easier for people to 
> find  information about abusers - but I think that ultimately for users 
> to track down abusers:
> 
> Maybe we should look at the use case that this LLA really represents: I 
> have a list of IP addresses and I want to find out information about 
> these addresses.

At some point, I realized that I was willing to believe any of the 
following:

1. The LLA query (or something close to it) is great, and although no 
user is asking for it now, it will be a big time saver for some use cases.

2. Now that we understand that getting "all" relevant networks is 
doable, that is good enough.

3. The LLA query is not really useful as folks are always dealing with 
individual IP addresses.

After thinking about this some more, I will have to admit that the 
"researching abuse" use case seems to start with individual IP addresses 
rather than IP address ranges.  That is, any range that a user would 
submit is a guess.

> Maybe what we really want is to modify the <findNetworksByAddress> query 
> to allow a multiple <ipv[46]Address> entries, and allow the server to 
> return the smallest set <ipv[46]Network> results that match all of these.

So, essentially, the server would union the results of all of the 
"one-level-less-specific" queries for each IP address, right?

> about (but can't know they don't care about until the query is done).

I guess I'm not sure how this query (which I think gets to the heart of 
this pariticular use-case) is really worth it?  You can, if you are 
worried about round-trip times, submit more than one query per request.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 21 Oct 2004 20:14:18 +0200

> Shane Kerr wrote:

<snippity/>

>> Maybe what we really want is to modify the <findNetworksByAddress> 
>> query to allow a multiple <ipv[46]Address> entries, and allow the 
>> server to return the smallest set <ipv[46]Network> results that match 
>> all of these.
> 
> 

Well, for whatever specificity was requested. But it only make sense in the 
context of one-level-less-specific or all-level-less-specific.

>> Having this query would result in less network traffic than the LLA, 
>> as clients wouldn't have to get network details that they don't really 
>> care about (but can't know they don't care about until the query is 
>> done).
> 
> 

If you have a list of IP addresses you want to know about:

192.0.2.13
192.0.2.40
192.0.2.200

And these yield a number of networks less than the number of queries:

192.0.2.0/26
192.0.2.128/25

Then you've saved having to execute 192.0.2.40 at all, or at least having to 
have an answer for it in the request.

(I am assuming that 1 query yields 1 answer - I may be wrong here.)

-- 
Shane Kerr
RIPE NCC

---

From: David Blacka <[email-masked]>
Date: Thu, 21 Oct 2004 14:31:24 -0400

Shane Kerr wrote:
> Well, for whatever specificity was requested. But it only make sense in 
> the context of one-level-less-specific or all-level-less-specific.

Hmm.

>>> as clients wouldn't have to get network details that they don't 
>>> really care about (but can't know they don't care about until the 
>>> query is done).
>>
>>
>>
>> I guess I'm not sure how this query (which I think gets to the heart 
>> of this pariticular use-case) is really worth it?  You can, if you are 
> Then you've saved having to execute 192.0.2.40 at all, or at least 
> having to have an answer for it in the request.

I can see how doing the union on the server may save the duplicates from 
going out on the network.  Of course, a human issuing one query at a 
time would also save this network traffic (although at the expense of 
more roundtrip overhead).  I guess I'm struggling with the balance 
between this query's utility and the additional code and spec complexity 
  it generates.

If, for instance, it was noticably more efficient (not counting network 
resources) to do the search for mulitple IPs rather than handling 
separate queries, then it makes more sense go this route.

However, you might not wish to go down this route if the goal is to try 
to get everyone to use UDP for this sort of case.

> (I am assuming that 1 query yields 1 answer - I may be wrong here.)

One query query returns one answer, but that answer could contain more 
than one result object, if you get my drift.

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Oct 2004 00:38:40 -0400

On Oct 21, 2004, at 12:14 PM, David Blacka wrote:

> You can, if you are worried about round-trip times, submit more than 
> one query per request.

And this was my first thought when I read Shane's message.  An IRIS 
client can submit multiple search sets in one pass.

However, if we believe this will be a common use case, then I think I 
favor allowing it in AREG specifically for the purposes of passing 
fewer angle brackets and perhaps the ability of more efficient code 
paths.

-andy

---

From: Shane Kerr <[email-masked]>
Date: Fri, 22 Oct 2004 17:35:30 +0200

> separate queries, then it makes more sense go this route.

I guess it's about where the efficiency lies. A client can cache the server 
replies. In my example, with these IPs:

192.0.2.13
192.0.2.40
192.0.2.200

And these networks:

192.0.2.0/26
192.0.2.128/25

A client that operated like this:

   foreach IP in IP_LIST:
     if not (IP in NETWORKS_FOUND):
       NETWORK = iris_lookup(IP)
       NETWORKS_FOUND.append(NETWORK)
     endif
   endfor

Then you'd see:

     iris_lookup(192.0.2.13)
     iris_lookup(192.0.2.128)

On the wire, just using basic queries.

A client that operated like this:

   NETWORKS_FOUND = iris_lookup(IP_LIST)

Would not really save much (any?) traffic in terms of bytes, but of course 
it's an extra TCP setup/teardown that gets eliminated.

In the UDP case for 3 IP's it doesn't make sense, but if we're talking a few 
hundred, all of a sudden things get a little bit interesting.

I'll do some voodoo on our log files to try to see if there is any 
efficiency gain in the type of queries we see.

> to get everyone to use UDP for this sort of case.

In the case where users want information about a single IP, UDP makes sense. 
If users want information about a set of IP addresses, then TCP makes sense. 
It's almost like providing the right tool for the job. ;)

-- 
Shane Kerr
RIPE NCC