Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
"Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov> Mon, 14 November 2011 11:14 UTC
Return-Path: <kotikalapudi.sriram@nist.gov>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F70E11E8234 for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 03:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.212
X-Spam-Level:
X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKAFIOYu6g3j for <sidr@ietfa.amsl.com>; Mon, 14 Nov 2011 03:14:12 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF0911E81E8 for <sidr@ietf.org>; Mon, 14 Nov 2011 03:14:11 -0800 (PST)
Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 14 Nov 2011 06:14:08 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 Nov 2011 06:13:32 -0500
From: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 14 Nov 2011 06:13:32 -0500
Thread-Topic: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
Thread-Index: AQHMor5xosDF2n1HPkGttBtzThsGyQ==
Message-ID: <D7A0423E5E193F40BE6E94126930C49308E9E35567@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] Burstiness of BGP updates (was: WGLC: draft-ietf-sidr-bgpsec-reqs)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 11:14:13 -0000
Brian, For BGP-4 updates, Geoff does provide the peak numbers observed for prefix updates in 1 second intervals. http://bgpupdates.potaroo.net/instability/bgpupd.html For example: Peak Prefix Update Rate per second: 1539 while Average Prefix Updates per second: 2.76 I suspect the peak perhaps corresponds to BGP session reset events when updates are generated back-to-back. If you exclude those reset events, then BGP-4 chattiness will have low variance. Since we do not have operational BGPSEC yet, we cannot obtain similar measurements at present. But I am confident that if you focus on BGPSEC chattiness only due to beaconing (i.e., exclude BGP session resets events), then the burstiness (of BGPSEC beacons alone) will be low. Bear in mind that the protocol recommends beacons should be jittered in time, and when thousands of prefixes are beaconed in a time-jittered fashion from distributed sites, they smooth out and the resulting beacon arrival process at a router would be a rather smooth Poisson process (variance/mean = 1). So the peak # beacons in n-second intervals (for n>=1) will likely be a small multiple of the mean # beacons in n-second intervals. Again mind you, on the otherhand, if BGPSEC session resets occur, then that would be quite different -- thousands of BGPSEC updates (not beacons) would be sent back-to-back in that case between the two affected peers. It may be noted that operators are anyway used to allowing 10s of seconds for table convergence after session resets. (You will see an analysis of convergence following BGPSEC session reset in the presentation that Randy and I have in the SIDR WG meeting tomorrow.) Sriram ________________________________________ >From: Brian Dickson [brian.peter.dickson@gmail.com] > >Hi, Sriram, > >Could you supply similar kinds of numbers, but with "peak" instead of >"average", esp. 50%ile, 75%ile, and 95%-ile levels for "peak"? > >Average is much less important than peak, in my experience. >Steady-state is easy. > >Also, in noisy/spiky data, mean != median typically. BGP is noisy/spiky. > >(Also when doing percentiles, it is essential to say, "95%ile on >5-minute samples, over a period of 1 week" for instance - and those >would be the customary sample windows to use.) > >Thanks, >Brian
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Sriram, Kotikalapudi
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Jakob Heitz
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Randy Bush
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Jakob Heitz
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … George, Wes
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Jakob Heitz
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … George, Wes
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Jakob Heitz
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Brian Dickson
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … George, Wes
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Russ White
- Re: [sidr] Burstiness of BGP updates (was: WGLC: … Jakob Heitz
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Jakob Heitz
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Jakob Heitz
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Shankar K A
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Christopher Morrow
- Re: [sidr] Burstiness of BGP updates Shankar K A
- Re: [sidr] Burstiness of BGP updates Jakob Heitz
- Re: [sidr] Burstiness of BGP updates Shankar K A
- Re: [sidr] Burstiness of BGP updates Brian Dickson
- Re: [sidr] Burstiness of BGP updates Christopher Morrow
- Re: [sidr] Burstiness of BGP updates Brian Dickson
- Re: [sidr] Burstiness of BGP updates Christopher Morrow
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Christopher Morrow
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Robert Raszuk
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Brian Dickson
- Re: [sidr] Burstiness of BGP updates Robert Raszuk
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Eric Osterweil
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Stephen Kent
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Russ White
- Re: [sidr] Burstiness of BGP updates Eric Osterweil
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Geoff Huston
- Re: [sidr] Burstiness of BGP updates Tony Tauber
- Re: [sidr] Burstiness of BGP updates Robert Raszuk
- Re: [sidr] Burstiness of BGP updates Tony Tauber
- Re: [sidr] Burstiness of BGP updates Robert Raszuk
- Re: [sidr] Burstiness of BGP updates Tony Tauber
- Re: [sidr] Burstiness of BGP updates Stephen Kent
- Re: [sidr] Burstiness of BGP updates Randy Bush
- Re: [sidr] Burstiness of BGP updates Jakob Heitz