1. June 2007 ICC 2007 1 Measurement and Evaluation of ENUM Server Performance Charles Shen and Henning Schulzrinne Dept. of Computer Science, Columbia University, New York, NY

2. June 2007 ICC 2007 2 Motivation ENUM translates E.164 No. to URIs Built upon DNS infrastructure Query response time –PSTN post-dial delay in the order of seconds –PSTN switch processing time in the order of 200 to 350 ms Query throughput, database size, bulk record update –E.g. 100 million users, 0.1 erlang traffic over 100 million records 50,000 calls per second during busy hour Can existing DNS servers be used for ENUM? –no comprehensive study found at the time

3. June 2007 ICC 2007 3 ENUM in a Nutshell 1-212-939-1234 4.3.2.1.9.3.9.2.1.2.1.e164.arpa IN NAPTR 0 0 "u" "E2U+sip" \ "!ˆ.*$!sip:info@enum.example.com sip:info@enum.example.com Input an E.164 number Transform to FQDN Look for NAPTR record Apply regexs to get the result

4. June 2007 ICC 2007 4 Name Server Software Evaluated SoftwareOpen Source BackendOptimized for ENUM Popularity BINDYesFileNoMost PDNSYesMySQL, Oracle, DB2, file,... NoModest NavitasNoNominum specific backends, DB2,... Yes?

5. June 2007 ICC 2007 5 ENUMperf Test-bed

6. June 2007 ICC 2007 6 PDNS Throughput For existing records Peak throughput at around 5,500 q/s Peak throughput of querying non-existent records is only 630 q/s (almost 1/9!)

7. June 2007 ICC 2007 7 PDNS Response Time Value in the range of one millisecond Database lookup time contributes more than 60% Querying non-existent records dominated by Start Of Authority (SOA) searches For existing records

8. June 2007 ICC 2007 8 PDNS Database Scaling Good when records are in memory Poor otherwise Similar when querying non-existent records –but with much lower peak throughput For existing records

9. June 2007 ICC 2007 9 PDNS - Impact of Cache Implementation flaw in cache cleanup made performance worse than no cache when cache size is large –all results shown assume it is fixed Throughput increases 100% (packet cache) or 50% (query cache) Close to an order of magnitude increase for querying non-existent records with query cache For existing records

10. June 2007 ICC 2007 10 Comparing Throughput - Existing Records Navitas peak throughput more than three times that of PDNS BIND not included (only 1/50 of Navitas’) For existing records

11. June 2007 ICC 2007 11 Comparing Throughput -- Non-Existing Records Navitas about 10 times of PDNS and 6 times of BIND BIND outperforms PDNS –PDNS inefficient for non-existing records For non-existing records

12. June 2007 ICC 2007 12 Comparing Response Time For non-existent records Within one millisecond for all three Considered well below the call signaling budget Similar for existing records

13. June 2007 ICC 2007 13 Database Scaling - BIND Poor for existing records Good for non-existent records (better than PDNS) Degrade dramatically with out-of-memory records

14. June 2007 ICC 2007 14 Database Scaling - Navitas Best scaling property among the three Out of memory records not tested

15. June 2007 ICC 2007 15 Background Update Load Impact PDNS peak query throughput drops by 20% Navitas peak query throughput largely unaffected, but fluctuation is seen Response time variation at sub-milliseconds NavitasPDNS Query Throughput (q/s)5, 4003, 700 Update Rate (records/s)2, 5003, 000

16. June 2007 ICC 2007 16 Conclusions Query response time not a concern for post-dial delay BIND poor: scaling and background update PDNS and Navitas suitable for ENUM –Navitas significantly better due to optimization for ENUM PDNS can be improved to better serve ENUM –cache maintenance –ENUM records memory efficiency –fast-path handling of non-existing records