WG Chair Hat Off
On 27/10/2009, at 10:52 AM, Sandra Murphy wrote:
Geoff, I thought the reason for using (and mandating) rsync was
precisely to avoid re-load of the whole data space on each
synchronization.
I thought so too.
If so, what estimates would you use of how much of the space would
be new (what Matt calls "fresh") data at each synchronization time
point?
The numbers I guessed at below assumed rsync-like behaviour.
An alternative approach would be based on a relying party retrieving
the manifest of the publication point and performing the comparison of
the local store state with the repository based on the manifest data.
At the level of approximation I was using to query this suggested
refresh frequency I do not think that it would make very much
difference to the load guesstimates.
Geoff
(This is a clarification response, which is not made in my role as a
co-chair.)
--Sandy
(This is a clarification query, which might be viewed as co-chair
hat on or member hat on, or both, your choice.)
On Tue, 27 Oct 2009, Geoff Huston wrote:
WG Co-Chair Hat OFF
Hi Matt,
entities who are actually using RPKI data for routing SHOULD be
fetching fresh data from the repositories at least once every
three hours.
3 hours?
At a first pass that seems very frequent.
From a server's perspective if there are 30,000 AS's out there and
each is running a local cache and each is a distinct relying party
of the RPKI system, then the local hit rate at the server would be
3 per second, assuming that all the relying parties evenly spread
their load (which is a pretty wild assumption - the worst case is
that all 30,000 attempt to resync at the 3 hour clock chime point)
Assuming that a repository sweep with no updates takes 30 seconds
to complete then the server would have an average load of some 90
concurrent sync sessions. If there is a local rekey then the
refresh would also imply a reload of all the signed products at
this repository publication point. Assuming that this would then
take 3 minutes to download, then the rekey load per server would be
of the order of 540 concurrent rsync sessions as an average load.
These load numbers appear to me to be somewhat large.
From the relying party's perspective if there are 30,000 distinct
RPKI repository publication points, and a serial form of local
synchronisation using a top-down tree walk then the same set of
assumptions imply that the relying party's perspective then it
needs to process the synchronisation with the remote cache
(including minimally the manifest crypto calculation at a rate of 3
per second. Assuming that there are 200,000 distinct ROAs out there
that are re-validated at each fetch then once more the numbers
imply that a 3 hour refresh would infer that the relying party
would need to validate 200,000 ROAS in 10,800 seconds. That
probably needs some pretty quick hardware.
These numbers are pretty much a toss at a dart board, and the
draft's authors' may well be using a different scale model to
justify this recommended time cycle. What numbers did you have in
mind Matt that would make this "SHOULD" 3 hour refresh cycle
feasible in a big-I Internet scenario of universal use?
Geoff
WG Co-Chair hat off
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
