Subject: DNS performance (was Re: [Speermint] TLs performance)

From: Klaus Darilion <[email-masked]>
Date: Fri, 04 Aug 2006 13:30:54 +0200

Henry Sinnreich wrote:
> Hi Klaus,
> 
> This is a good beginning, but you may want to include the 2-3 DNS
> lookups from the originating UAC and the additional 3-4 DNS lookups for
> ENUM, NAPTR, etc.
> 
> Can you add such a test?

Hi Henry!

Due to lack of time (and test applications) I did not made DNS tests 
yet, but some theory: DNS lookups do not need many resources. Of course, 
it will increase call setup time as the DNS lookup takes time, but that 
does not mean that the call throughput of the SIP proxy will decrease. 
If the SIP proxy uses asynchronous DNS or has enough threads, than the 
overall call throughput should be nearly constant, regardless of how 
long the DNS lookup takes.

Regarding the call setup delay: If a domain is looked up the first time, 
it will take some time (usually <100 ms). But further lookups for this 
domain will be cached in the DNS resolver server. Usually, there will be 
a DNS resolver somewhere "near" the SIP proxy and DNS lookups for cached 
domains will be <2ms.

There is also lots of discussion that RFC3263 is bad as NAPTR+SRV 
lookups will increase the call setup time as we need 3 DNS lookups 
instead of 1. But again, this additional 2 DNS lookups will usually only 
happen between the SIP proxy and the DNS resolver. If the NAPTRs, SRV 
and A/AAAA records are delegated to the same authoritative DNS server, 
this server will include all domains in the additional section of the 
DNS response.

E.g. the SIP proxy has to resolve pernau.at (NAPTR+SRV+A). It first will 
query for NAPTR records:

 >dig pernau.at NAPTR

;; QUESTION SECTION:
;pernau.at.                     IN      NAPTR

;; ANSWER SECTION:
pernau.at. 65 IN NAPTR    50 50 "s" "SIPS+D2T" "" _sips._tcp.pernau.at.
pernau.at. 65 IN NAPTR    90 50 "s" "SIP+D2T"  ""  _sip._tcp.pernau.at.
pernau.at. 65 IN NAPTR   100 50 "s" "SIP+D2U"  ""  _sip._udp.pernau.at.

;; ADDITIONAL SECTION:
pernau.at.              1312    IN      A       213.239.207.29
pb94.dyndns.org.        12114   IN      A       213.239.207.29
_sips._tcp.pernau.at.   65      IN      SRV     0 0 6061 pernau.at.
_sip._tcp.pernau.at.    65      IN      SRV     0 0 6060 pernau.at.
_sip._udp.pernau.at.    65      IN      SRV     0 0 6060 pernau.at.

;; Query time: 31 msec

This lookup did take 31 msec as all the caches were empty. If now the 
SIP proxy queries for the SRV and A records, this will be really fast as 
the resolver already has cached the values from the additional section.

 > dig _sips._tcp.pernau.at SRV

;; QUESTION SECTION:
;_sips._tcp.pernau.at.          IN      SRV

;; ANSWER SECTION:
_sips._tcp.pernau.at.   107     IN      SRV     0 0 6061 pernau.at.

;; Query time: 2 msec

The same is for the A lookup.

Conclusion: Even if the DNS caches are empty, the call setup delays due 
to NAPTR and SRV lookups are not that big as lots of people think - DNS 
is quite intelligent.

regards
Klaus

> 
> Thanks, Henry
> 
> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]] 
> Sent: Monday, July 24, 2006 1:00 PM
> To: [email-masked]
> Subject: [Speermint] TLs performance
> 
> Hi!
> 
> I made some tests with sipp+openser:
> 
> scenario:
> 
> UAC <-TLS-> openser <-TLS-> UAS (all of them got its own 2xP3 1,26GHz 
> machine, linked with 100MBit). Simple forwarding configuration (like a 
> loadbalancer), no DNS lookups or DB queries.
> 
> UDP: ~620 cps
> TLS: ~680 cps (single TLS connection)
> 
> cps=calls per second = INVITE-180-200-OK-ACK-BYE-200
> 
> I think TLS performs better as because of UDP retransmissions, which 
> "kills" the proxy if it becomes slow.
> 
> More data when I have it.
> 
> regards
> klaus
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 4 Aug 2006 11:10:34 -0700

Thanks Klaus for the thorough analysis!

I would only add to the observation:

>further lookups for this domain will be cached in the DNS resolver
server.

In this case there is the risk that the cached DNS data is stale, and we
may have an error condition. Some mobile phone registrations may change
with the same speed or even faster than the DNS refresh from domain to
domain. 

I could not get a handle on this. Any thoughts on this, or even more
important, have any measurements been made to capture the effect of DNS
caching on mobility between domains? Or is the mobile provider prevalent
thinking that users will never change domains? :-)

Thanks, Henry

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 4:31 AM
To: Henry Sinnreich
Cc: [email-masked]
Subject: DNS performance (was Re: [Speermint] TLs performance)

Hi Henry!

domains will be <2ms.

;; QUESTION SECTION:
;pernau.at.                     IN      NAPTR

;; ANSWER SECTION:

;; ADDITIONAL SECTION:

;; Query time: 31 msec

;; QUESTION SECTION:

;; ANSWER SECTION:

;; Query time: 2 msec

regards
Klaus

---

From: "Charles Shen" <[email-masked]>
Date: Fri, 4 Aug 2006 17:10:49 -0400

Hi, 

We have the following technical report on ENUM performance, using PDNS,
BIND, and ANS.

Charles Shen and Henning Schulzrinne, "Measurement and Evaluation of ENUM
Server Performance," Department of Computer Science, Columbia University,
Tech. Rep. CUCS-029-06, July 2006. 

The report is available at: http://www.cs.columbia.edu/research/publications

Hope it will be helpful. 

Thanks.

Charles 
-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 7:31 AM
To: Henry Sinnreich
Cc: [email-masked]
Subject: DNS performance (was Re: [Speermint] TLs performance)

Henry Sinnreich wrote:
> lookups from the originating UAC and the additional 3-4 DNS lookups 
> for ENUM, NAPTR, etc.
> 
> Can you add such a test?

Hi Henry!

Due to lack of time (and test applications) I did not made DNS tests yet,
but some theory: DNS lookups do not need many resources. Of course, it will
increase call setup time as the DNS lookup takes time, but that does not
mean that the call throughput of the SIP proxy will decrease. 
If the SIP proxy uses asynchronous DNS or has enough threads, than the
overall call throughput should be nearly constant, regardless of how long
the DNS lookup takes.

Regarding the call setup delay: If a domain is looked up the first time, it
will take some time (usually <100 ms). But further lookups for this domain
will be cached in the DNS resolver server. Usually, there will be a DNS
resolver somewhere "near" the SIP proxy and DNS lookups for cached domains
will be <2ms.

There is also lots of discussion that RFC3263 is bad as NAPTR+SRV lookups
will increase the call setup time as we need 3 DNS lookups instead of 1. But
again, this additional 2 DNS lookups will usually only happen between the
SIP proxy and the DNS resolver. If the NAPTRs, SRV and A/AAAA records are
delegated to the same authoritative DNS server, this server will include all
domains in the additional section of the DNS response.

;; QUESTION SECTION:
;pernau.at.                     IN      NAPTR

;; ANSWER SECTION:

;; ADDITIONAL SECTION:

;; Query time: 31 msec

This lookup did take 31 msec as all the caches were empty. If now the SIP
proxy queries for the SRV and A records, this will be really fast as the
resolver already has cached the values from the additional section.

;; QUESTION SECTION:

;; ANSWER SECTION:

;; Query time: 2 msec

Conclusion: Even if the DNS caches are empty, the call setup delays due to
NAPTR and SRV lookups are not that big as lots of people think - DNS is
quite intelligent.

regards
Klaus

---

From: Michael Haberler <[email-masked]>
Date: Sat, 05 Aug 2006 00:31:12 +0200

> In this case there is the risk that the cached DNS data is stale, and we
how often do you change telcos?
> may have an error condition. 
an expired cache entry is not an error condition, it  is a performance
impact of a  tradeoff decision between consistency and lookup time

> Some mobile phone registrations may change
the change driver on ENUM DNS entries is your porting frequency, not
your change-of-celltower/wlan access - that's a sip proxy issue
> thinking that users will never change domains? :-)
mobility between domains (if you're talking users changing providers for
a domain) is standard ISP fare - user wants to change - reduce
expiration timers - cutover - increase expiration timers - done

I'm a bit lost which problem you're actually referring to

-m

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 6 Aug 2006 08:24:21 -0700

Michael,

>I'm a bit lost which problem you're actually referring to

Thanks for getting this in focus!

I am trying to include the impact of numerous DNS lookups performed in
an assumed peering scenario, when evaluating performance: Looking up the
outbound proxy, ENUM, NAPTR, etc. in (1) the originating UA, (2) the
(possibly two) SBCs and (3) the various SIP proxy's in the path.

1. How many lookups are there in various peering scenarios?
2. What is the delay due to the lookups?
3. What is the impact of caching and what if there is no caching?

I don't expect a complete answer from you right now :-) but only wanted
to point out this is not as trivial as was implied in previous messages.

I guess some diagrams for various scenarios would provide better
insight, and sure, some experimental results between real domains, with
and without caching would be even more convincing.

Henry 

-----Original Message-----
From: Michael Haberler [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 3:31 PM
To: Henry Sinnreich
Cc: Klaus Darilion; [email-masked]
Subject: Re: DNS performance (was Re: [Speermint] TLs performance)

-m

---

From: Duane <[email-masked]>
Date: Sun, 06 Aug 2006 12:38:21 -0400

> 1. How many lookups are there in various peering scenarios?

Can't really speak for others, however for e164.org:

;; Received 362 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 37 ms
;; Received 241 bytes from 204.74.112.1#53(TLD1.ULTRADNS.NET) in 46 ms
;; Received 310 bytes from 204.209.140.172#53(ns3.e164.org) in 64 ms

We decided early not to allow NS records for other reasons, but it had
the side effect of less NS lookups to obtain route information, or a
failed query response.

-- 

Best regards,
  Duane

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sun, 6 Aug 2006 13:57:54 -0700

Thanks Duane, this is very encouraging. 
These are local server responses. It seems propagation delays and
occasional packet loss is not included.

Have you also considered the scenario where DNS queries are made buy the
SIP UA to find the outgoing SIP proxy, by a couple of SBCs in the path
and by the incoming SIP proxy?

What is the total number of DNS queries in some of such SPEERMINT
scenarios?

Thanks again, Henry

-----Original Message-----
From: Duane [mailto:[email-masked]] 
Sent: Sunday, August 06, 2006 9:38 AM
To: Henry Sinnreich
Cc: Michael Haberler; [email-masked]
Subject: RE: DNS performance (was Re: [Speermint] TLs performance)

-- 

Best regards,
  Duane

---

From: Duane <[email-masked]>
Date: Sun, 06 Aug 2006 18:32:28 -0400

> occasional packet loss is not included.

Our updates occur basically once a minute, we don't send update out via
AXFR, we use rsync instead, our most common TTL is set to 10 minutes

> and by the incoming SIP proxy?

As per my comment below, there is too many variables involved to state
in a definitive way, examples of this also include people in South
America and African regions having a lack of more direct access to the
root servers etc.

> What is the total number of DNS queries in some of such SPEERMINT

That could vary wildly depending if you have SRV records, if it involves
a country code and several sub zones and all that, or if it's hanging
off the main root servers such as the gTLDs, and that's all assuming you
don't have lookups occurring across multiple zones.

-- 

Best regards,
  Duane

---

From: "Patrick Melampy" <[email-masked]>
Date: Sun, 6 Aug 2006 22:02:32 -0400

Henry ---

I'm not sure there is an exact answer to your questions. It seems that like
all DNS related activities, the intelligent caching and TTL management are
keys for efficiency. If there is a peering situation, the only ENUM/DNS data
that will NOT be cached in normal circumstances is the original ENUM query
to get the NAPTR record that contains the full domain address (if found).
Every other NAPTR and DNS record will most likely be in a local cache. The
amount of cache hits would be increased as the number of adjacencies are
kept to a reasonable number. So its possible that only one DNS transaction
per call will be required.

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Sunday, August 06, 2006 4:58 PM
To: Duane
Cc: [email-masked]
Subject: RE: DNS performance (was Re: [Speermint] TLs performance)

Thanks again, Henry

-----Original Message-----
From: Duane [mailto:[email-masked]] 
Sent: Sunday, August 06, 2006 9:38 AM
To: Henry Sinnreich
Cc: Michael Haberler; [email-masked]
Subject: RE: DNS performance (was Re: [Speermint] TLs performance)

-- 

Best regards,
  Duane

---

From: Michael Haberler <[email-masked]>
Date: Mon, 07 Aug 2006 07:56:46 +0200

Patrick Melampy schrieb:
> ..kept to a reasonable number. So its possible that only one DNS transaction
and this one is likely to come from a local replica of at least your
country's worth of Infrastructure or private ENUM since I expect
operators to run local copies (be it hidden secodanries or a database
fed from the registry in some other way).

so in the normal case (warm caches) you'd see no DNS interaction beyond
your local caching server at all - pretty hard to beat by a DHT ;-)

-Michael

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 7 Aug 2006 12:19:08 -0400

Michael is entirely correct here... the may not be about the DNS at all but
the ancillary use of DNS technology locally cached to maintain a full copy
of a trusted routing registry. There are going to be various forms of
routing data that will need to be either aggregated ( local cache) or
queried (classic DNS)  depending on the circumstances.

The key discovery part of SPEERMINT is, perhaps, not about ENUM at all but
the role of a trusted registry(s) and how is that data accessed. 

The local cache maintains fairly static number translation data necessary to
complete a call either on the PSTN or IP end to end. This could include
things like LNP under certain conditions.

Basic mappings like TN to SIP AOR (point of interconnection) will not change
that often. Internal network routing will probably be placed in these
registries only validated.

> Sent: Monday, August 07, 2006 1:57 AM
> To: Patrick Melampy
> Cc: [email-masked]

---

From: Francois Menard <[email-masked]>
Date: Mon, 7 Aug 2006 17:50:59 -0500 (EST)

I guess it all depends on how realtime you want your LNP to be...

F.

--
Francois D. Menard
Project Manager/Charge de projet
Xit telecom inc.
1350 Royale # 800
Trois-Rivieres, QC, G9A 4J4
Tel: +1 819 374 2556 x 268
Cell: +1 819 692 1383
[email-masked]

---

From: Duane <[email-masked]>
Date: Mon, 07 Aug 2006 19:04:25 -0400

> I guess it all depends on how realtime you want your LNP to be...

I doubt carriers anywhere would give you a time to change over in
minutes, it would be closer to hours, so even having a 10 to 30 minutes
TTL wouldn't harm things from LNP point of view...

-- 

Best regards,
  Duane

http://www.cacert.org - Free Security Certificates
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Because e164.arpa is a tax on VoIP

"In the long run the pessimist may be proved right,
     but the optimist has a better time on the trip."

---

From: "Geoff Devine" <[email-masked]>
Date: Tue, 8 Aug 2006 05:50:10 -0400

That's not the way LNP works today.  

Class 5 offices have temporary triggers for the window where a number is being ported.  The definitive location of the subscriber is kept in the LNP database.  When that database is updated, all calls route to the ported destination.  You're violating the LNP requirements if you route the call to the wrong class 5 switch after the LNP database has changed.  

There are 300 million telephone numbers in the United States.  It's unlikely many of them will be in a cache.  This isn't like caching "google.com".

Geoff

-----Original Message-----
From: Duane [mailto:[email-masked]]
Sent: Mon 8/7/2006 7:04 PM
To: Francois Menard
Cc: [email-masked]
Subject: RE: DNS performance (was Re: [Speermint] TLs performance)

-- 

Best regards,
  Duane

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 08 Aug 2006 12:07:45 +0200

Geoff Devine wrote:
> Class 5 offices have temporary triggers for the window where a number
> is being ported.  The definitive location of the subscriber is kept
> in the LNP database.  When that database is updated, all calls route
> to the ported destination.  You're violating the LNP requirements if
> you route the call to the wrong class 5 switch after the LNP database
> has changed.

Thus, for each call the central LNP database is queried?

regards klaus

> 
> There are 300 million telephone numbers in the United States.  It's
> unlikely many of them will be in a cache.  This isn't like caching
> "google.com".
> 
> Geoff
> 
> -----Original Message----- From: Duane [mailto:[email-masked]] Sent:
> Mon 8/7/2006 7:04 PM To: Francois Menard Cc: [email-masked] 
> minutes, it would be closer to hours, so even having a 10 to 30
> minutes TTL wouldn't harm things from LNP point of view...
>

---

From: "Geoff Devine" <[email-masked]>
Date: Tue, 8 Aug 2006 06:39:41 -0400

In the US?  Yes.  A centralized LNP database is queried.

In many other countries, a huge file is distributed once per day.  Welcome to the stone age.

Geoff

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]]
Sent: Tue 8/8/2006 6:07 AM
To: Geoff Devine
Cc: Duane; Francois Menard; [email-masked]
Subject: Re: DNS performance (was Re: [Speermint] TLs performance)

regards klaus

---

From: Tim Dwight <[email-masked]>
Date: Tue, 08 Aug 2006 08:55:40 -0500

There is in country code 1 a central database-of-record, operated by the
NPAC, from which carriers download LNP data into systems within their own
networks; "systems" being in theory SCPs although in practice this service
is sometimes integrated into the STPs.  Point being that while the
database-of-record is centrally administered LNP resolution is performed in
a decentralized manner within individual carrier networks.

tim

> From: Geoff Devine [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 5:40 AM
> To: Klaus Darilion
> Cc: [email-masked]
> > is being ported.  The definitive location of the subscriber 
> is kept in 
> > the LNP database.  When that database is updated, all calls 
> route to 
> > the ported destination.  You're violating the LNP 
> requirements if you 
> > route the call to the wrong class 5 switch after the LNP 
> database has 
> > changed.
>

---

From: Tim Dwight <[email-masked]>
Date: Tue, 08 Aug 2006 09:01:03 -0500

> > is being ported.  The definitive location of the subscriber is kept in 
> > the LNP database.  When that database is updated, all calls route to 
> > the ported destination.  You're violating the LNP requirements if you 
> > route the call to the wrong class 5 switch after the LNP database has 
> > changed.

It is possible that the originating switch doesn't support LNP.  In such a
case the call may arrive at the "donor" switch (the switch from which the
number was ported).  This isn't the norm but isn't "illegal" either.  Donor
switches are required (in GR-2936) to support LNP, which ensures that in
such a case, calls are correctly routed (albeit with a bit of a dogleg in
the middle).

tim

---

From: Klaus Darilion <[email-masked]>
Date: Wed, 09 Aug 2006 13:46:29 +0200

What happens if there a number ported and the central LNP gets updated. 
How are the updates distributed to the carriers?  Immediately pushed to 
the carriers? Or do the carriers fetch updates on a regular basis?

regards
klaus

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Wed, 9 Aug 2006 08:04:19 -0400

There is an immediate push from the central database to the  carriers
service management systems. Carriers then must update their realtime
call processing databases. 

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Wednesday, August 09, 2006 7:46 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: DNS performance (was Re: [Speermint] TLs performance)

regards
klaus