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

Project Planning #4348

Open
matzf opened this issue Jun 5, 2023 · 6 comments
Open

Project Planning #4348

matzf opened this issue Jun 5, 2023 · 6 comments

Comments

@matzf
Copy link
Contributor

matzf commented Jun 5, 2023

In a recent TC Implementation meeting, we've discussed the idea to develop and publish roadmaps for the development of the open-source SCION implementation.
The idea is to make planned development activity visible, to communicate planned features to users and help coordinate between developers.
It's not meant to be a binding commitment, and contributions outside of this process are still very welcome.

To start, we'll use a very simple process:

  • Gather input from community on planned work, desired features etc. in this github issue
  • The TC Implementation then compiles a roadmap from this input and publicly announces it

Everybody: please comment to this issue on development topics that you're either planning to work on yourself or that you would be keen to have someone else work on.

@matzf
Copy link
Contributor Author

matzf commented Jun 5, 2023

Very broadly, a goal of the SCION Association currently is to make the open-source SCION implementation directly operationally usable; the open-source SCION implementation should be (at least minimally) operationally viable on its own, not "only" serve as basis for an actually usable proprietary implementation.

  • Router and SCION-IP gateway performance
    Performance improvements required for router / gateway to become minimally viable alternatives to proprietary implementations
  • Critical missing features:
    • peering links
    • configurable path and routing policies in gateway
  • Stabilize inter-AS communication protocols
    Use appropriate network protocols between control services of different ASes, path control for inter-AS communication
  • Extended beaconing and path policy configuration language
    Required for connecting e.g. SCION education network (strictly non-commercial) to production network
  • Overlapping ISDs
    Required in future deployments, should be done as long as we can still do protocol-breaking changes
  • Router/control service key management
    Forwarding key and DRKey rollover
  • Authenticated SCMP control messages
    Partially implemented. Todo are validation and processing of SCMP messages at end host, rate limiting.
    Pending firm decision on whether or not this feature will be included in SCION or not.
  • Support SCION-native applications on larger variety of platforms
    Dispatcher-less application stack (allowing multiple independent SCION applications without OS support or central component)
  • General usability enhancements
    • Documentation (reference manuals, guides, tutorials)
    • Software packaging / releases
    • Sanitize configuration file tree and formats
    • Tooling

Myself, and in the near future one more software engineer directly employed by the SCION Association, are prioritizing these topics.

@johnstudarus
Copy link
Contributor

Is there any need for CI automation and regression testing? (Maybe that falls under Software packaging/releases). Or continuous validation of the SCION stack working on various bare metal service providers? @alicecuii - perhaps this would be a good project for you? Or if you want to tackle something larger, I'd love to see a message bus ported over to native SCION.

@jBainMartincoit - I'd like you to stay in the loop and see how you can help out with "General usability enhancements
Documentation (reference manuals, guides, tutorials)"

@matzf
Copy link
Contributor Author

matzf commented Jun 6, 2023

Looking at a recent CI run gives a bit of an overview of the set of checks that we run. This gives us a relative broad coverage already. Of course there can always be more and better tests, but I don't know of a subsystem or topic that is simply lacking tests.

One specific topic related automated testing where we could use help is this: there is a test harness called braccept (for border router acceptance tests). This sets up a SCION border router in a specific configuration, sends individual packets to it and validates that the router behaves as expected. Currently, this is very strict and tolerates no deviations from the open-source "reference implementation". Ideally, we'd want to reuse the same test harness to assess other router implementations, but for this it would need to be redesigned so it can accept and report on different behavior allowed by the of the specification (with all its "SHOULD"s and "MAY"s etc). The data plane specification document is currently being worked on, so it could be a good timing to work on this.
If this sounds like an interesting topic, we could create a github issue describing the requirements, so that you could then start to work out the details.

@JordiSubira
Copy link
Contributor

Currently, I am working on the following items on that list:

I also have interest in tackling:

  • Router/control service key management

I would kindly ask for whoever is interested on this to coordinate together :)

@benthor
Copy link
Contributor

benthor commented Jun 15, 2023

Below is a tentative categorization of the ongoing SCION work at the OVGU NetSys Lab.

Relevant to SCION Association Roadmap

These are topics and projects that we are working on that (might) affect the core protocol in some way and thereby seem most relevant to this roadmap.

  • eXpress SCION Router (XSR):
    A SCION border router making use of XDP and P4.
    Possible contributions from XSR to the reference BR (Lars + Robin):
    • Exchangeable data plane to allow using XDP and P4 on Tofino hardware with a Go control plane
    • eBPF implementation of the dataplane
    • AF_XDP sockets for bypassing the kernel network stack
    • MAC validation separated from the rest of the dataplane to allow for more flexible implementation in hardware (e.g. SmartNICs and FPGAs)
  • ID-INT development (Lars)
    • ID-INT support in Go BR
    • Host ID-INT
  • Support for Peering Links (Thorben / waiting on upstream)
  • SCION Certificate Authority and renew service for endhosts (Marten)

Further Ongoing Work - Related to SCION

The following topics probably have less impact on the protocol itself but depend (or are based) on SCION in some way. Many are centered on the end-host and seem less relevant to this roadmap but possibly still of interest.

  • Extend SEED with Tofino support (Lars + Robin)
  • BitTorrent over SCION improvements and GUI (Marten / student project)
  • DNS-over-QUIC support for SCION (Thorben / student project)
  • IPFS over SCION, SCION support in libp2p (Marten / student project)
  • Hercules ongoing work and improvements (Marten)
  • Deadline-aware Multipath Transport Protocol (Tony)
  • Scriptable path selector (Thorben)
  • Evolutionary Multi-objective optimization for optimal path selection (Tony / student project)
  • Bitcoin over SCION - Resilience against partitioning and other routing attacks (Tony / student project)
  • Splitting the border router's AES-CMAC validation and forwarding mechanisms to allow more flexible implementation in hardware (Lars)
    • Implement validation in NetFPGA (Björn + Florian)
    • Implement forwarding in P4 on Tofino switch
      • With support for external accelerator and ID-INT (Robin)
      • With support for EPIC (David G.)
  • PAN-bindings for C, C++ and Python (Lars)

Future Plans

Some further project ideas we have been throwing around but didn't do any work on yet

  • AES-CMAC Linux kernel implementation
  • Implement beacon filtering

@matzf
Copy link
Contributor Author

matzf commented Oct 10, 2023

The SCION Association's TC Implementation has compiled a roadmap document.
Find the full document here: 2023-10 Open-Source SCION Implementation Roadmap

Summary

Goals and Ambition

The open-source implementation of SCION aspires to be complete, i.e. not missing any required components or critical features, and and of sufficient quality (in terms of correctness, performance and usability), and with sufficient documentation to be minimally operationally viable.

Scope

  • Infrastructure components for a SCION network, namely the SCION control service and router, and tooling for the SCION control plane PKI
  • End host SCION network stack, tools, and application programming libraries to build SCION native applications
  • SCION-IP-Gateway

The scope of the project and these components is the “base” SCION protocol. For the time being expressly not in scope are experimental SCION-extensions such as Colibri, or EPIC.

Releases

When major work topics are complete, we'll publish releases consisting of:

  • Source Code: git version tag and source code bundles
  • Program binaries and installation packages
  • Documentation

Development focus

The focus for the planned work in this period is to improve operational readiness and deployability of the open-source components.

Planned work topics:

Infrastructure components (router, control service, gateway):

End host stack, SCION-native applications:

Possible timeline

Possible sequence of work items and rough estimated time of arrival, covering the period of about one year starting from now.

Disclaimer: this is based on rough estimates for the effort and many of these topics will require upfront discussion and detailed design work. The timing may depend on the availability of independent collaborators and their voluntary contributions. The included release milestones illustrate that we will release after completing major work topics and should not be mistaken to indicate a commitment to release these version numbers at the indicated dates or feature sets.

image


We'll update this post with links to issues/milestones to track the progress of individual topics.

This roadmap intends to guide the development work for the coming year or so, but it's not meant to be set in stone. We may amend the roadmap if circumstances change, and everyone is still welcome to contribute to this planning process by commenting or discussing in the chat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants