Markdown Version | Session Recording

Session Date/Time: 26 Jul 2022 14:00

alto

Summary

The ALTO Working Group session provided updates on existing charter items, discussed pending technical issues, and explored new areas of work. Key discussions focused on ALTO O&M support, the ALTO over New Transport draft, and a comprehensive update on ALTO deployments and codebases. Additionally, non-charter items proposing ALTO as a Network Exposure Function and an architecture for computing power optical networks were presented. The session saw significant technical debate, especially regarding the new transport mechanisms and the scope of ALTO's O&M.

Key Discussion Points

• Working Group Status: Three new RFCs published, two existing drafts awaiting editor action. ALTO O&M and ALTO over New Transport adopted as working group drafts. Early reviews for ALTO over New Transport received from HTTP experts.
• ALTO O&M Support (Draft):
  • Data Type Deployment (IANA Registries): Discussed two models: enumerations (guaranteed consistency, hard to extend) vs. identities (easy to extend, less consistency control). Seeking working group consensus.
  • Server-Level Management: Questioned whether to include lower-level HTTP configurations (e.g., cache-control, retry-after) in the Yang module.
  • Logging and Fault Management: Proposed adding success/failure records for configuration updates, configuration type support, and data source connection status. Additional useful metrics are sought.
  • Client-Side O&M: Identified a need for client-side configuration (accessing services, query parameters, transport control). Proposed adding a new top-level container for ALTO client or treating ALTO client as an ALTO data source listener.
  • Server-to-Server Communication (Multi-domain): Explored ALTO server acting as a data source for another ALTO server. Two options: extend ALTO for direct data collection or use other southbound protocols (currently no standards). Also highlighted the challenge of cross-domain path discovery.
  • Unifying Data Sources (Yang Model): Discussed the complexity of unifying data models for source-bound protocol parameters, query expressions, and data collection mechanisms (polling, pub-sub, on-demand query). Strong feedback suggested this is a very complex issue, potentially outside ALTO's core scope of exposing (not collecting) data.
• ALTO over New Transport (HTTP/2, /3) (Draft):
  • Design Rationale: Aims to replace Server-Sent Events (SSE) functions (incremental updates, stop/start signaling) using HTTP/2 or /3 while adhering to RFC 7285 and RESTful API principles.
  • Client Long Pull: Proposed allowing clients to request the next_sequence_number to implement a long-poll mechanism, a minor change to the current pull model.
  • Server Put for Server Push: Proposed replacing HTTP/2's Push Promise (considered an anti-pattern by some) with a standard HTTP PUT method from server to client. This makes the client conceptually a stateful machine.
  • Dependency Ordering of Resources: Discussed how ALTO servers should submit interdependent resources to the HTTP layer (e.g., Network Map -> Cost Map). The current draft recommends submitting resources in a Directed Acyclic Graph (DAG) order to prevent performance degradation from out-of-order delivery by the HTTP transport.
  • Concurrency Control Specification: Debated whether ALTO should specify HTTP/2/3 specific concurrency control or leave it to operational configuration, or specify generic requirements.
  • Example Formats: Sought guidance on whether examples should be in HTTP/1.1 or HTTP/2 format, with a preference for HTTP/1.1 with pseudo-annotations for clarity.
  • Media Type Finalization: Proposed finalizing the format=input media type.
  • Architectural Scope Discussion: Martin Duke questioned whether a separate HTTP/2/3 document is needed, or if the "naive" approach of simply putting existing ALTO requests into HTTP/2 streams is sufficient. He suggested considering if the draft is effectively redesigning SSE in a version-agnostic way, and to benchmark proposed solutions against simpler approaches.
• ALTO Codebases and Deployment:
  • CERN Deployment: Implemented ALTO to provide bandwidth usage control on physical links for the File Transfer Service (FTS). The network optimizer acts as an ALTO client, querying ALTO for link usage and optimizing data transfers. A demo was given at the hackathon, and a paper will be presented at Sigcomm Night.
  • Telefonica Deployment: Integrating ALTO to expose network capabilities to their CDN. ALTO provides topological information (e.g., hop counts) and will include performance metrics. The deployment is moving from lab to pre-production to production, facing challenges with multi-vendor environments, complex IGPs, and security. No issues found with core ALTO specification, but passing protocol information to ALTO was complex.
  • Pacific Research Platform (PRP) Deployment: ALTO is being deployed in science networks (e.g., ESnet, PRP) to provide network visibility for Edge Cloud and 5G applications (Holodeck, vehicle networks, metaverse).
  • MPTCP/MPQUIC Optimization: Demonstrated ALTO's role in helping SDN controllers allocate MPQUIC/MPTCP packets to suitable paths, resulting in higher throughput, especially in lossy networks.
• Non-Charter Items (Future Work):
  • ALTO as Network Exposure Function (NEF): Proposed using ALTO as an NEF to expose network capabilities to applications, aligning with industry trends (3GPP NEF, MEC APIs). This includes existing ALTO capabilities (topology, cost) and new proposals like "service edge" (compute capabilities) and "service functions" (characterizing paths to service function instances/chains). This is intended for future chartering.
  • Architecture of Computing Power Optical Network: A draft outlining an architecture that combines computing resources with optical networks to manage and optimize data storage, computing, and transmission for cloud/AI applications.

Decisions and Action Items

• ALTO O&M (Question 6 - Unifying Data Sources): Decided to defer standardization of how to unify data sources in the Yang model, focusing instead on implementation details initially, given its complexity and potential scope creep beyond ALTO's data exposure role.
• ALTO O&M (Questions 1-3): Authors to make decisions and submit a new version of the O&M document as soon as possible.
• ALTO over New Transport (Discuss 3 - Concurrency Control): Martin Duke recommended specifying generic requirements for concurrency control (e.g., "send enough pushes," "enough streams") rather than deferring entirely to operational configuration. Richard agreed this should be a requirement.

Next Steps

• ALTO O&M Support:
  • Authors will continue to collect feedback for questions 4-6.
  • Test the Yang model in real implementations.
  • Reach agreements on questions 1-6 and completely revise the document before the next IETF meeting.
  • Push for ALTO O&M Yang model deployment in Open Alto GitHub by March 2023.
• ALTO over New Transport:
  • Richard to consider Martin Duke's advice: "free ourselves of what we're to do for a minute," think about the problem being solved (HTTP versions vs. replacing/supplementing RFC 8895), and experiment with existing code for server push vs. simpler HTTP/2 approaches.
  • Huddle offline with HTTP experts for further discussion.
  • Finalize media type format=input.
• ALTO Codebases and Deployment:
  • CERN: Continue work towards production data. New demo planned for next hackathon.
  • Telefonica: Continue working towards summer production deployment, collect scalability data for IETF 115. Focus on integrating performance metrics and automating client-side processes.
  • PRP: Demo planned for next hackathon and SC22 (November).
• Non-Charter Items:
  • ALTO as NEF & Service Edge/Function Drafts: Continue developing these drafts for future ALTO chartering and to complement work in other IETF working groups. Prepare updated versions for IETF 115.