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

Clarifications in introduction and beaconing #46

Open nicorusti opened 1 month ago

nicorusti commented 1 month ago

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

Path Exploration or Beaconing {#beaconing}

Introduction and Overview

Extending a PCB

Path-Segment Construction Beacons

PCB Validity

Propagation of PCBs {#path-prop}

Selection of PCBs to Propagate {#selection}

Storing and Selecting Candidate PCBs

matzf commented 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.

nicorusti commented 1 month ago

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

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.