scionassociation / scion-cp_I-D

Specification of the SCION control plane.
https://scionassociation.github.io/scion-cp_I-D/
Other
1 stars 0 forks source link

Clarify origination v.s. propagation interval #45

Open nicorusti opened 1 week ago

nicorusti commented 1 week ago

We currently only mention propagation interval in the draft. However, there is a separate origination interval in the implementation.

As reported by @tzaeschke in https://github.com/scionassociation/scion-cp_I-D/pull/42#issuecomment-2211084556 :

The notes contain several references to "beacon origination interval", i.e. the interval at which new beacons are created. I couldn't find any description of this interval, maybe I overlooked it? Is it the same as the propagation interval? I couldn't find a discussion of beacon origination interval (or the RegistrationInterval), see "DefaultOriginationInterval" (or the DefaultRegistrationInterval) in the code.

Partition and Healing

Also: Does "Healing" include "adding new links"? In this case we also need to wait for the propagation interval and the origination interval.

Path Discovery Time and Scalability {#scalability}

Also, I think the calculation needs to take into account the "beacon origination interval".

Does this distinction make sense? We might distinguish between interval for core beaconing and intra-ISD beaconing

matzf commented 1 week ago

In my opinion, the distinction between origination interval and propagation interval is not necessary for the draft. The term "propagation interval" might not be entirely apropos for beacon origination, but the concepts are identical. I'd suggest to use "propagation interval" exclusively in the draft, or alternatively replace it with a more generic term (e.g. "announcement interval" or "PCB creation interval").

For what it's worth, I think the distinction of origination and propagation interval is not even useful in the implementation. If anything, we'd want to separately configure a frequency for core and non-core beaconing, but the configuration does allow to make this distinction. In the draft, I think this also not necessary. I think the description is abstract enough to allow different values for this interval in different contexts.


Also: Does "Healing" include "adding new links"? In this case we also need to wait for the propagation interval and the origination interval.

Quoting the current text from that section:

Recovering (also called healing) from a partitioned network is also seamless, as only coarse time synchronization between the partitions is required to resume normal operation and move forward with updates of the cryptographic material.

My reading was that it means that the control plane can just resume with path discovery once the broken links have been recovered. That doesn't mean that it won't take some time to actually build the paths from that point on, just that nothing special needs to be done. It's a bit vague, and perhaps also not very illuminating, but to me it seems that this doesn't have to discuss the time until paths are found.

nicorusti commented 1 week ago

Also, for the records, these are the values in the prod network (as confirmed by @oncilla)

[beaconing]
origination_interval = "30s"
propagation_interval = "30s"
registration_interval = "5s"