• HOME
  • About
  • Program Plan
  • Annual Report
  • Joining CAIDA
  • Staff
  • Jobs
  • Legal Agreements
  • How-To
  • Blog
  • Contact Us
• CATALOG
  • Datasets
  • Media
  • Papers
  • Recipes
  • Software
• RESEARCH
  • Topology
  • Security
  • Traffic Analysis
  • Economics and Policy
  • Visualization
• DATA
  • Overview
  • Data Sharing
  • Distribution Statistics
  • How-to
  • Data Usage FAQ
  • Papers using CAIDA Data
  • Acceptable Use Agreement
• TOOLS
  • Overview
• SERVICES
  • AS Rank
  • AS Rank API
  • BGPStream
  • BGPStream API
  • HI-CUBE (login required)
  • IODA
  • MANIC
  • MANIC API
  • Vela
  • Vela web API
  • Vela MIDAR API
  • Vela aliasq API
• PUBLICATIONS
  • Papers
  • Presentations
  • Blog
  • Visualizations
  • - Animations
  • - Posters
  • Networking Bibliography
• WORKSHOPS
  • Overview
  • AIMS
  • DUST
  • IMAPS
  • KISMET
  • WIE
  • WOMBIR
  • Collaborative
  • Archive
• PROJECTS
  • Ark
  • KISMET
  • MANIC
  • Macroscopic Topology
  • Spoofer
  • Network Telescope
  • IMPACT (PREDICT)
• FUNDING
  • PANDA
  • FANTAIL
  • PENMAN
  • SLAM
  • Censorship Outages
  • MapKIT
  • STARDUST
  • MADDVIPR
  • Program Plan

(CAIDA, January 2003)

RouteViews provides the research community with static snapshots of BGP tables that are far more complete and representative than any other collection; for the last five years virtually all useful interdomain routing research has relied on this data. RIPE also sponsors a routing data collection project (RIS) that has facilitated several useful research results. We discuss the differences between these two valuable data collection resources and how the research community might best allocate resources to improve and evolve them.

Main BGP measurement priorities
The main priorities for BGP data for researchers is:

1. data with high diversity
2. long history
3. constant, sufficiently large and representative set of peers
4. one-stop shopping (getting data from one source rather then merging disparate collections)

Diversity of feeds

A comparison of RouteViews with the RIPE rrc00 collector (other collectors are located at IXes and are not comparable because they use single-hop BGP sessions) shows that the diversity of feeds from each data collection project is of the same order of magnitude. Both have feeds from Europe, US and Australia, and Japan. RIPE has more coverage of European providers and RouteViews has moremore coverage of US providers.

BGP session resets

total bgp announcements vs.~session resets for RouteViews, August 2002

As of August 2002 RouteViews had 23 full feeds and RIPE rrc00 had 12. Route Views has several ASes participating with more than one peer, which has a potential advantage when studying policy differences and delays.

Route Views has on the average about 3 times higher incidence of session resets, (defined as 15-min intervals in which full-feed peer makes over 50K announcements+withdrawals.) Most of these (55%) come from a small set of 4 ISPs, two of which are located in Europe. Discounting these ISPs results in a comparable proportion of resets (5.6 per peer in a month) to that of RIPE (3.7 per peer in a month).

It would be a great improvement if RouteViews could adjust its TCP timers and other BGP parameters so that their session reset rate would become closer to that of RIPE.

Suggestions for improving static BGP table collection:

1. Make topological diversity the main criterion for peer selection.
2. try to cover every tier one provider (important: get back 701 peering)
3. Throw away peers with non-backbone tables (10 out of 59, 2 out of 25 update peers)
4. try to have a few tier-two views with lots of upstream and peering (right now we only have downstream connectivity, as every paper's analysis confirms (some even claim it to be property of the Internet: `almost no peering'.)
5. two ASes (267,2493) have only one upstream, which is useless if the upstream is already in RouteViews since even though they have full tables it does not bring any extra topological information. Specifically: AS 267 (puck.nether.net) has only Verio as upstream, and Verio is already present with 2 tables; AS 14608 (Alaska Fiberstar) has 701 and 3356 (Level 3) as its only connections (indegree and outdegree.). Get Tier2s with richer peering instead.
6. ASes with many tables (4513 GlobIX with 4 tables, 6395 Broadwing with 3) are better selected among Tier 1s. Increasing #Tier2s with many tables is not recommended.
7. Try to obtain an AS peer in China-HK, Singapore/Malaysia (currently Asia is represented by Japan with 2 ASes; evidence suggests China uses US connectivity). Increase diversity for Europe, other continents.
8. Maintain stability of the list (incremental growth) if at all possible. When peer IP address changes, it sheds doubt on whether the tables for this AS are backward comparable.

Suggestions for improving dynamic BGP data collection:

CAIDA verified the claim that RIPE data has fewer session resets (see above graph). Recommendations.

1. Reduce the rate of session resets. Check specifically for timers and for boxes: loop0.core1.sjc.layer42.net (47 resets in a month); route-view-ffm.ip.tiscali.net in Germany (37 resets); akabgp.srv.q.p80.net in Sweden (36 resets); psg1.psg.com (18 resets). (Note that psg0.psg.com has only 5 resets in August. Do we need two boxes at all?)
2. Remove the two peers (out of 25) with small tables (low 1000's of prefixes).
3. Introduce better timestamp resolution (this applies to RIPE as well).
4. Work more closely with RIPE on update collection. Duplication is unnecessary.
5. Sponsor or at least participate in more workshops for researchers in the field of BGP analysis.