Markdown Version | Session Recording

Session Date/Time: 24 Mar 2022 12:00

panrg

Summary

The panrg session covered several key research areas, starting with administrative announcements and a discussion on integrating SCION-related work into the IRTF/IETF. Presentations included updates on the Path Properties draft, a novel "Sidecar" protocol for performance-enhancing proxies (PEPs) in encrypted transport scenarios like QUIC, wide-area network auto-scaling for cloud applications, a polynomial key-based architecture for source routing (Polka), and a proposal for trusted paths between endpoints and intermediate nodes using BNGs. A virtual interim meeting was decided upon to further discuss SCION engagement.

Key Discussion Points

• Administrative Announcements
  • Attendees reminded of the IRTF Note Well and encouraged to use the on-screen QR code for joining the microphone queue.
  • Gareth and Carsten volunteered to take minutes.
• SCION Engagement in IRTF/IETF
  • There was significant discussion in a prior side meeting (Tuesday) about how to integrate aspects of SCION, including work related to the Path Properties draft, into the IRTF/IETF.
  • Decision: A virtual interim meeting will be scheduled between the current IETF meeting and the next one in Philadelphia to brainstorm and discuss which parts of SCION work fit into panrg and how to engage with other IETF groups. Spencer Dawkins encouraged scheduling this early.
• Path Properties Draft Update (Cyril Hrubis)
  • Key Changes:
    • Replaced "host" with "endpoint," defined as the first or last node on a path. This was an iteration, having previously moved from "endpoint" to "host" and now back with a clearer definition.
    • Defined an "end-to-end path property" as a path property defined on both endpoints and the virtual link between them.
    • Clarified context-dependency of definitions (e.g., path notion in SCION for routing vs. data plane).
    • Added a new definition: "routing domain identifier," for path elements in the same administrative domain, using a common routing protocol (e.g., AS number, OSPF area ID).
    • Minor changes: Added a discussion section with links to mailing list and GitHub, rephrased recursive administrative domain definition, extended acknowledgements.
  • Discussion on "Endpoint" Definition:
    • Brian Trammell expressed satisfaction, finding it sufficient and necessary.
    • A poll on readiness for last call showed mixed results, with some not having read the latest draft or needing more time.
  • Discussion on "Routing Domain Identifier":
    • Deng Jian raised concerns about ambiguity with existing routing protocols (e.g., ISIS) that use "domain" differently.
    • Cyril clarified it's intended as a generic identifier for grouping nodes by ownership and communication protocol.
• Service Awareness (or "How to use PEPs in an Encrypted World") (Michael Scharf)
  • Problem: Performance-enhancing proxies (PEPs) are traditionally disliked due to ossification and lying to TCP. QUIC's encrypted headers make traditional PEPs impossible, hindering performance over challenging links (e.g., satellite, millimeter wave).
  • Proposed Solution: A "Sidecar" protocol designed solely for non-critical PEP functions.
    • Principles: Opt-in, non-criticality (main protocol doesn't rely on it for reliability), local host interface (API to a library), minimal changes to main protocols.
    • Functionality:
      • Data Plane: Manipulate queues, retransmit packets using hashes of transport headers (not full headers).
      • Control Plane: Local communication, ACKs via hashes (e.g., UDP options).
    • Example Use Cases:
      • Congestion control for fluctuating capacity links (e.g., millimeter wave): Sidecar proxy acts back to sender's sidecar, which notifies QUIC to increase congestion window.
      • Wi-Fi ACK aggregation: Access point sidecar acts on behalf of the client, reducing ACK traffic.
  • Open Questions/Research Areas: Overhead of hashes/ACKs, cumulative ACKs with hashes, discovery and negotiation of sidecar proxies, trust models, independence from main protocol.
  • Community Feedback: Positive reception, with Marcus Schöler from Ericsson noting similar ongoing work ("lightweight PEP," multi-domain congestion control) and interest in collaboration.
• Wide Area Networks for Cloud Auto-scaling (Berta Serracantó)
  • Scenario: Users (branch) connect via an SDN to applications in the cloud, managed by a cloud orchestrator.
  • Problem: Cloud auto-scaling (horizontal: more replicas; vertical: more resources per replica) doesn't typically inform the network, potentially leading to network bottlenecks.
  • Solution: Network Auto-scaling:
    • Horizontal: Dynamically changing overlay paths.
    • Vertical: Changing underlay path characteristics (e.g., bandwidth).
  • Prototyping: Uses public cloud, cn1-operator monitors app, cn1-reader pulls changes from external service registry, adapter notifies SD-WAN controller.
  • Results: Demonstrated successful traffic switching with minimal delay impact and proactive network adaptation matching cloud auto-scaling events, preventing performance degradation during traffic surges.
• Polka: Polynomial Key-Based Architecture for Source Routing (Rafael Salles)
  • Problem: Endpoints lack information about traffic paths. SDN table-based solutions suffer from high state configuration, scalability issues, and capacity limits in tables.
  • Solution: Polka provides strict source routing by encoding paths using polynomials, with changes only at the edge, requiring no state in the core network.
  • Requirements: Topology agnostic, fixed headers, programmable switches.
  • Mechanism: Uses three polynomials: Route ID (calculated via CRT), Node ID (for each core node), Path ID (for each core node's output port). Forwarding uses a mod operation between Route ID and Node ID.
  • Implementation: Aims to reuse CRC hardware for polynomial mod operations, P4 language, leveraging the Red Project (VM2, Tofino).
  • Protection: Achieved by encoding multiple paths within the same Route ID, allowing for re-encoding at a switch if a path segment fails.
• Trusted Path between Endpoints and Intermediate Nodes (Zhan Li)
  • Concept: Leverage the Broadband Network Gateway (BNG) as a trusted entity at the ingress of an enterprise network, maintaining per-connection state and trust relationships with users.
  • Goal: Enable endpoints to trust path-related information from the Ingress PE and allow the Ingress PE to trust user suggestions for path decisions (if verified by the BNG).
  • Mechanism:
    • Ingress PE -> Client: Ingress PE signs messages with its private key; client verifies with public key.
    • Client -> Ingress PE: BNG signs client suggestions with its private key, or uses an IPsec tunnel between BNG and Ingress PE to verify user traffic. This provides a trusted relationship facilitated by the BNG.

Decisions and Action Items

• Decision: A virtual interim meeting will be scheduled to discuss SCION work integration into the IRTF/IETF.
  • Action Item: Chairs to schedule the virtual interim between now and the Philadelphia meeting and announce logistics on the mailing list.
• Path Properties Draft:
  • Action Item: Further discussion and review of the Path Properties draft, particularly the "routing domain identifier" definition and overall readiness, is encouraged on the mailing list.

Next Steps

• SCION Engagement: Attendees interested in SCION-related work should look for announcements regarding the virtual interim meeting.
• Path Properties Draft: Review the latest version of the draft and provide comments on the mailing list, especially regarding the endpoint and routing domain identifier definitions.
• Service Awareness & PEPs: Continue the discussion on the panrg mailing list, particularly on discovery mechanisms and trust models. Individuals with similar work (e.g., Ericsson) are encouraged to connect with Michael Scharf.
• Future Meeting: panrg expects to hold another hybrid meeting in Philadelphia.