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

Christopher Morrow <morrowc.lists@gmail.com> Thu, 24 May 2012 21:12 UTC

Return-Path: <christopher.morrow@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 4EBBC21F8568 for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 14:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-BjSSTZkxyH for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A603A21F8564 for <sidr@ietf.org>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Received: by obbeh20 with SMTP id eh20so280039obb.31 for <sidr@ietf.org>; Thu, 24 May 2012 14:11:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.182.31.11 with SMTP id w11mr770829obh.64.1337893915213; Thu, 24 May 2012 14:11:55 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.182.166.71 with HTTP; Thu, 24 May 2012 14:11:55 -0700 (PDT)
In-Reply-To: <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net>
Date: Thu, 24 May 2012 17:11:55 -0400
X-Google-Sender-Auth: jyXuCA9rwyNdLYwaGusVYbtmPyY
Message-ID: <CAL9jLabHU-nhx0x1MPvc2PNH9_ovf_B1wL6NcgLx3=m+dN1Adw@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: "John G. Scudder" <jgs@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: sidr@ietf.org, Rob Austein <sra@hactrn.net>
Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation
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, 24 May 2012 21:12:00 -0000

On Thu, May 24, 2012 at 4:13 PM, John G. Scudder <jgs@juniper.net> 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.

-chris

> --John
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr