Session Date/Time: 28 Jul 2022 17:30

panrg

Summary

The panrg session featured three main presentations and discussions. First, an in-depth component analysis of the SCION next-generation internet architecture was presented, detailing its PKI, Control Plane, and Data Plane, and discussing its interaction with existing protocols and deployment models. The second presentation outlined a problem statement for overlay routing in the context of evolving internet applications and proposed extensions. Finally, a proposal for the separation of data path and data flow sublayers in the transport area was introduced, aiming to address challenges posed by increased middlebox presence and new communication models. Key outcomes include the SCION team agreeing to further decompose and specify their architecture in multiple drafts and an agreement to continue discussions for all topics on the panrg mailing list.

Key Discussion Points

SCION Component Analysis (Nikola from ETH Zurich)

SCION Overview: A path-aware, inter-domain internet architecture prioritizing availability (including against adversaries), routing security, and scalability. It originated as a research project in 2009 and is now in production, notably for the Swiss inter-banking network.
Isolation Domains (ISD): Autonomous Systems (ASes) are grouped into ISDs. Each ISD has an independent root of trust, providing flexible trust models and aiding scalability by splitting routing processes into intra-ISD and inter-ISD.
Three Core Components:
- Control Plane PKI (CP-PKI):
  - Function: Provides a per-ISD trust model, allowing flexible trust decisions for end hosts. Implements a voting mechanism for critical changes to ensure multilateral governance and prevent single points of compromise.
  - Dependencies: Minimal, requiring initial AS bootstrapping (ceremony) and time synchronization.
  - Outputs: Trust Root Configurations (TRCs) and AS certificates used for routing authentication.
  - Relation to existing PKI: Uses X.509 certificates but with unique voting mechanisms and an ISD-based trust model distinct from the web PKI.
- Control Plane (CP):
  - Function: Explores network topology via "beaconing" and disseminates authenticated path segments. Ensures authentication of control messages. Supports multi-path routing.
  - Dependencies: Relies on CP-PKI for certificates to authenticate path information. Uses ISDs for scalable routing (two-tier hierarchy).
  - Outputs: Authenticated hop-by-hop path segments for ASes and interfaces.
- Data Plane (DP):
  - Function: Constructs packets with the full path inscribed in the header. Performs forwarding using these paths. Authenticates segments at each hop with simple AS operations.
  - Dependencies: Takes authenticated segments from the control plane. Can be influenced by application requirements (e.g., latency-optimized paths).
  - Properties: Routers are simple (no forwarding tables). Inter-domain only; reuses existing intra-domain routing/forwarding (e.g., MPLS, IGP, Segment Routing). Multi-path for availability; end hosts perform path selection. Separates locator (ISD/AS tuples) and identifier (existing IPv4/IPv6 addresses).
Interaction with Existing Protocols:
- RPKI: SCION does not include prefix origin authentication. It is complementary, and transition mechanisms from IP to SCION leverage RPKI for prefix origin attestation.
- LISP: Shares the idea of separating routing identifiers and locators. Similar gateway concepts (SCION-to-IP Gateway / SIG). LISP lacks multi-path and authentication.
- Segment Routing (SR): Primarily intra-domain, whereas SCION is inter-domain. Potential for cooperation (SR within an AS, SCION between ASes). SR lacks authentication for untrusted environments.
Component Independence: While components offer some standalone benefits (e.g., PKI for symmetric key derivation), maximum properties and functionality are achieved when all three components work together.
Deployment & Transition Mechanisms: Current deployments primarily use SCION-to-IP Gateways (SIGs) at the network edge (CPE or ISP core network) or within an AS (deployments 'B' and 'D' in the slides). Native SCION hosts ('A') are less common. SIGs enable significant benefits (e.g., multi-path, availability for critical industries like banking/healthcare) without requiring modifications to every endpoint. Full native SCION offers application-level path selection but requires wider endpoint adoption.

Overlay Routing Problem Statement (Gongli from Huawei)

Motivation: Modern internet applications (real-time communication, VR/AR, metaverse) demand stricter network quality (latency, throughput, packet loss, jitter). Traditional internet is best-effort, BGP routing is business-driven, not performance-driven. Existing solutions like 5G/SDN are often single-domain.
Overlay Networks: An old technology revisited, deployed by large OTT providers. They use private or hybrid infrastructure to relay traffic via Points of Presence (PoPs) to offer better performance.
Current Overlay Routing Challenges:
1. Local vs. Global Optimal: Current decomposition into access and backbone segments may not yield globally optimal end-to-end paths (e.g., example of routing via Dubai vs. South Africa).
2. Complex Signaling: Multiple steps (DNS query, access controller request, access point assignment) are needed to establish an overlay path.
3. Lack of Path Awareness: Endpoints have no information about the available paths, limiting flexibility for service-specific path selection.
Proposed Extensions:
1. End-to-End Joint Path Computation: Compute entire overlay path (access + backbone) by a centralized controller that can act as a root DNS server.
2. DNS Tunneling for Path Requests: Reuse DNS for path configuration. An endpoint queries DNS for a destination address and includes an overlay path request (e.g., via EDNS option code). The DNS response returns both the address and the end-to-end overlay path.
3. Endpoint Source Routing: Endpoints use source routing (or segment routing) by including the list of PoPs and optional path properties (latency, bandwidth) in packet headers. This allows for path selection directly at the endpoint and stateless forwarding by overlay nodes.

Separation of Data Path and Data Flow Sublayers (Chris Casaei from WIDE Project)

Motivation: The internet is evolving beyond a pure end-to-end model due to the proliferation of middleboxes (QoS, firewalls, edge computing, in-network computing). Current transport layer protocols (RFC 1122/1123) are tightly coupled, making it difficult to introduce new features or coordinate with the IP layer.
Transport Layer Functionality Review:
- Some functions are purely end-to-end (reliable data, integrity checks, basic flow control, security).
- Some require data path information (Path MTU discovery, congestion control - e.g., ECN).
- Some are waypoint-aware (firewalls, policy-based routing).
Problems with Current Protocols: Tightly coupled design (e.g., QUIC combines many functions). Reinvention is often needed for new transport protocols. Difficult to achieve IP layer cooperation (e.g., ECN).
Proposal: Separate transport layer into two sublayers:
1. Data Path Sublayer: Sits above the IP layer, handles per-path or path-related state.
  - Functions: Trajectory/waypoint handling, bi-directional connection management, resource monitoring for congestion, congestion control data, flow multiplexing (similar to QUIC connections), packet duplication/replication.
2. Data Flow Sublayer: Sits above the Data Path Sublayer, handles per-flow state.
  - Functions: Retransmission, flow control (buffer management for receiver), flow prioritization, end-to-end security, inverse multiplexing for multi-path protocols.
Use Case (M2M Communication): Machine-to-machine traffic often operates at maximum rate, causing congestion in best-effort networks. With network feedback (congestion, priority) from the Data Path layer, a Data Flow layer could arbitrate flow priority. For instance, a low-priority archive transfer could be throttled to allow a high-priority data processing flow to achieve a higher rate. This extends concepts like ECN with more precise feedback (e.g., streaming telemetry from data centers).
Next Steps: Continue discussion on the mailing list, review existing transport protocols for their functionalities, identify additional use cases for the proposed separation, and develop example protocols based on this architecture. The goal is to evolve the internet architecture without a clean-slate approach, focusing on distributed computing models.

Decisions and Action Items

SCION Component Analysis:
- The SCION authors (Nikola and team) will update their existing decomposition draft (zero-zero version) to incorporate feedback and the insights from the presentation.
- The SCION team will begin writing new drafts to document the specifications of the three core components (CP-PKI, Control Plane, Data Plane) in ID format, aiming to break them into smaller, more manageable pieces.
- The panrg chairs will schedule an interim meeting in mid-October to continue discussions on SCION, allowing sufficient time for the authors to prepare updated and new documents.
- Discussions will continue on the panrg mailing list.
Overlay Routing Problem Statement:
- Authors (Gongli and team) are encouraged to post their problem statement to the panrg mailing list to gauge broader interest and collect feedback.
Separation of Data Path and Data Flow Sublayers:
- Authors (Chris Casaei) are encouraged to continue the discussion on the panrg mailing list, focusing on the historical context, use cases, and reviewing existing transport layer protocols.
- Brian Carpenter will follow up offline with Chris Casaei regarding relevant RFCs from the IB stack evolution program (on path cooperation and wire images).

Next Steps

SCION: Authors to submit updated/new drafts for the component specifications. Interim meeting to be scheduled for mid-October to maintain momentum and discuss specifics.
Overlay Routing: Initiate discussion on the panrg mailing list to explore interest and potential next steps.
Data Path/Data Flow Separation: Continue discussion on the mailing list, provide historical context, explore further use cases, and begin developing example protocols.