Markdown Version | Session Recording

Session Date/Time: 08 Nov 2022 09:30

coinrg

Summary

The coinrg session featured three research presentations covering practical aspects of in-network classification, the interplay between the end-to-end principle and in-network computing, and the observed impact of Distributed Ledger Technologies (DLTs) on provider networks. A new draft proposing a system for alternative secure elements in the internet was also presented. Discussions included resource constraints in programmable data planes, challenges in designing end-to-end compliant transport protocols for in-network compute, DLT communication patterns, and the role of secure elements in enhancing network trust. The chairs outlined plans for an interim meeting to review existing drafts and future directions.

Key Discussion Points

• Practical In-Network Classification (Yiming Chen, University of Oxford)

  • Research Evolution: Presented three years of research, starting with "Easy" (2019) demonstrating ML model mapping to programmable network devices (P4, BME2, NetFPGA), evolving to an "Automating Network Machine Learning" framework for end-to-end automatic deployment.
  • Framework Capabilities: Supports over 12 ML models, generates P4 and P4 runtime files, auto-tests on Python/software switches, and deploys to hardware (Tofino, Papi, Raspberry Pi, Nvidia Spectrum, FPGA).
  • Challenges & Solutions:
    • Limited Stages: Solved by parallelizing independent functions (e.g., parallel feature and tree tables) and using lookup tables.
    • Limited Memory: Addressed with efficient mapping solutions (lookup-based vs. tree-like) and advanced table types (LPM, ternary, range match) with "smart rope" to reduce entries.
    • Coexistence with Network Functions: Demonstrated co-existence with L2/L3 switch programs (Intel Tofino switch.p4), consuming 5-65% of resources with minimal latency impact.
  • Trade-offs: Hyper-parameter selection for features, trees, and depth is crucial due to resource constraints. Support for features varies based on header format (custom vs. ASCII) and co-deployment.
  • Deployment & Updates: Runtime retraining and updates are handled via digest and shadow updates, allowing non-disruptive model modifications without changing the P4 program.
  • Performance: Achieves full line rate on commodity switches (e.g., 64-port Tofino) with sub-microsecond latency, without recirculation/resubmission or control plane dependencies.
  • Hybrid Deployment: For high accuracy/large models, a small model is deployed in-network, and a large model acts as a backend server. Decision confidence determines if packets are processed locally or forwarded to the backend.
  • Discussion: Questions arose about specific resource constraints (stages, memory, parser limitations for header fields, lack of floating-point/multiplication support) and handling new traffic features/data (currently not addressed for "feature" data but generally using unsupervised learning for retraining).

• The End-to-End Transport Layer (Ike Wiermann, Technical University of Munich)

  • Context: Networks are evolving from "dumb pipes" to "smarter networks" with in-network computation (Coin), challenging traditional transport layer assumptions and the end-to-end principle.
  • End-to-End Principle: Reaffirmed its core tenet (functions implemented completely and correctly at endpoints) but also noted the allowance for network-provided "incomplete versions" as performance enhancements.
  • Coin Element Definition: Generalized Coin elements as any capability between endpoints, distinguishing between "on-path" and "off-path" computations.
  • Functionality Types:
    • End-to-End Function Internal Computation: Incomplete or tweaked versions of original end-to-end functions, deemed potentially end-to-end compliant.
    • End-to-End Function External Computation: New functionalities not part of the original end-to-end function, viewed as more akin to edge/cloud computing and potentially problematic for end-to-end compliance.
  • Design Principles for Coin:
    1. Placement Location: Adhere to original requirements, enrich functionality, optimize functional complexity against key communication requirements (e.g., latency).
    2. Transparency: Insert Coin functionality in full transparency to endpoints to avoid unexpected issues (e.g., like performance-enhancing proxies).
  • Transport Protocol Considerations: Focused on addressing, flow granularity, and collective communication.
    • Addressing: Explored implicit integration (strategic placement) vs. explicit steering mechanisms (tagging packets). Raised questions about exact location vs. constraint-based specification and instance affinity.
    • Existing Solutions: Mentioned source routing, service function chaining (SFC), and information-centric networking (ICN) as potentially applicable.
  • Provocative Questions: Discussed whether a single global protocol is needed for Coin's E2E problems, or if specialized protocols for limited domains, possibly with standardized interaction, are preferable. Also, questioned if the end-to-end principle could be "bent" in controlled, limited domains (e.g., industrial networks).
  • Discussion:
    • Dirk Trossen suggested that defining a Coin protocol prematurely without knowing specific use cases might be too hard and that the end-to-end principle might not apply to all Coin goals (e.g., data flow systems).
    • Olaf noted robustness and innovation protection as advantages of the E2E principle and raised concerns about interdependencies/side effects of partial functions and the complexity of requiring applications to have network knowledge for addressing.
    • Andy Reid emphasized the central role of transparency and addressing, suggesting further development on these ideas.
    • Lars Eggert found the initial E2E framing very useful and encouraged focusing on "low-hanging fruit" and "minimal changes" to existing protocols for practical, near-term deployment, especially for IETF-related work.
    • Eric Norman highlighted the importance of considering state in the network and state-sharing aspects related to robustness, also inquiring about the spectrum of research possibilities from minor tweaks to entirely new paradigms.

• Insights on the Impact of DLTs in Provider Networks (David R. W., Technical University of Munich)

  • Background: Dlts (e.g., Ethereum, Bitcoin) build on distributed hash tables and consensus mechanisms over P2P networks (UDP/TCP/QUIC).
  • DLT Service Interactions: Client transactions, miner block commits, and client reads.
  • Key Mechanism: Atomic broadcast, randomized over receivers to avoid collusion and ensure ledger distribution, deals with scale and permissionless nature.
  • Communication Patterns: Discovery (UDP ping/pong, query for more nodes) and Pool Establishment (TCP, TLS, capability exchange for upper-layer protocols).
  • Challenges: High cost for pool maintenance (continuous reachability, discovery, state exchange), resilience (failing nodes cause latency), unicast replication overhead, and IP address privacy exposure.
  • Experimental Results: Measured pool establishment time, showing a log-normal/power-law distribution, indicating significant delays. Analyzed attempts, reachability, and success rates for outgoing/incoming requests. Identified failures in TCP socket initialization, TLS negotiation, and capability checkpoints.
  • Proposed Network-Level Assistance (Coin):
    • Service-centric abstraction for miners (service instances).
    • Encoded constraints for improved reachability.
    • Replacing randomized unicast with network-built multicast capabilities for fixed peer groups.
    • Using IP multicast to ensure randomized peer selection for requests.
  • Discussion: No questions were explicitly captured during the Q&A for this presentation.

• An IOC (I/O Computing) System for Alternative Secure Elements (Pascal Sarrus)

  • Secure Elements (SEs): Tamper-resistant microcontrollers with embedded software (e.g., bank cards, SIM cards, passports). Feature modest CPU/memory but strong crypto processors (EAL 6+). Communicate via ISO 7816 (small APDU packets) or other interfaces. Open programming (Java Card).
  • Global Platform: A standardized framework for secure software management (list, delete, upload applications).
  • Goal: Connect SEs to the internet to deploy online cryptographic resources, identified by URIs, offering a higher level of trust.
  • Architecture Requirements: Additional processors for network interface/TCP/IP, Global Platform for on-demand applications, TLS for user/service interface, SE naming, and attestation procedures.
  • URI Naming: SEs identified by a server name (SCL) with an associated pre-shared key. Access via TLS secured command-line interface.
  • Administration Plane (ROCKS): Uses TLS with client/server certificates (PKI) to transport ISO 7816 packets, supporting Global Platform for application management (download/delete/upload).
  • Service Plane (TLS for Secure Elements): A specific TLS server profile using pre-shared keys. The server name is embedded in the SE's "answer to request" (historical bytes). A client-facing server routes incoming/outgoing packets to the TLS backend server.
  • On-Demand Application Attestation: Application provider downloads app and binds SE name. The SE creates a public/private key pair. Provider delivers public key, certificate, and pre-shared key to the user. User connects via TLS, verifies certificate, and confirms SE knowledge of both the unshared secret and public key, ensuring no man-in-the-middle. User can then modify the pre-shared key.
  • Implementation Status: Code available on GitHub for TLS/SC for Java Card (compatible with v3.04/3.05 APIs). Server code (V5) supports Windows/Unix/Raspberry Pi and uses PC/SC for SE communication. No patents, all open-source.
  • Connection to Coin: When cryptographic procedures are needed within the network (e.g., for blockchain issues, as discussed earlier), secure elements provide a trustworthy, open, and provable way to store keys and perform cryptographic computations. They offer a strong root of trust (certified EAL levels) at scale (billions deployed annually) for in-network secure procedures.

Decisions and Action Items

• Draft Review Interim: The chairs plan to hold an interim meeting, likely in January, to review the existing list of publications, drafts (including expired ones for potential re-kindling), and the newly presented draft by Pascal Sarrus, to discuss which documents should be considered for working group adoption.
• Continued Discussion: Specific discussions from Ike Wiermann's presentation (e.g., about problem framing, robustness, application knowledge, low-hanging fruit, and state in the network) were suggested for further offline or list-based engagement.

Next Steps

• Interim Meeting: An interim meeting is planned for January to review current and expired drafts, focusing on potential working group adoption and future directions for the research group.
• IETF 116: The coinrg will most likely hold a session at IETF 116 in Japan in March.
• Community Engagement: Continue monitoring discussions related to the 5G NetApp Lab proposal and relevant papers from conferences like HotNets.
• Mailing List: Attendees and interested parties are encouraged to subscribe to the mailing list for ongoing conversation and to peruse archives for materials.