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

• doc: update timestamp spec #4300
  Proposal discussion still ongoing, no decision taken.
• Overlapping ISDs #4293
  No time to discuss in detail; perhaps should involve the TC Standardisation in the discussion.
• cppki: require segment lifetime fully covered by certificate chain #4286
  All in favor, details to be decided, cppki: require segment lifetime fully covered by certificate chain #4286 (comment)
• slayers: add packet validation #4278
  Accept
• Refactor addr.HostAddr types #4149
  Discussed superficially, agreement that we should work on this topic but no decision on specific proposal.
• doc: epic-sapv #4110
  Reject (doc: epic-sapv #4110 (comment))
  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.
• doc: CASA #4109
  Reject (doc: CASA #4109 (comment))
  Similar discussion as above.
• router: enforce configured MTU #3738
  Accept, final call for comments (router: enforce configured MTU #3738 (comment))
• AS Master key derivations should use salt value with a random part #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

• doc: design doc for end host without dispatcher #4280, end host, router: dispatch UDP in router, remove dispatcher socket #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.

• doc: design document for the border router redesign #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

• doc: design doc for end host without dispatcher #4280, end host, router: dispatch UDP in router, remove dispatcher socket #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

• Proposal: Cross-Segment Hop Fields #4439
  Public discussion ongoing, no decision needed now.
• HTTP3 based SCION control plane #4434
  Prototype was built at hackathon. Needs more work, no decision needed now.
• proposal: re-think SCMP error propagation in snet library #4389
  Will be important, but no decision needed now.
• proposal: Resolving the SVC resolution issue #4388
  Needs more investigation, no decision needed now.
• Overlapping ISDs #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

• doc: end host stack projects overview  #4451.

Packaging; testing on different platforms

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