Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg

Amund Kvalbein <amundk@simula.no> Sun, 14 March 2010 20:33 UTC

Return-Path: <amundk@simula.no>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0B7A3A67E4 for <rrg@core3.amsl.com>; Sun, 14 Mar 2010 13:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.34
X-Spam-Level:
X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vIS-JEZFLbo for <rrg@core3.amsl.com>; Sun, 14 Mar 2010 13:33:47 -0700 (PDT)
Received: from mail-forward1.uio.no (mail-forward1.uio.no [129.240.10.70]) by core3.amsl.com (Postfix) with ESMTP id 2EEB83A6452 for <rrg@irtf.org>; Sun, 14 Mar 2010 13:33:40 -0700 (PDT)
Received: from exim by mail-out1.uio.no with local-bsmtp (Exim 4.69) (envelope-from <amundk@simula.no>) id 1NquVN-0003SX-K5 for rrg@irtf.org; Sun, 14 Mar 2010 21:33:45 +0100
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from <amundk@simula.no>) id 1NquVN-0003SU-Ih; Sun, 14 Mar 2010 21:33:45 +0100
Received: from cm-84.215.56.229.getinternet.no ([84.215.56.229] helo=[192.168.1.33]) by mail-mx4.uio.no with esmtpsa (TLSv1:CAMELLIA256-SHA:256) user amundk (Exim 4.69) (envelope-from <amundk@simula.no>) id 1NquVN-0007Jt-2F; Sun, 14 Mar 2010 21:33:45 +0100
Message-ID: <4B9D4828.6050607@simula.no>
Date: Sun, 14 Mar 2010 21:33:44 +0100
From: Amund Kvalbein <amundk@simula.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre
MIME-Version: 1.0
To: rrg@irtf.org
References: <201002180040.o1I0eAr0027055@cichlid.raleigh.ibm.com> <4B837DB1.8050009@firstpr.com.au> <201002242234.o1OMYlJV031162@cichlid.raleigh.ibm.com> <CD964388-4B88-4B58-82D5-88A7A11A5095@apnic.net> <4B8FB78D.7060903@firstpr.com.au> <4B9B068A.3030004@firstpr.com.au> <alpine.LFD.2.00.1003141730020.4735@stoner.jakma.org>
In-Reply-To: <alpine.LFD.2.00.1003141730020.4735@stoner.jakma.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 7 sum msgs/h 3 total rcpts 2547 max rcpts/h 23 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 0A7FA6D2D308155EA0AB7DA56E3622F9F6C404B3
X-UiO-SPAM-Test: remote_host: 84.215.56.229 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 2 total 70 max/h 6 blacklist 0 greylist 0 ratelimit 0
Cc: Constantine Dovrolis <dovrolis@cc.gatech.edu>
Subject: Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 Mar 2010 20:33:49 -0000

Folks,

In this context, I think you might be interested in a measurement study 
that will be presented at INFOCOM this coming week. The focus of the 
study is BGP scalability with respect to churn rates. We have analyzed 
six years of Routeviews BGP update traces from four monitors in 
different tier-1 networks.

Some of the main findings are that
- BGP churn varies widely on many time scales, and cannot be understood 
through "black-box" statistical analysis.
- The most severe churn experienced by these monitors are caused by 
mis-configurations and events that are local to the monitored AS.
- Surprisingly, as much as 40% of churn consists of duplicate 
announcements, which are unnecessary for correct protocol operation. 
This figure has been pretty constant over our measurement period.
- After filtering out duplicates, local effects and anomalies caused by 
a few specific events, we find that there is an increasing trend in 
"baseline" churn over the past six years, but that this growth is quite 
modest, and much slower than the growth in the DFZ RIB size.

The paper can be found at
http://simula.no/research/nd/publications/Simula.nd.435
Comments are always welcome.

Regards,
Amund

----

Amund Kvalbein, Post Doc
Simula Research Laboratory
http://simula.no/people/amundk


On 14. mars 2010 18:30, Paul Jakma wrote:
> On Sat, 13 Mar 2010, Robin Whittle wrote:
>
>> Geoff's research is:
>>
>>> In the "Re: [rrg] draft-narten-radir-problem-statement-05.txt" thread
>>> http://www.ietf.org/mail-archive/web/rrg/current/msg06152.html
>>>
>>> and in "BGP in 2009":
>>> http://www.potaroo.net/presentations/2010-02-01-bgp2009.pdf
>
> Those are the ones. I'd read that email too, but had forgotten of its
> existence in replying to this thread - thanks for highlighting it.
>
>> It's possible that the current architecture of the internet is
>> holding back growth that should otherwise be there.
>>
>> Yes. If we concentrate only on non-mobile networks, there are two
>> broad aspects of the routing scaling problem:
>>
>> 1 - The unreasonable, arguably unscalable, burden placed on the
>> DFZ routers individually, and on the DFZ control plane in
>> general, by the set of end-user networks which currently
>> get portability, multihoming and inbound TE by the only
>> means available: getting their own space and advertising it
>> as PI prefixes in the DFZ.
>
> Well, why is it "unreasonable" exactly? If the system works and is
> scalable, what's the problem?
>
> It's only unreasonable if there's a /good/ way to keep those prefixes
> out of the DFZ (i.e. good in the sense that it's at least as good as
> what we have today). If such a way exists, then that's great - we should
> definitely research ways to improve routing, of course.
>
> However, it does not seem justified to say the current routing
> architecture has a scaling problem. So it would not be justified, at
> thhis time (AFAICT), to excuse inefficiencies added by proposed changes
> on the basis that there's a pressing problem with the current architecture.
>
>> 2 - The much larger number of end-user networks which could use 2
>> or more ISPs and which want or need portability, multihoming or
>> inbound TE but don't have it because they are unable to get the
>> space and advertise it. (Perhaps a subset of these could do
>> it, but don't because they known how unscalable it is.)
>
>> The growth in BGP advertised PI prefixes is the simplest measure of
>> the first aspect - which is like the tip of the iceberg. The less
>> visible part is point 2, like the main body of the iceberg.
>
> Well, the internet is going to grow. That's hardly a surprise. What's
> the problem with the internet growing? Geoff's results seem to show that
> the growth is well within the scaling abilities of the 'net.
>
>> So even if Moore's Law keeps up in some acceptable manner with the
>> pace of growth in the number of PI prefixes in the DFZ, this doesn't
>> help with point 2 or with mobility.
>
> Sure, but:
>
> a) If the scope of the problem suddenly is "those very small
> networks which want portability/multi-homing but aren't big enough
> to get an AS and PI", then:
>
> - it's a much, much smaller problem in terms of affected parties
> than "internet routing doesn't scale"
>
> - it's not clear even that such networks exist to any
> meaningful extent (OK, I'm geeky enough that I'd love portability
> and multihoming for my home network), i.e. if this is the
> problem being solved then that changes the economic incentives
> of roll-out.
>
> b) If the problem is that fewer networks today can get PI, then we
> should be able to see a change in the mode of prefix growth in the
> historical data. However, TTBOMLK, we don't see this in the data.
>
> Basically, if there's a problem then where is the evidence of it, now
> that we seem to have initial evidence to suggest otherwise?
>
>> Sorry I haven't had time to revisit our discussions in early February.
>> I have a backlog of RRG messages to read and respond to - mainly
>> discussion following from my critiques of several architectures - and
>> I need to give priority to paying work.
>
> No worries, that was just speculation on my part anyway. :)
>
> regards,