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

[Eric Osterweil <[e-mail]>]

Hey Rob,

One more meta-comment on this thread: we (as designers) should not expect to be prescribing exactly how operators will run their systems.  Here in the very early stages we are seeing the early adopters deploy in ways that make _their_ operations easy.  imho, this is always going to be the bottom line/starting point.  If a solution requires a specific operational model (when others are technically correct), and the overall system scalability can suffer this way, I think we have a fundamental problem.  

More succinctly, operators shouldn't need to know why you want their certs in a hierarchy.  Rather, we should recognize that they are telling us that flat structures make their lives easier, and we should use that to reengineer what _they_ need.

Just my 0.02,

Eric

On Mar 30, 2012, at 11:10 AM, Rob Austein wrote:

> While I will admit to some astonishment that the following explanation
> could possibly be news to long-time participants in this WG (given how
> much time I've spent whining about this issue over the last five years
> or so both in public and in private), let me quote from the slides:
> 
>    * How efficient [fetching RPKI repositories using rsync] is
>      depends heavily on how the publication repositories are
>      organized.
> 
>    * In an efficiently organized repository, filesystem hierarchy
>      follows X.509 certificate hierarchy, so that one can pick up
>      significant subtrees with a single rsync connection.
> 
>    * To date, the RIRs have chosen to deploy flat hierarchies where
>      there is no relationship at all between filesystem hierarchy
>      within the repository and certificate hierarchy.
> 
> To make that more concrete, here's an example.  Let's assume we have
> the following trivial hierarchy: Bob and Betty are issued by Alice,
> Carol and Carl are issued by Bob, Dave, and Dana are issued by Carol,
> Dara is issued by Carl, and and all of these are hosted in a single
> repository.
> 
> In an inefficient, "flat" repository, the publication points for
> objects issued by these entities would look something like this:
> 
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Betty/
>    rsync://example.org/rpki/Bob/
>    rsync://example.org/rpki/Carl/
>    rsync://example.org/rpki/Carol/
>    rsync://example.org/rpki/Dana/
>    rsync://example.org/rpki/Dara/
>    rsync://example.org/rpki/Dave/
> 
> In a hierarchical repository, the same publication points would look
> more like this:
> 
>    rsync://example.org/rpki/Alice/
>    rsync://example.org/rpki/Alice/Betty/
>    rsync://example.org/rpki/Alice/Bob/
>    rsync://example.org/rpki/Alice/Bob/Carl/
>    rsync://example.org/rpki/Alice/Bob/Carl/Dara/
>    rsync://example.org/rpki/Alice/Bob/Carol/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dana/
>    rsync://example.org/rpki/Alice/Bob/Carol/Dave/
> 
> Assuming top-down tree walk (the normal case), retrieving objects
> issued by this set of entities takes eight rsync connections with the
> flat repository, as opposed to one rsync connection with the
> hierarchical repository.
> 
> In practice one might want a slightly more complex structure to limit
> the size of individual directories, but it doesn't matter so long as
> the filesystem hierarchy is organized in such a way that picking up
> an issuer's publication point picks up a non-trivial number of its
> subjects' publication points automatically.   It doesn't have to be
> perfect, just has to do enough better than the flat model to amortize
> the cost of setting up and tearing down the rsync connection over a
> significantly larger number of files.
> 
> This is not about PKI, it's purely an rsync efficiency issue.
> 
> Presumably there are scaling limitations to the hierarchical approach,
> but anecdotal evidence among the people I've asked ("I tried ... and
> it worked") suggests that, if the underlying networks and filesystems
> are in good shape, a single rsync connection ought to be able to
> handle up to at least 10,000 small files, perhaps a lot more than
> that.  Note that this is just talking about rsync itself: mileage
> might vary significantly if the underlying networks or filesystems are
> seriously broken.  Also note that these anecdotal estimates have not
> been tested in any rigorous fashion as far as I know, so that's
> another entry on my list of things we ought to be measuring.
> 
> Hope this helps to clarify the change I've been suggesting.
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr