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

Christopher Morrow <> Thu, 24 May 2012 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EBBC21F8568 for <>; Thu, 24 May 2012 14:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y-BjSSTZkxyH for <>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A603A21F8564 for <>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so280039obb.31 for <>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kl2AYz4P8fgz03mTHAmXnHJp8NRs9fuXYZU/WDH1I1o=; b=DbQIlcuuN/pSZ0yWiwBABlbFY6gIjhVUdGORV+bEjdF0B8lFTJjKFvo84den/X7GpW YFdJfyAG4LmDyES/HFED6MxMXe93M3X+rWf8xtCc10T6wtJ1EMEI3RWjGFTcRZT0Eakf /T4RjSZOji2x/fDqCmpwcnmtdKJXPaAxPYK5NoAtx4hsU3B7nDyxPwi/TAkovUS6eLC6 EKNX1uEcUaco2N3Bvtoar/mIZDnEDBpoGlDdSfkWqcpJNb+U1QuuDL67//RzNhsWsDkp SedUirSff35RysSydwNyFMTOBq+0Jm8D4DZszfd7XTJLO3yuuErGifJLSzSq1NJ5HNcG E01w==
MIME-Version: 1.0
Received: by with SMTP id w11mr770829obh.64.1337893915213; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Received: by with HTTP; Thu, 24 May 2012 14:11:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 24 May 2012 17:11:55 -0400
X-Google-Sender-Auth: jyXuCA9rwyNdLYwaGusVYbtmPyY
Message-ID: <>
From: Christopher Morrow <>
To: "John G. Scudder" <>
Content-Type: text/plain; charset="ISO-8859-1"
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 21:12:00 -0000

On Thu, May 24, 2012 at 4:13 PM, John G. Scudder <> wrote:
> Wes,
> 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.

per publication-point I think? So you have to collect N-thousand of
these torrent files, and keep N-thousand torrent jobs running and keep
state on N-thousand remote torrent files changing over time... some of
this could be alleviated in many ways, worst case though is that.

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

well, folk like fedora/ubuntu/etc offer full distributions over
bittorrent ... I've not done a find . | wc -l on a system like this in
a long time, but 4-8 gb over bittorrent for a few thousands of files
seems to work fairly well for them.

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

maybe looking at a bittorrent-like solution for intra-as distribution
is interesting though? though that also seems (to me) to fall into
'local implementation' land, from the vendor/arms-dealer that sold me
the solution.

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

me too, as an amateur of bittorrentz I mean.


> --John
> _______________________________________________
> sidr mailing list