Markdown Version | Session Recording

Session Date/Time: 15 May 2023 15:00

TAPS

Summary

The TAPS interim meeting focused on two main areas: resolving outstanding GitHub issues and pull requests on the TAPS documents, and discussing the status of TAPS implementations, future adoption, and the working group's path forward post-RFC publication. Several document issues were addressed, leading to clarifications and specific text changes. The discussion on implementations highlighted the need for API stability after RFC publication to drive broader adoption and explored various strategies for future work, including protocol mappings and the working group's long-term status.

Key Discussion Points

• Document Issue Resolution:

  • Multi-streaming: Clarified text regarding underlying transport connections supporting multi-streaming, explicitly mentioning SCTP as an example. (Pull Request merged)
  • API Events: Confirmed that API events related to multi-streaming are adequately described. (Pull Request merged)
  • Flow Control: Agreed to reference both minimum and maximum values for flow control mechanisms. (Pull Request merged)
  • System Policy Failures: Discussed the communication of policy violations. It was clarified that if such failures prevent connection establishment, they should be communicated to the application via an establishment error event when attempting to create a connection. (Text updated in Pull Request)
  • Non-Normative Language: Reaffirmed that the TAPS implementation document is strictly non-normative. A general statement to this effect was added to the document. The use of modal words like "may" and "should" is acceptable given this non-normative status.
  • Operations and Manageability Considerations: Decided against a dedicated section for "Operations and Management Considerations." Instead, relevant policy discussion will be integrated into existing architectural sections (e.g., Section 2 or Section 4) to avoid adding a standalone section for what is primarily an API document.
  • Modal Words Check: Michael volunteered to review the implementation document to ensure that any prescriptive statements implying mandatory behavior are consistently placed in the API document, not the non-normative implementation guide.
  • Nomenclature: Agreed on using "root node" as a standard term.
  • Multiplexed Streams / Cloning: Discussed that connection abstraction can map to multiplexed streams (e.g., Quick) or entire transport streams (e.g., TCP). While cloning explicitly requests multiplexing, it can also happen automatically unless specifically prohibited by a selection property. The need to verify consistency with the API document was noted.
  • Zero-RTT Data Max Length: Identified a potential issue where max_message_length for Zero-RTT data is a connection property, but its value needs to be known before connection establishment (e.g., on a pre-connection). This may require clarification or an API change to allow querying this property on a pre-connection. Tommy was assigned this issue.
  • Path Changes: It was determined that detailed descriptions of how transport protocols handle path changes (e.g., TCP socket recovering from route loss) are out of scope for the TAPS implementation document, as these are protocol-specific behaviors.
  • Specific Transport Protocol Considerations / Mappings: The use of protocols as examples without defined mappings was discussed. It was agreed to reference future work on mappings rather than defining them directly within the current documents.
  • Downgrade Avoidance: Agreed to add a reference to the security considerations section of the TAPS architecture document for guidance on downgrade avoidance.
  • IPv6 Default Address Selection: Decided that IPv6 default address selection is an internal operating system behavior and not relevant for detailed inclusion in the TAPS implementation document.

• Implementation Update and Future of TAPS:

  • Current Implementations: Tommy provided an update, noting Apple's Network Framework (Swift/C) and previous Python attempts. He emphasized that current implementations are based on earlier TAPS drafts and may not exactly match the latest API draft.
  • API Stability and RFC Alignment: A key point was that widespread TAPS implementation and adoption hinges on API stability, which will be achieved upon RFC finalization. Major API revisions in existing implementations (e.g., Apple's) are expected after RFC publication.
  • Implementation Roadmap: Tommy presented a phased roadmap: Standard RFC -> More Implementation -> Deployment/Release -> Application Adoption -> RFC Updates (based on deployment feedback). Martin Duke highlighted the potential need for significant RFC updates post-adoption, as seen in other IETF standards.
  • Mappings (Quick, HTTP): The need for TAPS mapping documents for Quick and HTTP was discussed. Tommy offered to work on a Quick mapping document and assist with HTTP mappings, seeking co-authors for diverse perspectives. Martin Duke questioned if the Quick Working Group would host such a document; Tommy suggested they would likely review it but not host the work, implying it would remain with TAPS or TSVWG. Philip emphasized the high value of HTTP mappings for non-browser applications.
  • Working Group Status Post-RFC Publication: Extensive discussion took place regarding the TAPS working group's future.
    • Proposals for Dormancy/Closure: Martin Duke and Aaron proposed going dormant after RFC publication, keeping the mailing list open for collaboration, and reactivating only if a critical mass of new topics emerges (e.g., from implementation feedback or mapping efforts).
    • Chair's View (Mohit): Preferred closing the working group after RFC publication but keeping the mailing list active. He noted that TSVWG could potentially handle small, related tasks or bootstrap new efforts.
    • Brian's Perspective: Advocated for keeping the group open but dormant with a future milestone, arguing that closing raises the activation energy for future work.
    • Martin's Focus on OS Support: Martin Duke emphasized that active targeting of OS communities (Linux, Microsoft, Android) for TAPS implementations is crucial for broader adoption. Tommy agreed that library-based, cross-platform implementations could alleviate some pressure on direct OS integration.
    • Outreach and Engagement: Aaron suggested hackathons as a useful forum for implementer support. The idea of an IETF blog post around RFC publication was raised.
  • Deployment and Hackathons: The group discussed how to foster deployment, including hackathons and potential Internet Society grants, emphasizing the need to identify implementers first.

Decisions and Action Items

• Decisions:
  • The TAPS implementation document is explicitly non-normative, and language has been adjusted accordingly.
  • No dedicated "Operations and Management Considerations" section will be added to the implementation document; relevant content will be integrated into architectural sections.
  • The TAPS working group will remain open until the core RFCs are published.
  • Post-RFC publication, the working group will likely go dormant or close, but the mailing list will remain open for continued discussion.
• Action Items:
  • Tommy: Revise the Quick mapping document and seek co-authors for Quick and HTTP mapping efforts. Continue addressing outstanding GitHub issues related to Zero-RTT data max length, handling marked connections, and message framework clarifications.
  • Michael: Review the implementation document to ensure consistency regarding prescriptive statements, ensuring all mandatory behaviors are defined in the API document.
  • Brian: Add a reference to the security considerations section of the TAPS architecture document concerning downgrade avoidance.
  • Chairs (Mohit/Gory): Plan an informal, public side meeting at a future IETF (e.g., Prague) to discuss hackathons, deployment strategies, and future TAPS work once RFCs are published.
  • Brian (with collaboration from Michael, Tommy, Maria): Draft an IETF blog post about TAPS, to be released around the time of RFC publication, to raise awareness.
  • Tommy, Michael, Maria: Coordinate outreach efforts targeting OS communities and other developers to promote TAPS adoption.

Next Steps

1. Complete Document Finalization: Address remaining GitHub issues and finalize the core TAPS documents for RFC publication.
2. Implementation Alignment: Encourage existing and new implementers to align their TAPS APIs with the published RFCs for consistency and stability.
3. Develop Protocol Mappings: Pursue the creation of TAPS mapping documents for key protocols such as Quick and HTTP, with Tommy leading the Quick mapping effort and seeking co-authors. This work may occur within the TAPS WG, TSVWG, or via other collaborative mechanisms.
4. Outreach and Promotion: Execute a coordinated outreach strategy, including an IETF blog post, to increase awareness and encourage adoption of TAPS by application and OS developers.
5. Foster Deployment: Explore mechanisms like hackathons and potential grant opportunities to support open-source implementers and encourage application adoption.
6. Monitor and Evolve: Continuously monitor implementation experiences and application adoption, anticipating the need for future RFC updates or new work items based on real-world feedback.
7. Informal Side Meeting: Organize an informal side meeting at an upcoming IETF to further discuss deployment, hackathon planning, and the direction of future TAPS-related efforts.