Markdown Version | Session Recording

Session Date/Time: 17 May 2022 15:00

TAPS

Summary

The TAPS Working Group held an interim meeting to discuss the status of the implementation draft, ongoing reviews, and outstanding issues and Pull Requests (PRs). Key discussions included clarification of terminology, handling of stream IDs for multi-streaming protocols, and a significant proposal for improving multicast API definitions. The Working Group decided not to hold a session at IETF 114 and will instead continue with interim meetings.

Key Discussion Points

• IETF 114 Meeting Schedule: There was a check-in regarding the frequency of TAPS WG meetings at IETF plenaries. The working group's sense was to meet every other IETF meeting. As such, there will not be a TAPS WG session at IETF 114 in Philadelphia. Interim meetings will continue to drive progress.
• Implementation Draft Reviews:
  • The chairs noted that Torben's comments are still in the queue, and Christian Amzus was pinged for his pending review from IETF 113.
  • Discussion on general process for incorporating comments into PRs, with authors encouraged to make changes based on editor/WG feedback.
• PR on connection.clone() Scope Clarification:
  • A PR was opened to clarify the scope of connection.clone(), focusing on cleaning up and clarifying existing text.
  • The author indicated a conservative approach to PRs, with more in queue. General agreement that the changes are beneficial.
• PR on "Connection Attempt" Terminology:
  • An issue highlighted confusion regarding the term "entire connection attempt" vs. "connection attempt" referring to a leaf node action.
  • A PR was proposed to clarify this, suggesting "connection establishment" or "connection establishment tree" for the overall process, and referring to "leaf node" for individual attempts.
  • Decision: Clarify that "when a single leaf node becomes ready to use, then the entire connection establishment tree is considered ready." The PR will be merged.
• Issue on "Racing" Terminology (Section 4.1):
  • Concern was raised that the term "racing" in the draft, especially in early sections, could be confusing from a Happy Eyeballs perspective where it typically implies simultaneous starts. TAPS defines racing more broadly (simultaneous, staggered, failover).
  • The suggestion was to either move the section defining racing (4.3) earlier or, more practically, to clarify the scope of racing in the introduction to Section 4.
  • The architecture draft provides a clearer definition, but a forward reference or explicit mention in the implementation draft would be beneficial.
  • Action Item: Brian to clarify the concept of racing in the introduction to Section 4 of the implementation draft, potentially mentioning the default style of staggered racing.
• PR on Stream IDs for Multi-Streaming:
  • The discussion revolved around enabling applications to explicitly specify stream IDs for multi-streaming protocols (e.g., HTTP/3 over QUIC, IPFIX over SCTP).
  • Current PR proposes adding an optional stream_id parameter to connection.clone().
  • Concerns raised:
    • Assumption of integer semantics for stream IDs (though common).
    • Potential for ambiguity with existing ConnectionGroup for multi-streaming and how stream_id interacts with it (e.g., if a stream ID is already taken).
    • It was noted that if an application cares about stream IDs, it will likely manage them comprehensively.
  • Decision: The WG agreed that the right solution is a generalized mechanism for passing protocol-dependent parameters to initiate() and clone(). This allows flexibility (e.g., sctp.stream_id, quick.unidirectional_stream).
  • Action Item: Michael to update the PR to implement a generalized mechanism for passing protocol-dependent parameters to initiate() and clone().
• PR on Non-Negative Values:
  • A PR proposing to ensure that all timeout and similar numeric values are specified as "non-negative" was quickly reviewed.
  • Decision: This PR was deemed a "no-brainer" and will be merged.
• PR on Multicast API Definition:
  • Colin presented a PR to address long-standing issues with multicast support.
  • Current draft definition is "odd" as it uses the local endpoint for the multicast group and lacks explicit specification for the local interface. It also has challenges with rendezvous and source filtering (SSM).
  • Colin's proposal: Treat the local endpoint as the local interface address/port and the remote as the multicast group for initiate(). For listen(), the local is the multicast group and the remote is the sender.
  • Challenge: Source-Specific Multicast (SSM) requires a third address (source address) which is not readily available in the current local/remote endpoint structure.
  • Proposed solution: Introduce an explicit group_id parameter within the remote object or a more generalized approach for protocol-specific multicast parameters.
  • General agreement that the proposal is an improvement.
  • Action Item: Colin to flesh out his multicast PR with concrete examples, exploring the impact of the proposed changes.
• Outstanding Issues:
  • Brian will conduct another review pass on his assigned implementation draft issues, specifically regarding privacy considerations and protocol stack terminology, to ensure they are closed or addressed.
  • Tom volunteered to take an unassigned issue on the API draft.

Decisions and Action Items

• Decision: The TAPS Working Group will not hold a session at IETF 114 in Philadelphia.
• Decision: The PR clarifying "connection attempt" terminology will be merged.
• Action Item: Brian to clarify "racing" terminology in the introduction to Section 4 of the implementation draft.
• Decision: Adopt a generalized mechanism for passing protocol-dependent parameters (e.g., stream ID) to initiate() and clone() calls.
• Action Item: Michael to update his PR to implement the generalized mechanism for protocol-dependent parameters for initiate() and clone().
• Decision: The PR making numeric values non-negative will be merged.
• Action Item: Colin to flesh out his multicast PR with concrete examples, demonstrating the proposed API changes.
• Action Item: Brian to perform a review pass on his outstanding assigned issues for the implementation draft to verify their status.
• Action Item: Tom to address the unassigned issue on the API draft (Issue 2012).

Next Steps

• The Chairs will schedule another interim meeting in June via a doodle poll with a shorter expiration time.
• Participants are encouraged to review the outstanding issues and PRs, especially on the implementation draft, and work towards their resolution before the next interim.
• Continue work on issues for the API draft.