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

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