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

"John G. Scudder" <> Thu, 24 May 2012 20:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C4CA21F856C for <>; Thu, 24 May 2012 13:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NgNUVrnI-vM9 for <>; Thu, 24 May 2012 13:14:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BB02A21F8568 for <>; Thu, 24 May 2012 13:14:16 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 24 May 2012 13:14:19 PDT
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 24 May 2012 13:13:17 -0700
MIME-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: "John G. Scudder" <>
In-Reply-To: <>
Date: Thu, 24 May 2012 16:13:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <>
To: Wes Hardaker <>
X-Mailer: Apple Mail (2.1278)
Cc: Rob Austein <>,
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 20:14:21 -0000


On May 23, 2012, at 9:22 PM, Wes Hardaker wrote:

> 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.

I'm far from an expert on Bittorrent but I believe this is not right. A .torrent file (what you called a "bittorrent start file") can contain contain a list of files to be transferred, there's no mandate to zip them into a single file first. Presumably the BT protocol is smart about not transferring files you already have locally -- that's kind of the whole point. Rob's "operational overview" slide makes it clear he's imagining operating in the collection-of-files mode. 

Probably there are some issues with this mode of operation too -- if you list every single RPKI object individually then the size of the .torrent file scales linearly in the size of the unauthenticated/ tree. This seems likely to suck since I am guessing BT's normal operating regime is to transfer small numbers of large files rather than potentially vast numbers of relatively tiny files.

The zip files Rob's slides talk about just contain the .torrent file and manifest (which is also O(N) in the size of the tree, sigh).

Speaking purely as a Bittorrent amateur + not the author of the slides!