Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify origination v.s. propagation interval #45

Closed
nicorusti opened this issue Jul 7, 2024 · 3 comments
Closed

Clarify origination v.s. propagation interval #45

nicorusti opened this issue Jul 7, 2024 · 3 comments

Comments

@nicorusti
Copy link
Member

nicorusti commented Jul 7, 2024

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

As reported by @tzaeschke in #42 (comment) :

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
Copy link
Contributor

matzf commented Jul 8, 2024

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
Copy link
Member Author

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"

@nicorusti nicorusti added this to the -07 milestone Jul 26, 2024
@nicorusti nicorusti removed this from the -07 milestone Sep 19, 2024
@nicorusti
Copy link
Member Author

I agree with @matzf that there is no editing action needed on the draft because of this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants