Closed matzf closed 1 month ago
Thanks for fixing my typos, @nicorusti.
General Note:
ASes could always switch to otherwise unused links
.
unused
links? Unused
indicates that they are not in the "Best PCB" set.
If that is the case, then we cannot simply "switch" to use them, we first need to have them discovered by beacons. This takes time, see propagation interval
(unless PCB are forwarded immediately) and beacon origination interval
.propagation interval
and the origination interval
.
As I understand, with propagation interval being set to e.g. 10Minutes, this adds up to 5hops1/210min= 25minutes for 5 hops.Intra-ISD beaconing
: Isn't this incomplete? How are DOWN segments created? I think leaf ASes need to propagate paths back to the COREs? -> Link to #intra-reg ?Inter-ISD beaconing
: Similarily, I think there is a step where CORE beacons share their path DB with other CORE ASes in the same ISD?selects the best combinations
: Maybe link to a section that explains how this works? And what "best" means?For the purpose of validation, a timestamp is considered "future" if it is later than the current time at the point of validation plus the minimum expiration time of a hop field (337.5 seconds, see ).
Maybe add an explanation why we add the minimum expiration time here?
Shouldn't "future" simply be timestamp + some_delta_to_account_for_server_time_inaccuracies, where the delta is maybe a few seconds rather than 5.5 minutes?temporary storage
: Maybe clarify what "temporary" means.
At each propagation event, each AS selects a set of the best PCBs from the candidates in the beacon store
The best PCBs set size SHOULD be at most "50" (PCBs) for intra-ISD beaconing and at most "5" (PCBs) for core beaconing.
Note that during bootstrapping and if the AS obtains a PCB containing a previously unknown path, the AS SHOULD forward the PCB immediately, [...].
PCBs are propagated at a configurable interval (typically, one minute).
PCBs with N hops may be validated up to N intervals (so typically N minutes) after origination
Rephrase The norm is 6 hours.
to ... SHOULD be 6 hours
? What does 'norm' mean?
In comparison to these time scales, clock offsets in the order of minutes are immaterial.
~balances _OF_ the number of discovered paths
-> remove OF~ Already fixed
Generally, the time until a specific PCB is built depends on its length and the propagation interval.
?
PCB arrives at a random point in time during the interval and is buffered before potentially being propagated
As will become apparent, the inter-ISD beaconing results in excessive overhead with very large numbers of participating core ASes.
The ideal topology for SCION is to keep the inter-ISD core network to a moderate size, to benefit from the divide-and-conquer partitioning of ASes into ISDs and the efficiency of the intra-ISD beaconing.
Otherwise, child ASes at distance D below the new link, learn of the new link after D further propagation steps
On a cold start of the network, [...]. With a 5 second propagation period [...]
When a new link is added to the network, it will be available to connect two ASes at distances from the link D1 and D2 from the link, respectively, after a mean time (D1+D2)*T/2.
Thank you for your feedback @tzaeschke ! I respond here regarding the scalability and clock inaccuracy sections. For other sections, and for points that we don't have time to address in time this revision, I opened separate issues:
I think the word "typically" is misleading here, it can be understood as "PCBs [...] are validated typically after N minutes", whereas it actually means that the maximum is typically N minutes. Rephrase to "(maximally N minutes)"
Done, maximally N minutes sounds good.
Also, AFAIK, the current configured real-world interval is more like 10-15 minutes...?
@matzf I is it 1 min as in the draft, or 10-15? 10-15 feels a bit high to me
Rephrase
The norm is 6 hours.
to... SHOULD be 6 hours
? What does 'norm' mean?
I am a bit reluctant to use RFC2119 language (uppercase SHOULD) for exactly 6 hours. This is a value that overall depends on the maximum AS path expected in the network, and it might as well be a different value. I therefore rephrased like this:
For this reason, it is unadvisable to create hops with a short expiration time, that should be around 6 hours.
In comparison to these time scales, clock offsets in the order of minutes are immaterial. This relates only to the previous paragraph about certificates; I guess it should be attached to the previous paragraph?
Done.
The notes contain several references to "immediate cold-start PCB forwarding"
@matzf clarified here that this is not the case, I removed that note, this should also solve some many of the consistency issues you reported.
Also, I think the calculation needs to take into account the "beacon origination interval".
To be handled in https://github.com/scionassociation/scion-cp_I-D/issues/45
As will become apparent, the inter-ISD beaconing results in excessive overhead with very large numbers of participating core ASes.
Does this need to be in the IETF spec?
Good point, I rephrased this section to:
To achieve scalability in its routing process, SCION uses a divide-and-conquer approach, partitioning ASes into ISDs. In order to benefit from this, an ideal topology SCION should keep the inter-ISD core network to a moderate size. For more specific observations, we distinguish between intra- and inter-ISD beaconing.
What is done to ensure this? What happens if the size is not moderate? What is "moderate"?
We give some numbers in the Inter-ISD Beaconing section with an example with 1000 core ASes, this gives a rough figure. The bandwidth and computation overhead figures there should also give a rough hint of what happens if the network grows too much: the overhead becomes considerable. What is done to ensure this IMHO depends on how the network is deployed, I think this topic would be a better fit to be discussed in the new deployment Internet Draft, I opened an issue there: https://github.com/scionassociation/scion-deployment_I-D/issues/1
Typo: duplicated "from the link";
Fixed
Commented on the related issues for the other sections.
Also, AFAIK, the current configured real-world interval is more like 10-15 minutes...?
@matzf I is it 1 min as in the draft, or 10-15? 10-15 feels a bit high to me
The 1 minute value seems realistic. SCIONLab uses 5 seconds for non-core beaconing and 1 minute for core beaconing. Anapaya's infrastructure reportedly runs with 30s.
Scalability of path discovery.
Fixes #8