Markdown Version | Session Recording

Session Date/Time: 28 Jul 2022 14:00

QUIC Working Group Session - IETF 114

Summary

The QUIC working group met to discuss the progress of adopted documents and potential new work. Key discussions focused on Multipath QUIC (addressing single vs. multiple packet number spaces), ACK Frequency (frame types, ignore_ce, guidance), QUIC Load Balancer (readiness for WG Last Call), and new proposals for QUIC Timestamps and Multicast QUIC. Significant progress was reported on HTTP/3 and QPACK achieving RFC status.

Key Discussion Points

• QUIC Versions in Alt-SVC / SVCB Records: Martin Duke announced a draft for including QUIC versions in Alt-SVC and SVCB records will be significantly stripped down to focus on SVCB and will be proposed for adoption in the PROTOCOL WG, as ALPN has dissociated from QUIC versioning.
• HTTP/3 and QPACK RFCs: HTTP/3 and QPACK documents have officially become RFCs, marking a significant milestone.
• QUIC Multipath Extension:
  • A new draft version was published, incorporating a "unified proposal" to mandate Multiple Packet Number Spaces (MPS) when the multipath extension is negotiated. Single Packet Number Space (SPS) support is optional.
  • A new PATH_STATUS frame was introduced to signal path recommendations (standby or available).
  • The PATH_ABANDON frame can now be used to actively deny a new path, avoiding timeouts.
  • Discussion on SPS vs. MPS: While SPS initially appears simpler, implementation experience and analysis (e.g., for congestion control, RTT calculation, ECN handling) indicate MPS is significantly clearer and easier to implement correctly, despite MPS requiring changes to crypto for packet number decryption with Connection IDs. SPS makes delay calculation ambiguous and can lead to sub-optimal performance.
  • Hardware offload implications: MPS is generally seen as more amenable to future hardware offload due to less packet reordering across paths.
  • Zero-length Connection ID (CID) support: SPS supports zero-length CIDs. The need for zero-length CIDs with multipath, especially for client-side use cases like browsers, was questioned, as it introduces complexity.
• ACK Frequency Extension:
  • Frame Type Size: Discussion on whether the ACK_FREQUENCY frame type should be a one-byte code point for efficiency. Consensus leaned towards it being infrequently sent, so the current two-byte size is not a significant concern. Editors will make the final decision.
  • ignore_ce field: The ignore_ce field, restricted to ECT(0) packets, was discussed. There is no known active implementation or compelling use case. It was deemed too simplistic and potentially harmful, as ECN handling should be dictated by the congestion controller.
  • Guidance for Congestion Controllers: There was a request for normative guidance or recommendations on ACK_FREQUENCY settings for common congestion controllers (e.g., Reno, Cubic). This is challenging as optimal values vary by network conditions and use cases (e.g., data center vs. internet). The document is expected to provide mechanism, with strategies potentially in follow-up documents.
  • Loss Detection Delay: A problem was identified where a high ACK eliciting threshold can delay loss detection of single missing packets. A proposed solution is to communicate the sender's reordering threshold to the receiver, allowing the receiver to send an immediate ACK for missing packets within that threshold, accelerating loss detection.
• QUIC Load Balancer (QUIC-LB):
  • All Github issues for the QUIC-LB draft are closed, including a fix related to crypto review of the for-pass algorithm.
  • Implementation status: Two load-balancer side implementations exist, but no server-side implementations, preventing interop testing. Google is working on a server-side implementation.
• QUIC Timestamps (Proposed Work):
  • The draft (v10) proposes a simple TIMESTAMP frame with a transport option.
  • Use cases include: better congestion control on asymmetric paths, simplified RTT measurement in multipath, and improved delay-based congestion control (e.g., LEDBAT, Hystart).
  • Some implementation experience exists (PicoQUIC, LightSpeed).
  • Discussion on clock synchronization requirements, timestamp placement (all packets vs. ACK packets), and the need to clarify "one-way delay delta" vs. absolute delay.
  • Support from the real-time media community was noted for WebRTC-style congestion control.
• Multicast QUIC (Proposed Work):
  • Proposal for source-specific IP multicast, anchored to a unicast QUIC connection.
  • Shared symmetric keys for multicast packets, with separate unicast integrity packets to prevent spoofing.
  • Server controls client joining multicast sessions, client provides limits.
  • Multicast channels are for server-to-client data (server-initiated streams/datagrams).
  • Implementation work is ongoing (Google Quiche-based demo).
  • Challenges include strictly enforcing origin policy for web traffic in a browser context.
  • Interest noted for solving scaling problems in popular content delivery (e.g., sports, large downloads), especially for smart TVs using web APIs.
  • Discussion whether QUIC is the right layer or if a separate protocol is more appropriate; proponents argue for using QUIC's framing and security model.

Decisions and Action Items

• Multipath QUIC:
  • Decision: Multiple Packet Number Spaces (MPS) are mandatory if the Multipath extension is negotiated. Single Packet Number Space (SPS) support is optional. This decision is already merged into the draft.
  • Action Item: Chairs to discuss and potentially issue a consensus call on the adoption of MPS as mandatory.
• ACK Frequency:
  • Decision: The ignore_ce field will be removed from the draft due to lack of use cases and concerns about its simplistic nature.
  • Action Item: Editors will decide on the ACK_FREQUENCY frame type size (one-byte vs. two-byte).
  • Action Item: Continue to work on providing guidance and examples for using ACK_FREQUENCY with common congestion controllers.
  • Decision: The concept of communicating the reordering threshold to the receiver for improved loss detection will be pursued, likely replacing the ignore_order concept.
• QUIC Load Balancer:
  • Decision: The working group will wait for more implementation experience, specifically server-side implementations (e.g., Google Quiche), before initiating a Working Group Last Call.
• QUIC Timestamps:
  • Action Item: Chairs will discuss a follow-up on the mailing list and potentially issue an adoption call to gauge community interest and objections.
• QUIC Observability Tooling:
  • Action Item: Emil is encouraged to propose this work for a future QUIC agenda.

Next Steps

• Multipath QUIC: Seek further implementation experience and feedback, particularly regarding zero-length Connection ID use cases. Consider a hackathon for interop testing.
• ACK Frequency: Editors to finalize frame type size. Continue to refine guidance for congestion controllers. Incorporate the reordering threshold mechanism.
• QUIC Load Balancer: Implementers to continue work on server-side implementations to enable interop.
• QUIC Timestamps: Await mailing list discussion and potential adoption call from the chairs.
• Multicast QUIC: Continue discussions, including at the upcoming MBO and INDIAN sessions.
• General: Chairs will continue to monitor progress on Version Negotiation, v2, QUIC Grease Bit, and QUIC Careful Resume.