Re: Re send-n for query optimisation

Hi  Clive,
  As Paul pointed out, this is not a UK-only problem.
However, looking at your numbers, I think you are gilding the lilly.
I disagree with your figures for the generality of UK telephone users.

I would have used: 6 calls per day, 3-4 in busy two hour period.
Average call length << 1 hour.

As for call attempts / completed calls, I'd defer to Paul if he's
willing to give out some numbers for his network. 4 call attempts
per completed call seems high.

Even so, we *are* talking about a DNS based system. Our friends in
Verisign assure us all their servers are hammered much more than this.
The total number of queries is distributed over the whole of the UK.
You are thinking about a decentralized system, I hope? This is DNS.

It also does cacheing. The propensity of people to call any individual
number is low, but not always. Particularly with the "problem" ones in
the UK, the propensity is likely to be much higher. For example, if we
are to believe the Daily Mail and its ilk, there must be thousand upon
thousand of calls to 0800 1111. This is going to remain resident in the
cache of any provider's full-service resolver. If there are multiple
queries for incomplete numbers, then these may also be in the "negative"
cache.

So - assuming a distributed system with separate authoritative servers
and full-service resolvers, does it really matter whether or not one
saves 50% or 75% of queries?

There may well be some recommendations on negative cache times, but  
isn't
that a DNSOPS issue, not one specifically for ENUM.

all the best,
   Lawrence



On 11 Jul 2008, at 14:00, Clive D.W. Feather wrote:
> Jim Reid said:
>>>> But the ENUM lookups don't have to be blocking,
>>>> so why not let the client send an ENUM query after every digit (see
>>>> above for prefix/area code considerations)?
>>> Because it's still load on the servers that would be worth reducing.
>> I'm not sure that this load is ever likely to be significant in the
>> overall scheme of things Clive. Is there any hard data here or are we
>> all just working on guesses?
>
> I don't have hard data, but I can give you some estimates.
>
> Say 50 million telephone users in the UK. Assume each averages 1  
> hour of
> calling per day, average call length 3 minutes, and a 25% failure  
> rate of
> call attempts (no answer, engaged, etc.). Finally, assume a busy- 
> hour ratio
> of 6:1.
>
> That's then about 87,000 call attempts per *second*.
>
>> How much query traffic could send-n
>> actually save as a proportion of the overall number of DNS lookups
>> that will be going on inside the NICC's private ENUM-like tree?
>
> For calls in the UK, as Paul has shown, you need a lookup at 8  
> digits -
> without send-N, that's therefore 4 lookups per call. Send-N will  
> eliminate
> 2 of those. So that's 174,000 queries per second saved.
>
>> I
>> would assume that these lookups would be passing through some sort of
>> resolving server, so there should be a Big Win for cache hits after
>> the initial "priming" query.
>
> Let's assume caching gives you a 10:1 saving (I'm not at all clear  
> it will
> be anywhere near that good), so that reduces it to a saving of 17,000
> queries per second.
>
> -- 
> Clive D.W. Feather  | Work:  <[email protected]>   | Tel:    +44 20  
> 8495 6138
> Internet Expert     | Home:  <[email protected]>  | Fax:    +44 870  
> 051 9937
> Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973  
> 377646
> THUS plc            |                            |
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum