Hi, On Nov 9, 2012, at 4:07 AM, Randy Bush <[email protected]> wrote:
>>> no need. this is object based security. rama and hanuman have tals and >>> validate. having every cache in the world hit the CAs is not gonna >>> scale. >> Yes, perhaps we need a different architecture and transport protocol. > > measurement has shown that rsync is about as good as you're gonna do > performance-wise for a system where publication is centralised. Could you share those measurements? When we did lab testing on this our results were rather different. Presented at the interim in Vancouver: http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-interim-2012-sidr-5-0.pdf If one looks at just the simple case of performing a recursive rsync on a substantial rsync repository to determine if there are any updates, when there are none.. so just the overhead, determining this, no data transferred.. Then it's clear that rsync is not able to deal with substantial load and it's trivial to DoS. http://www.ietf.org/proceedings/interim/2012/07/27/sidr/slides/slides-interim-2012-sidr-5-1.pdf Here we proposed having a simple update file (10kB for test purposes) that can be fetched to determine if updates are needed. This performs several orders of magnitude better than doing a recursive rsync (5000 req/s vs 2 req/s on simple hardware). Then looking at the transport for just this file using http is roughly 10 times better than rsync (non-recursive, just that file). > and have a look at the ripe publication loads late last month. way to > go tim and alex. > I agree that given the current architecture a hierarchical structure is better for clients. As I mentioned though this is hard on the server for substantial repositories (roughly 10 times today: 70k objects and up vs our 7k today). >>> you may want to look at my ripe and nanog presos on the scaling >>> experiments we did. >> More arguments to think on alternate paths. > > actually, the results were the opposite. > > not that i am uninterested in working on future architectures. > Good. On that note I think it's worthwhile thinking about different complementary ways to deal with this. I.e. make the server side more scalable as well as considering flooding protocols and other ways to share data between RPs. > randy > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
