[Ietf-not43] traditional searches

[Eric A. Hall]

on 8/22/2003 1:53 PM Andrew Newton wrote:

> No publicly-facing server is going to trust that the client obeys a 
> capabilities list and it will always do an authorization check on a 
> query.

The benefits of a capabilities model go to both the client and the server
(the client benefits are arguably higher in some scenarios). I'm not
calling this a guarantee of use, just pointing out the motivation. On the
other hand, there is absolutely zero motivation for a client to use a
probe. This is illustrated below.

> A 'dry run' switch simply stops the trip to the data store, 
> which is probably more expensive than the authorization check.

Here are some examples.

First, a basic rejection of a submitted query due to permission failures
of the query context does not require a trip to the mail store:

  client: bind
  server: okay
  client: query
  server: permission denied
  client: bye

This is identical to a probe that gets rejected. There are zero savings in
this scenario, and the client would have gotten the same mileage from just
issuing the original query:

  client: bind
  server: okay
  client: probe
  server: rejected due to permissions
  client: bye

Worse are successes. Here's a non-probe success:

  client: bind
  server: okay
  client: query
  server: answer data...
  client: bye

Here's a probe success. Again, the client would have been better off by
just issuing the damn query:

  client: bind
  server: okay
  client: probe
  server: okay
  client: query
  server: answer data...
  client: bye

Variations on those themes such as recovery probes/queries follow the same
basic math.

Here's what failure with the capabilities model looks like:

  client: bind
  server: okay; capabilities
  client: bye

Here's what success with the capabilities model looks like:

  client: bind
  server: okay; capabilities
  client: query               <--known valid
  server: answer data...
  client: bye

So, probes are always of equal or higher cost than just issuing the
original query, while the capabilities model is always faster and cheaper.
This is demonstrably better for the servers, but is also better for
clients since latency is cumulative, and the cumulative penalty goes
against the client. EG, if the client gets directed to a resource entry on
a server that is three or four levels deep (domain.isp.co.uk, or a
netblock that is reallocated multiple times), then the extra round trips
really start adding up, especially if they are coming via a high-latency
link (eg, a cellular PDA).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/