---

CAIDA/WIDE Collaboration

The objectives of informal joint CAIDA/WIDE workshops are:

• to discuss Internet measurement analysis activities going on in each organization;
• to explore opportunities for joint collaboration on projects;
• to continue data exchange.

The second workshop covered three main areas in its packed one-day agenda: DNS, IPv6, and BGP. The list of attendees included 11 participants from WIDE, 8 participants from CAIDA, as well as representatives from NLnet, RIPE, University of Waikato, and ISI.

Presentations

1. DNS measurements and modeling
   • Yuji Sekiya (WIDE), Passive and Active measurement of Root DNS
     This is an ongoing project to compare passive and active measurement of the root DNS servers. The active measurements used dnsprobe and the passive measurements used NetraMet. Yuji measured RTT, packet count, and packet loss rates to and from the root nameservers. He also ran NetraMet at two universities: Tokyo and Keio.
   • Nevil Brownlee (CAIDA), Automated gathering and web display of NeTraMet DNS data
     Automated collection of DNS-related flow data using the NetTraMet tool.
   • Henk Uijterwaal (RIPE), RIPE NCC DNS Monitoring - http://dnsmon.ripe.net
     dnsmon is an active DNS measurement project that RIPE began several months ago. Eventually RIPE will make the data available to the general public as well as server and TLD operators.
   • Kazunori Fujiwara (WIDE), Active DNS server measurement based on ICANN CNNP test
     The Minimum ICANN-required Performance Specifications for Registry Services outline Cross-Network Nameserver Performance Requirements and corresponding measurements ("CNNP tests") to verify the performance. (kc asked who at icann was using or checking any of this stuff. answer seems to be none.)
   • Duane Wessels (CAIDA), Laboratory simulations of the client side of DNS transactions
     This talk presented at NANOG in October 2003 describes the setup and results of laboratory simulations of various DNS caching software implementations and configurations.
   • Yasuhiro Orange Morishita (WIDE), Making an experimental environment for checking of DNS server behavior
     The specific objective of this experimental environment is to survey influences on the Internet caused by incorrect DNS server configurations, e.g., lame delegation, server down, security holes. Yasuhiro demonstrated exactly how to use this environment for comparing named implementations.
   • Marina Fomenkov (CAIDA), How do local DNS resolvers really work?
     Analysis of DNS traffic data collected at the University of Auckland included identification of high level users, rates of queries to roots and gTLDs vs. time, distribution of queries among root servers, response time distributions, and analysis of query patterns.
   
   General discussion: future directions of DNS research and collaboration
   • Bradley Huffaker (CAIDA)
     How will the deployment of anycast affect our ability to analyze the root system, and what types of questions can we usefully be asking in this new architecture?
     Bradley proposed a study of a client distribution for a single root with several anycast nodes that would proceed as follows:
     1. monitor current DNS client distribution;
     2. collect dnsstat info for 24 hours from all anycast nodes;
     3. examine and contrast client distribution for:
        - what is the client distribution among nodes, global and local?
        - how does the distribution compare to expectations from AS graph? (check using local (1 hop away) RIB and/or RouteViews)
        - Monitor effect of introducing a new anycast node: collect a RIB from a router in front of a new location (before/after), collect dnsstat for 24 hours from all nodes (before/after)
        
     Questions:
     How long does it take to stabilize after anycast node insertion?
     Can we predict the final stable client distributions?
     
   • kc claffy (CAIDA)
     asked at RSSAC for an anycast status web page detailing which roots are doing anycast in which cities from which dates, but got no commitment from RSSAC members. CAIDA has this information for just one root server, and anycast nodes on the servers are still not instrumented (blocked on funding).
   • Akira Kato (WIDE)
     talked about his passive analysis of traffic at a DNS server. He tapped an ISP DNS caching server and collected 340 million packets in 73 hours. 90.2% queries sent by users had valid TLDs and 200 TLDs out of 259 existing TLDs were observed. However, of the 240K queries sent to roots, only 0.23% were for valid TLDs, with .local comprising 23.3% of the total, and various numeric TLDs comprising 33.5%.
     



2. IPv6 measurements
   • Matthew Luckie (WAND), Active measurements of IPv6 topology: scamper project
     - scamper is a macroscopic IPv6 mapping tool similar to skitter in approach, but using a UDP traceroute-like methodology rather than ICMP, and without all the backend data management/storage software. scamper runs traces (in parallel as needed) to a list of IPv4 and IPv6 addresses at a specified packet/s rate and records the RTTs of intermediate hops and of the final destination.
     
     - The scamper IPv6 list sources include:
     1. 6bone.db;
     2. DNS walk of ip6.int (deprecated branch);
     3. Google for "IPv6";
     4. RIPE's IPv6 TTM monitors;
     5. addresses collected from preliminary scamper runs.
     
     - Features still unimplemented in scamper:
     1. MTU discovery, which might facilitate Layer-2 profiling, including identification of IPv{4|6} in IPv{4|6} tunnels;
     2. multi-homing: identify multiple IPv6 addresses (one tunneled and one native) that may cause strange or potentially untraceable behavior;
     3. identification of MPLS tunnels;
     4. interaction with BGP.
   
   
   • Kenjiro Cho (WIDE), Path Differences to Dual-stack Nodes
     - This study evaluates performance differences between IPv4 and IPv6. In particular, IPv6 performance in the field seems noticeably worse than IPv4, causing many sites to disable it. Kenjiro seeks to analyze which aspects of the IPv6 stack may interfere with better performance. He derived a list of target dual-stack nodes (hosts with both A and AAAA) and compared V6 ICMP RTT with V4 ICMP RTT. We need a better list of IPv6 addresses and more measurement points.
     
     - Preliminary results are:
     1. 50% destinations have similar RTTs (difference is within 20%) for IPv4 and IPv6 addresses;
     2. 24% of destinations are not reachable by either;
     3. IPv6 paths are considerably different from IPv4 paths;
     4. visualization helps to identify poorly-configured tunnels.
     
     
   
   
   • Bradley Huffaker (CAIDA), Comparative studies of IPv4 and IPv6 topology
     CAIDA's next generation macroscopic topology probing project will include a framework for analyzing IPv6 address space trends. One way to track the rate of address disappearance is to parse whois database allcations. Bradley also plans to track the rate at which IPv6 prefixes appear in RouteViews BGP tables and the size of allocations vs.~the size of announcements.



3. BGP measurements
   • Kengo Nagahashi (WIDE), BGP simulation environment on Starbed
     Starbed (website unfortunately only in Japanese) is WIDE's hardware-based BGP simulation environment that uses 512 PCs with redundant switch boxes to represent a large-scale BGP environment. Phase 1 includes a study of propagation time with 14 nodes. WIDE hopes to use Starbed to investigate BGP instabilities such as route flapping and prefix hijacking, and also perhaps to simulate atomised BGP.
   • Patrick Verkaik (CAIDA), Atoms - beyond CIDR aggregation
     - This research in BGP aggregation possibilities is focused on the potential of BGP atoms to reduce the load on the routing system. The fundamental idea behind atoms is taking advantage of the fact that many destination prefixes all share the same AS path (and even accompanying attributes) from the perspective of a given routing table. In November 2003, the 127K prefixes in RouteViews would coalesce into about 35K atoms.
     
     - The project is in its final stage now. Patrick is using GaTech's BGP extension to ns-2 [BGP++] to test his BGP atoms implementation under several realistic topologies. This extension allows us to simulate BGP and atom membership updates, determine the cost of these updates (in terms of number of messages, and convergence time), and compare these costs with those of non-atomized routing implementations.
     
     
   • kc claffy (CAIDA)
     CAIDA plans to continue its engagement in interdomain routing research in the coming year, although not specifically in the atoms project.

Future Plans

Plan another WIDE/CAIDA workshop in approximately 6 months. There was consensus that two days were really needed next time.

• Tentative dates are April 22-23, 2004.
• Try to organize it again at ISI (Bill Manning local host)
• prepare announcements and agenda for this workshop (Marina Fomenkov)