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 beaconing fast retry at bootstrapping #48

Closed
nicorusti opened this issue Jul 8, 2024 · 1 comment
Closed

Clarify beaconing fast retry at bootstrapping #48

nicorusti opened this issue Jul 8, 2024 · 1 comment
Assignees
Labels
enhancement New feature or request Prio 1
Milestone

Comments

@nicorusti
Copy link
Member

In #42 we discussed about propagation interval in case of "bootstrapping"/"cold-start". Following clarifications in this slack discussion, it turns out that:

There is a fast recovery where we attempt to beacon a lot more frequently until we have beaconed successfully over the given interface

This is implemented in here in scionproto. There was just one note in the draft that got removed in #42. We should re-add this, together with some clarifications, especially in the Effects of Clock Inaccuracy and Path Discovery Time and Scalability sections.

Some points to be addressed were reported by @tzaeschke here:

Storing and Selecting Candidate PCBs

  • Note that during bootstrapping and if the AS obtains a PCB containing a previously unknown path, the AS SHOULD forward the PCB immediately, [...].
    • Is this true? It appears to conflict with many other parts of the document that talk about propagation intervals in the contect of cold-start.
    • Is there a difference between "bootstrapping" (used here) and "cold-start" (used in other places)? Maybe stick to one term or explicitly declare equality?
    • Is this subject to the "Best 5 PCB" rule? -> If a new path is immediately forwarded, does it count towards th "best 5"? If not, then we are effectively
      forwarding >5 paths, correct? If yes, then the first 5 paths are always the best until they expire and can be replaced with other paths?
    • What means "unknown path"? Does it refer to all links in the segment or just the remote AS? If it is all links in the segment, then there may be many new paths
      coming in all the time that need to be forwarded immediately, or not?

Effects of Clock Inaccuracy

  • PCBs are propagated at a configurable interval (typically, one minute).
    • Unless they are new, then the interval is ignored, see "immediate cold-start PCB forwarding".
    • Maybe rephrase: "(typically, one minute)" ---> "immediately for new beacons, minimum 5secs for intra-ISD, minimum one minute for inter-ISD"?

Path Discovery Time and Scalability {#scalability}

  • Generally, the time until a specific PCB is built depends on its length and the propagation interval.?
    • I think in the context of "cold boot¨, the propagation delay is "0", see "immediate cold-start PCB forwarding".
  • PCB arrives at a random point in time during the interval and is buffered before potentially being propagated
  • see "immediate cold-start PCB forwarding"
  • Also, I think the calculation needs to take into account the "beacon origination interval".

Intra-ISD Beaconing

  • Otherwise, child ASes at distance D below the new link, learn of the new link after D further propagation steps
    • New path: "immediate cold-start PCB forwarding"

Inter-ISD Beaconing

  • On a cold start of the network, [...]. With a 5 second propagation period [...]
    • Above it says that bootstrapping results in immediatede forwarding, see "immediate cold-start PCB forwarding".
  • 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.
  • Also: see previous point about "immediate cold-start PCB forwarding"
@nicorusti nicorusti changed the title Clarify beacons at bootstrapping Clarify beaconing fast retry at bootstrapping Jul 8, 2024
@nicorusti nicorusti added enhancement New feature or request Prio 1 labels Jul 9, 2024
@nicorusti nicorusti added this to the v-05 milestone Jul 9, 2024
@nicorusti nicorusti mentioned this issue Jul 9, 2024
@nicorusti
Copy link
Member Author

Handled in #49

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Prio 1
Projects
None yet
Development

No branches or pull requests

3 participants