Clarifications in introduction and beaconing

[nicorusti]

Copied over from feeedbac received by @tzaeschke in #42 (comment)

Introduction

Avoiding Circular Dependencies and Partitioning

• Does this section (title) make sense as it is? The two topics (circular dependencies and partitioning) appear unrelated. Partitioning is discussed in a separate subsection
• Also, this section claims to contain a list that explains how circular dependencies are avoided.
  However, I am not sure how anything in the list explains anything about circular dependencies?

Partition and Healing

• ASes could always switch to otherwise unused links.

  • What are 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.
  • Also: Does "Healing" include "adding new links"? In this case we also need to wait for the 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.

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.

  • How long are PCBs stored?
  • Under what circumstances are they removed, e.g. when they expire?
  • Or possibly replaced with a new version? What if the new version has an earlier expiration date?

• 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.

  • I found this a bit confusing: the "50" appears to be the total number of beacons forwarded for non-core ASes, whereas the "5" refers to the number of
    PCBs per remote CORE AS. Maybe clarify this?

• 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?

[matzf]

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.

[nicorusti]

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.

[tzaeschke]

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.