Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 10 November 2011 19:47 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 C0A4921F8A62 for <sidr@ietfa.amsl.com>; Thu, 10 Nov 2011 11:47:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.435
X-Spam-Level:
X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2tNVf7LHeS1j for <sidr@ietfa.amsl.com>; Thu, 10 Nov 2011 11:47:03 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 99BC021F84FB for <sidr@ietf.org>; Thu, 10 Nov 2011 11:47:03 -0800 (PST)
Received: by faas12 with SMTP id s12so3821772faa.31 for <sidr@ietf.org>; Thu, 10 Nov 2011 11:47:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=iAHwEQy6OIF5n6H5gkwI/TPy74R3w8CkCImyymntSZ0=; b=JBGkCTkMzPAjyC4APL0RuzPaZbyWyW1yqaqAQdX4asawn3ICJjEeun+62LGUbv6bM0 QdzN2p1wsCoDVO7hr31cZS19Q6uC6QVvZbEWqEwunyBozLp4mtp2yNVb95/6igZRBTzU XPCOGQRI32tQv1TrwRBMldvKOsxI3pSuwBIJY=
MIME-Version: 1.0
Received: by 10.223.62.209 with SMTP id y17mr14024711fah.7.1320954422798; Thu, 10 Nov 2011 11:47:02 -0800 (PST)
Received: by 10.223.54.15 with HTTP; Thu, 10 Nov 2011 11:47:02 -0800 (PST)
In-Reply-To: <D7A0423E5E193F40BE6E94126930C49308E9E3555C@MBCLUSTER.xchange.nist.gov>
References: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com> <4297E946-980B-43C5-A01F-1F49706BC51E@tcb.net> <p06240808cad5c4d268eb@193.0.26.186> <0364A2AA-0CCF-408A-B5CB-42D7AFCAFB36@tcb.net> <p06240804cad81a9e4485@193.0.26.186> <54CED243-BDDD-45B9-AC5C-C6A97692FBF2@verisign.com> <CAL9jLaZ1GoN-iG4SWocVVhTKp5ppPOgHWcjh1J30GPnfwBPf+A@mail.gmail.com> <D7A0423E5E193F40BE6E94126930C49308E9E3555C@MBCLUSTER.xchange.nist.gov>
Date: Thu, 10 Nov 2011 14:47:02 -0500
Message-ID: <CAH1iCioCDTP_WgLCCh7ot1wJBHMZBjX5V3T08Y-7R986uS8pfQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
To: "Sriram, Kotikalapudi" <kotikalapudi.sriram@nist.gov>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] 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: Thu, 10 Nov 2011 19:47:04 -0000

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

On Tue, Nov 8, 2011 at 7:59 AM, Sriram, Kotikalapudi
<kotikalapudi.sriram@nist.gov> wrote:
>>
>> ooc, in regards to the above: is there any detailed analysis of how much extra overhead we can expect from these beacons if BGPSec were deployed universally today?  Specifically, the comment above, "an AS could cause the same impact on the routing system by changing other route parameters at the same frequency" seems to miss the point I think I see in the objection: what if _every_ AS must do this all the time (not just a rogue, or select few).  How much extra overhead would ensue if (say) someone took the current set of all ASes and prefixes and simulated the extra update traffic needed in (say) a day?  Maybe if we saw some numbers that told us how many additional updates and how much additional bandwidth this approach would require in a routing system like today's we could understand another aspect of much of a shift we are talking about?
>>
>
> Eric,
>
> According to
> http://bgpupdates.potaroo.net/instability/bgpupd.html
> the current global BGP system produces
> Average Prefixes per BGP Update:        2.24
> Average BGP Update Messages per second:         1.13
> Average Prefix Updates per second:      2.53
> From this we can compute:
> Average Prefix Updates per day =        218696
>
> Now if we consider a BGPSEC island of 100,000 participating prefixes
> (multiple ISPs form a BGPSEC island and there is BGPSEC between
> them and also in each ISP's entire customer cone):
> With 24 hour beaconing interval, we would have:
> Prefix Updates per Day = 100,000 (seen at each BGPSEC router)
> BGPSEC Update Size = 420B (for ECDSA-256)
> Average Bandwidth Required = 3.89 kbps (averaged over a day)
>
> Does this answer what you were asking for?
>
> Sriram
>
>
>
> _______________________________________________
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>