Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation

Wes Hardaker <> Thu, 24 May 2012 01:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E55C111E80AE for <>; Wed, 23 May 2012 18:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZXVNU6PXB3pp for <>; Wed, 23 May 2012 18:22:34 -0700 (PDT)
Received: from (unknown [IPv6:2001:470:1f00:187::1]) by (Postfix) with ESMTP id 60CB711E8072 for <>; Wed, 23 May 2012 18:22:34 -0700 (PDT)
Received: from localhost (unknown [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by (Postfix) with ESMTPSA id 0E19FBAD; Wed, 23 May 2012 18:22:33 -0700 (PDT)
From: Wes Hardaker <>
To: Rob Austein <>
References: <>
Date: Wed, 23 May 2012 18:22:33 -0700
In-Reply-To: <> (Rob Austein's message of "Mon, 26 Mar 2012 19:33:05 +0200")
Message-ID: <>
User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2012 01:22:35 -0000

Rob Austein <> writes:

> For those who didn't get to see the end of the "RPKI Over BitTorrent"
> presentation in today's SIDR meeting, the full slide deck is available
> at
> and should be relatively self-explanatory.

I've been thinking about this a lot lately, as it'll certainly be a
challenge to ensure everyone is up to date.  It doesn't matter whether
you "should have pulled" or whether "you pull right when you get a
request".  Either way, there is an underlying data distribution problem.

Most importantly, every bit of the repository needs to pretty much get
everywhere.  Rdist works well for trying not to duplicate data.
Bittorrent works well for sharing the load, but either requires a lot of
bittorrent start files (whatever they're called), which then becomes
hard to syncronize; or a small number of bittorrent files (one per
aggregation point) that indicate you need to refetch and entire .zip
file even if you already have most of it anyway.

But the real underlying problem is what I said above: every bit needs to
get efficiently to every place, ideally at time of initial publication.

This sure smells to me like a solution in need of multicast (or, more
accurately, "deployed multicast") with a fall back to something like
bittorrent for bootstrapping or when you've missed session data and
can't recover.  Multicast as a data stream would be much more efficient
is collecting updates, although there are still issues that would need
to be worked through like "how do you know you heard everything".  Oh,
and it only works if you multicast deployed to your site of course.
Wes Hardaker