Open nicorusti opened 1 month ago
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?
That's exactly what it is, we just picked a generous value for the allowed inaccuracies. Picking a value that already had a meaning in SCION seemed less arbitrary than making up another arbitrary value. There doesn't seem to be a non-arbitrary choice.
In the early skeleton of the deployment draft, we also got this content by @juagargi :
Beaconing Scalability
The current beaconing system creates a large amount of beaconing traffic because every node multiplies the beacons by forwarding them to multiple other ASs. This is currently handled by rate-limiting identical beacons (with identical paths) to only be forwarded every some fixed propagation interval. With larger networks, the beaconing traffic is expected to grow “substantially”.
- Risk: beaconing traffic grows with network size, especially with multiple links between pairs of ASes.
- Large amount of beacon traffic.
- Large amount of state on beacon servers.
- Considerable amount of state on control services to store segments, and considerable data traffic for serving segments.
- The beacon interval in the SSFN has been considerably reduced to deal with beacon traffic. (?)
- This affects the propagation time of newly available routes. [To be verified]
- This can affect convergence time.
@juagargi I have some concerns regarding this text:
The beacon interval in the SSFN has been considerably reduced to deal with beacon traffic. (?)
Beacon traffic increases if the interval is reduced. Also, Dominik today mentioned they use 30s in general. We can perhaps clarify this and integrate this in the next release of the CP draft. If there are more researchy parts to this, we can add it to the research questions draft.
I am moving this to here, as with #42 we added a section about beaconing scalability, and I feel this would belong there more than to the open research questions.
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?
That's exactly what it is, we just picked a generous value for the allowed inaccuracies. Picking a value that already had a meaning in SCION seemed less arbitrary than making up another arbitrary value. There doesn't seem to be a non-arbitrary choice.
I'm not sure I can follow this argument. If we want an "arbitrary" value, we could just say so. Picking the minimum hopfield expiration time requires not only more text + a (pointless) reference, I also found it really confusing, thinking I was lacking some obvious understanding why the minimum hopfield expiration is relevant here. Also, the value is not really arbitrary, it depends on what the acceptable/expected clock deviation is. Maybe we can just write that? I don't really see the benefit of picking a time interval that is defined somewhere else in the document in an unrelated context.
Copied over from feeedbac received by @tzaeschke in https://github.com/scionassociation/scion-cp_I-D/pull/42#issuecomment-2211084556
Introduction
Avoiding Circular Dependencies and Partitioning
Partition and Healing
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, seepropagation interval
(unless PCB are forwarded immediately) and beaconorigination interval
.propagation interval
and theorigination interval
. As I understand, with propagation interval being set to e.g. 10Minutes, this adds up to 5hops1/210min= 25minutes for 5 hops.Path Exploration or Beaconing {#beaconing}
Introduction and Overview
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?Extending a PCB
selects the best combinations
: Maybe link to a section that explains how this works? And what "best" means?Path-Segment Construction Beacons
PCB Validity
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?Propagation of PCBs {#path-prop}
Selection of PCBs to Propagate {#selection}
Storing and Selecting Candidate PCBs
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, [...].