TC Implementation meeting minutes

[matzf]

The Technical Committee (TC) Implementation is a body of the SCION Association who oversees and steers the open-source SCION implementation project. The TC Implementation is the @scionproto/scion-core-team.

This meta-issue records meeting minutes for the TC Implementation.

[matzf]

13. March 2023

@oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Proposal review

• 4300

  Proposal discussion still ongoing, no decision taken.

• 4293

  No time to discuss in detail; perhaps should involve the TC Standardisation in the discussion.

• 4286

  All in favor, details to be decided, https://github.com/scionproto/scion/issues/4286#issuecomment-1467748300

• 4278

  Accept

• 4149

  Discussed superficially, agreement that we should work on this topic but no decision on specific proposal.

• 4110

  Reject (https://github.com/scionproto/scion/pull/4110#issuecomment-1467712730) Consensus that there are no specific requirements to include this system with scionproto/scion and including it would be a significant burden. We want to keep the scionproto/scion implementation focussed on "core" SCION for now. We should document this somewhere.

• 4109

  Reject (https://github.com/scionproto/scion/pull/4109#issuecomment-1467673809) Similar discussion as above.

• 3738

  Accept, final call for comments (https://github.com/scionproto/scion/issues/3738#issuecomment-1467823583)

• 2168

  Reject. Using the PBKDF doesn't really make sense anyway as we always use random bytes. This whole thing should be reconsidered as part of the forwarding key roll over.

Other topics

• Configuration setup with various separate files is a mess and should eventually be (re-) designed. No strong preconceived ideas on what this should look like. @oncilla mentions caddy as an example of a well thought out system allowing on-the-fly changes to parts of the configuration without restarts.

[matzf]

1 June 2023 @oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Roadmap planning and releases

Roadmaps, Project planning

The idea is to make planned development activity publicly visible, to communicate planned work to users and help coordinate developers. We want to keep the process lightweight:

1. gather input from community on planned work, desired features etc. in a github issue or discussion
2. the TC compiles a high level roadmap and publishes this

The plans should be communicated in a way that encourages contributions. We need to avoid giving the idea "my topic is not in the roadmap so my contribution is not welcome", and also not "my topic is in the roadmap so it will be done without me doing anything".

Releases

We want to have (tagged) releases, to get

• version number to refer to
• way to communicate compatibilities and deprecation schedules etc.
• binary installation, as a easier way to start using the software

The audience for the releases is everybody in the open-source SCION ecosystem:

• operators of SCION infrastructure, operators of SCION end-hosts use the releases as source for binaries to install
• users of libraries
• maintainers of forks/dependent projects Even though not all audiences may have the same ideal release cadence, it makes most sense for us to just find a compromise. Due to the single repo setup, maintaining independent release cycles would be too complicated.

Not committing on either feature based or time based releases. We'll just start with something and see what works. The roadmaps include planned releases, but without committing to timing or feature sets.

@matzf will initiate the planning process described above, and setup the infrastructure for binary releases.

Proposal / PR review

• 4280, #4344

  Compatibility concerns: not all routers & services of an AS can be upgraded simultaneously, so services need to be able to function while the underlay port rewriting is only partially available.

  Two possible approaches:

  • keep the dispatcher and its supporting infrastructure in place. snet can use either dispatcher or direct UDP underlay
  • remove dispatcher support from snet etc. and replace the dispatcher with a simple UDP packet forwarder service on the end host as a compatibility shim.

  Deprecation of this compatibility layer should be announced, in order to make sure that the port-rewriting feature will eventually be enabled in deployments.

• 4339

  Can be merged.

Other topics

• Control plane implementation has some warts and rough edges that can only be fixed with an incompatible update. These issues should be collected in a github discussion so that we can work out a way to address all of it in one go. Examples are:
  • gRPC/HTTP2 over QUIC ugliness
  • SVC resolution
  • wrong namespace for proto definitions

[matzf]

2 October 2023 @oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @matzf

Roadmap planning and releases

Discussed roadmap document which will be published soon.

Proposal / PR review

• https://github.com/scionproto/scion/pull/4280, https://github.com/scionproto/scion/pull/4344

  @JordiSubira has continued to work on this topic and the latest version of the PR takes the compatibility requirements into account. @matzf, @oncilla and @FR4NK-W will all do a high-level review pass over this PR.

Other topics

• @marcfrei raised that there is a lack of coordination between developers, in particular for topics that are related to the SCION implementation but may not be in scope for the scionproto/scion repository. Concretely, there are multiple people working on application programming libraries for languages other than golang, but this work is invisible to most of us, and may be in fact duplicate. To address this, we'll:
  • Organize a regular, short call for contributors. For the start, we'll try the format of a ~30 minute call scheduled fortnightly, but only do it if there is demand. On the days before the call, we'll ask (in the #dev chat) if there are topics to be discussed, otherwise cancel it.
  • Offer adopting related projects into "contrib" repositories in the scionproto organization, to make this work more broadly visible. We'll have to figure out how exactly this would look like once we've identified topics that would be a good fit.

[matzf]

30 November 2023 @oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @jiceatscion, @matzf

Proposal / PR review

• 4439

  Public discussion ongoing, no decision needed now.

• 4434

  Prototype was built at hackathon. Needs more work, no decision needed now.

• 4389

  Will be important, but no decision needed now.

• 4388

  Needs more investigation, no decision needed now.

• 4293

  Low priority, not further discussed.

End host stack projects overview

Following up on a discussion in the previous week's Contributor Call; There are multiple development projects that concern the SCION end host stack. Created a document aiming to give an overview on how these parts will fit together. Brief presentation by @matzf and discussion; no vetos, so created pull request for more detailed review and public discussion

• 4451.

Packaging; testing on different platforms

Looking for options to test cross-compiled packages on arm (for WIP #4448).

[jiceatscion]

10 June, 2024 @oncilla, @lukedirtwalker, @FR4NK-W, @marcfrei, @jiceatscion, @matzf

Administrative matters

• Due to Matthias leaving, the committee needs a new chair. The departing chair proposes that the job be available to any committee member. No objection, but no taker either. JC accepts the position. No objection.
• Due to Matthias leaving the committee would benefit from a new member with long SCION experience. Several present suggest asking if Jordi Subirà would be interested. Unanimous approval in favor of inviting Jordi. Assuming he is willing, the board's approval would be required (but is probable).

• The project could use more code change approvers. Currently only committee members can approve. Consensus is that we could give approval powers to non-committee members. All present agree on the following process:

  • A future approver, is invited to co-review PRs, without actual power to approve.
  • If current approvers find the reviews helpful, the reviewer is given approval powers.
  • This may at some point be followed by an invitation to join the committee.

  Several members propose to start this process with Tilman Zäschke. Motion approved.

• François noticed that the "technical committee - implementation" does not, per it's charter, report to the Board. Due to a typo in the charter. This would need to be checked and fixed.

Communications

• JC provides a summary of the board of advisors meeting.

Roadmap

• Many items on the roadmap are shifting by 4 months.
• Matthias and JC propose to not add new major roadmap items for now, since the previous roadmap was optimistic and (per the conclusions of the BoA) innovations should not be pursued yet. Motion approved.
• Gateway enhancements can be de-prioritized (the OS gateway code isn't used much).
• Configurable beaconing policy is needed badly by SCIERA. A discussion follows regarding how best to implement that. No clear decision emerges.
• Dispatcher-less: quite a few small cleanup items. Enough to constitute a task on the roadmap to account for time spent.
• ConnectRpc is part of the roadmap item "stabilize the CS API". Dominik anticipates in to be in next release w/ a feature flag. Dominik's estimates the work to be 80% complete. One clever member remarks that it means it is close to half done.

Proposals reviews

• Replacing SVC resolution: not started. Lack of time.
• Support for overlapping ISDs: will be abandoned. Lack of demand. It probably means that the requirement that AS numbers be globally unique isn't useful. A discussion ensues but no definitive conclusion. The topic will need more work before it can be closed.
• gRPC/QUICK: approved and making progress (connectRpc).
• Cross-segment hop fields: abandoned. Lack of time.
• NAT support: Marc and Til are working on a design proposal.