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