Hi Everyone, We have just published -05 version for multipath quic extension: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ <https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ > 05 version includes several modifications: (1) Transport parameter and frame type: - Introduce enable_multipath as a zero-length transport parameter(PR#227/#252) which MUST NOT be remembered(PR #240) - Replace 0xbaba by random numbers in ACK_MP / PATH_ABANDON / PATH_STATUS Frame type and error code(PR #254) (2) RTT computation and ACK_MP frames: - Guidance about RTT computation and ACK_MP scheduling(PR#217) (3) Connection ID: - Remove stale statement regarding zero-length CIDs(PR#225) - Suggest implementations don't use all CIDs unless rebinding is a non-concern(PR #231) - Remove must check available CIDs on both sides(PR #243) (4) Editorial guidance: - Fixed examples and figures (PR#191) - Remove text that contradicts to the WG's effort trying to prevent ossification (PR#203) - 0-RTT packets could be acknowledged by ACK_MP frames(PR#223), Clarify PATH_ABANDON and PATH_STATUS are ack-eliciting(PR #230) - Clarify ECN counts are per-path, not per connection (PR #228) - Clarify the effect on transport machinery at PATH_ABANDON + 3PTO(PR #234) - Describe situations when all path are stand-by(PR #238) - Clarify nonce usage(PR #245) - Editorial cralification around preferred_address(PR#256) - Switch to using 3xmaxPTO between key updates(PR#257) - Fix token ambiguity issues(PR#260) (5) Error code: - Use FRAME_ENCODING_ERROR instead of MP_PROTOCOL_VIOLATION while receives multipath-specific frames in a different packet type except 1-RTT packet(PR #247 / #236) And we add acknowledgement to Marten Seemann and Kazuho Oku for their thorough reviews and valuable contributions! (PR#249) Please feel free to discuss the new version! Here’s a link to the diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-quic-multipath-05 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-quic-multipath-04 > Best Regards, The mpquic-authors group ------------------------------------------------------------------ From:internet-drafts <[email protected]> Sent At:2023 Jul. 10 (Mon.) 19:59 To:LIU Yanmei <[email protected]>; Yunfei <[email protected]>; Christian Huitema <[email protected]>; Mirja Kuehlewind <[email protected]>; Olivier Bonaventure <[email protected]>; Quentin De Coninck <[email protected]>; quic-chairs <[email protected]> Subject:New Version Notification for draft-ietf-quic-multipath-05.txt A new version of I-D, draft-ietf-quic-multipath-05.txt has been successfully submitted by Yanmei Liu and posted to the IETF repository. Name: draft-ietf-quic-multipath Revision: 05 Title: Multipath Extension for QUIC Document date: 2023-07-10 Group: quic Pages: 30 URL: https://www.ietf.org/archive/id/draft-ietf-quic-multipath-05.txt <https://www.ietf.org/archive/id/draft-ietf-quic-multipath-05.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ <https://datatracker.ietf.org/doc/draft-ietf-quic-multipath/ > Html: https://www.ietf.org/archive/id/draft-ietf-quic-multipath-05.html <https://www.ietf.org/archive/id/draft-ietf-quic-multipath-05.html > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath <https://datatracker.ietf.org/doc/html/draft-ietf-quic-multipath > Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-quic-multipath-05 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-quic-multipath-05 > Abstract: This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list ([email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/quic/ <https://mailarchive.ietf.org/arch/browse/quic/ >. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-lmbdhk-quic-multipath <https://github.com/mirjak/draft-lmbdhk-quic-multipath >. The IETF Secretariat
