From d1d6c6e4cdedd32e21e59f8653ba72d1881986ab Mon Sep 17 00:00:00 2001 From: Yanmei-Liu Date: Sun, 17 Mar 2024 18:14:44 +0800 Subject: [PATCH 01/33] [+] Clarify that endpoints use the same Path ID for one specific path in both directions. --- draft-ietf-quic-multipath.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index cffe2ca5..3e87eaf2 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -310,6 +310,14 @@ Each endpoint associates a Receiver Packet Number space to each Path Identifier that it provides to the peer. Each endpoint associates a Sender Packet Number space to each Path Identifier received from the peer. +Endpoints use the same Path ID for one specific path in both directions. +For a client-initiated path, the client decides which Path ID used for the new path, +and it picks one of the server allocated CID with the specified Path ID. +The client SHOULD choose a new Path ID which is not used in previous paths, +and both endpoints have already issued unused CIDs with the new Path ID. +The client then initializes a new path with a packet containing PATH_CHALLENGE and +the Destination Connection ID with the chosen Path ID. + The Path Identifier associated with the Destination Connection ID is used to construct the packet protection nonce defined in {#multipath-aead}. From a20fadb8afe623d0ef6d2a26325b9d62231893bd Mon Sep 17 00:00:00 2001 From: Yanmei-Liu Date: Sun, 17 Mar 2024 21:16:26 +0800 Subject: [PATCH 02/33] [+] specify PATH_ABANDON cause all the CID allocated for the Path ID to be retired. --- draft-ietf-quic-multipath.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 3e87eaf2..ba67db5c 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -312,11 +312,16 @@ to each Path Identifier received from the peer. Endpoints use the same Path ID for one specific path in both directions. For a client-initiated path, the client decides which Path ID used for the new path, -and it picks one of the server allocated CID with the specified Path ID. +it picks one of the server allocated CID with the specified Path ID. +Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, +it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. + The client SHOULD choose a new Path ID which is not used in previous paths, and both endpoints have already issued unused CIDs with the new Path ID. -The client then initializes a new path with a packet containing PATH_CHALLENGE and -the Destination Connection ID with the chosen Path ID. +If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID +for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can +choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing +the corresponding Path ID arrives. The Path Identifier associated with the Destination Connection ID is used to construct the packet protection nonce defined in {#multipath-aead}. @@ -480,6 +485,14 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). +PATH_ABANDON frame causes all the CID allocated for the specified Path ID to be retired. + +There is a special case that endpoints SHOULD send PATH_ABANDON frame: +When a client create a new path, it chooses a new Path ID and sends a Path Challenge +with a chosen Connection ID of that path. If it doesn’t receive any PATH_RESPONSE, +it SHOULD consider the Path ID as consumed, and also SHOULD send a PATH_ABANDON frame +to inform the server that the Path ID can’t be used in the future. + Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a CONNECTION_CLOSE ({{Section 10.2 of QUIC-TRANSPORT}}) or a Stateless From 34594ef7f005cb8ff67a2a3a4870594d329096fd Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Sun, 17 Mar 2024 21:23:49 +0800 Subject: [PATCH 03/33] Update draft-ietf-quic-multipath.md Co-authored-by: Marten Seemann --- draft-ietf-quic-multipath.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index ba67db5c..d52409e2 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -316,8 +316,7 @@ it picks one of the server allocated CID with the specified Path ID. Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. -The client SHOULD choose a new Path ID which is not used in previous paths, -and both endpoints have already issued unused CIDs with the new Path ID. +The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing From 4926786f10fdb8e36d48bcf88c1895b7ccd90adf Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Sun, 17 Mar 2024 21:24:38 +0800 Subject: [PATCH 04/33] Update draft-ietf-quic-multipath.md Co-authored-by: Marten Seemann --- draft-ietf-quic-multipath.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index d52409e2..f599c343 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -486,10 +486,7 @@ the only way for an endhost to detect path closure (see PATH_ABANDON frame causes all the CID allocated for the specified Path ID to be retired. -There is a special case that endpoints SHOULD send PATH_ABANDON frame: -When a client create a new path, it chooses a new Path ID and sends a Path Challenge -with a chosen Connection ID of that path. If it doesn’t receive any PATH_RESPONSE, -it SHOULD consider the Path ID as consumed, and also SHOULD send a PATH_ABANDON frame +When path validation of a new path fails, the client MUST consider the Path ID as consumed, and MUST abandon the path by sending a PATH_ABANDON frame. to inform the server that the Path ID can’t be used in the future. Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still From cab06c3d635245d2b2cf71407cef7dd515801cad Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Wed, 20 Mar 2024 08:52:25 +0800 Subject: [PATCH 05/33] Update draft-ietf-quic-multipath.md Co-authored-by: Quentin De Coninck --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index f599c343..c7ae1226 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -318,7 +318,7 @@ it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID -for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can +for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing the corresponding Path ID arrives. From e28e10e2658ce1a3f4ffe24e33f2340b53fd1584 Mon Sep 17 00:00:00 2001 From: Yanmei-Liu Date: Sun, 17 Mar 2024 18:14:44 +0800 Subject: [PATCH 06/33] [+] Clarify that endpoints use the same Path ID for one specific path in both directions. --- draft-ietf-quic-multipath.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 96a49222..f8fb3676 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -314,6 +314,14 @@ Each endpoint associates a Receiver Packet Number space to each Path Identifier that it provides to the peer. Each endpoint associates a Sender Packet Number space to each Path Identifier received from the peer. +Endpoints use the same Path ID for one specific path in both directions. +For a client-initiated path, the client decides which Path ID used for the new path, +and it picks one of the server allocated CID with the specified Path ID. +The client SHOULD choose a new Path ID which is not used in previous paths, +and both endpoints have already issued unused CIDs with the new Path ID. +The client then initializes a new path with a packet containing PATH_CHALLENGE and +the Destination Connection ID with the chosen Path ID. + The Path Identifier associated with the Destination Connection ID is used to construct the packet protection nonce defined in {#multipath-aead}. From b74c5ae24e123e243e7dd21ada49cb424be99943 Mon Sep 17 00:00:00 2001 From: Yanmei-Liu Date: Sun, 17 Mar 2024 21:16:26 +0800 Subject: [PATCH 07/33] [+] specify PATH_ABANDON cause all the CID allocated for the Path ID to be retired. --- draft-ietf-quic-multipath.md | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index f8fb3676..44e564cd 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -316,11 +316,16 @@ to each Path Identifier received from the peer. Endpoints use the same Path ID for one specific path in both directions. For a client-initiated path, the client decides which Path ID used for the new path, -and it picks one of the server allocated CID with the specified Path ID. +it picks one of the server allocated CID with the specified Path ID. +Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, +it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. + The client SHOULD choose a new Path ID which is not used in previous paths, and both endpoints have already issued unused CIDs with the new Path ID. -The client then initializes a new path with a packet containing PATH_CHALLENGE and -the Destination Connection ID with the chosen Path ID. +If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID +for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can +choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing +the corresponding Path ID arrives. The Path Identifier associated with the Destination Connection ID is used to construct the packet protection nonce defined in {#multipath-aead}. @@ -484,6 +489,14 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). +PATH_ABANDON frame causes all the CID allocated for the specified Path ID to be retired. + +There is a special case that endpoints SHOULD send PATH_ABANDON frame: +When a client create a new path, it chooses a new Path ID and sends a Path Challenge +with a chosen Connection ID of that path. If it doesn’t receive any PATH_RESPONSE, +it SHOULD consider the Path ID as consumed, and also SHOULD send a PATH_ABANDON frame +to inform the server that the Path ID can’t be used in the future. + Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a CONNECTION_CLOSE ({{Section 10.2 of QUIC-TRANSPORT}}) or a Stateless From fdbb95a4573fe95f11f861aa41d71b0390ac8763 Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Sun, 17 Mar 2024 21:23:49 +0800 Subject: [PATCH 08/33] Update draft-ietf-quic-multipath.md Co-authored-by: Marten Seemann --- draft-ietf-quic-multipath.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 44e564cd..90eec1a4 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -320,8 +320,7 @@ it picks one of the server allocated CID with the specified Path ID. Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. -The client SHOULD choose a new Path ID which is not used in previous paths, -and both endpoints have already issued unused CIDs with the new Path ID. +The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing From 982c03c88d3f4c195f2bba6afb5a5bd22caca227 Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Sun, 17 Mar 2024 21:24:38 +0800 Subject: [PATCH 09/33] Update draft-ietf-quic-multipath.md Co-authored-by: Marten Seemann --- draft-ietf-quic-multipath.md | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 90eec1a4..48934e4b 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -490,10 +490,7 @@ the only way for an endhost to detect path closure (see PATH_ABANDON frame causes all the CID allocated for the specified Path ID to be retired. -There is a special case that endpoints SHOULD send PATH_ABANDON frame: -When a client create a new path, it chooses a new Path ID and sends a Path Challenge -with a chosen Connection ID of that path. If it doesn’t receive any PATH_RESPONSE, -it SHOULD consider the Path ID as consumed, and also SHOULD send a PATH_ABANDON frame +When path validation of a new path fails, the client MUST consider the Path ID as consumed, and MUST abandon the path by sending a PATH_ABANDON frame. to inform the server that the Path ID can’t be used in the future. Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still From aea4f81c5230d2fc4ae1dee2d332144839d7d949 Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Wed, 20 Mar 2024 08:52:25 +0800 Subject: [PATCH 10/33] Update draft-ietf-quic-multipath.md Co-authored-by: Quentin De Coninck --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 48934e4b..df302c7f 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -322,7 +322,7 @@ it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID -for the specify path, it MAY choose to ignore the PATH_CHALLENGE, or it can +for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing the corresponding Path ID arrives. From 0cdd5597c4d3b9245ef421418da5a28730d30a6c Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Mon, 1 Apr 2024 11:52:54 +0800 Subject: [PATCH 11/33] Update draft-ietf-quic-multipath.md Co-authored-by: Quentin De Coninck --- draft-ietf-quic-multipath.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index df302c7f..abf54fcb 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -323,8 +323,8 @@ it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can -choose to send PATH_RESPONSE until it receives the MP_NEW_CONNECTION_ID containing -the corresponding Path ID arrives. +choose to send the PATH_RESPONSE frame upon reception of a +MP_NEW_CONNECTION_ID frame containing the corresponding Path ID. The Path Identifier associated with the Destination Connection ID is used to construct the packet protection nonce defined in {#multipath-aead}. From 6c02f5eb71f91b1c5510c0a70d1982e442fb8554 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Mirja=20K=C3=BChlewind?= Date: Tue, 14 May 2024 12:50:44 +0200 Subject: [PATCH 12/33] fix-lint --- draft-ietf-quic-multipath.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 9490ec05..09e3ae88 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -313,14 +313,14 @@ that it provides to the peer. Each endpoint associates a Sender Packet Number sp to each Path Identifier received from the peer. -Endpoints use the same Path ID for one specific path in both directions. -For a client-initiated path, the client decides which Path ID used for the new path, -it picks one of the server allocated CID with the specified Path ID. -Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, +Endpoints use the same Path ID for one specific path in both directions. +For a client-initiated path, the client decides which Path ID used for the new path, +it picks one of the server allocated CID with the specified Path ID. +Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. -If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID +If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send the PATH_RESPONSE frame upon reception of a MP_NEW_CONNECTION_ID frame containing the corresponding Path ID. From 479de5ef912b53ebbe3e81d16f4394719a4fccfc Mon Sep 17 00:00:00 2001 From: mirjak Date: Tue, 14 May 2024 18:31:29 +0200 Subject: [PATCH 13/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 09e3ae88..2d4c312d 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -1228,8 +1228,7 @@ PATH_ABANDON frames are formatted as shown in {{fig-path-abandon-format}}. PATH_ABANDON frames contain the following fields: Path Identifier: -: The Path Identifier of the Destination Connection ID used by the - receiver of the frame to send packets over the path to abandon. +: The Path Identifier to abandon. Error Code: : A variable-length integer that indicates the reason for abandoning @@ -1271,9 +1270,8 @@ PATH_STANDBY frames are formatted as shown in {{fig-path-standby-format}}. PATH_STANDBY Frames contain the following fields: Path Identifier: -: The Path Identifier of the Destination Connection ID used by the - receiver of this frame to send packets over the path the status update - corresponds to. All Destination Connection IDs that have been issued +: The Path Identifier the status update corresponds to. + All Destination Connection IDs that have been issued MAY be specified, even if they are not yet in use over a path. Path Status sequence number: @@ -1321,9 +1319,7 @@ PATH_AVAILABLE frames are formatted as shown in {{fig-path-available-format}}. PATH_AVAILABLE frames contain the following fields: Path Identifier: -: The Path Identifier of the Destination Connection ID used by the - receiver of this frame to send packets over the path the status update - corresponds to. +: The Path Identifier the status update corresponds to. Path Status sequence number: : A variable-length integer specifying From 323f3cf728885d95d7ff1eeca8aa66ebbc329560 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 17 May 2024 11:43:40 +0200 Subject: [PATCH 14/33] nits/typos Co-authored-by: Quentin De Coninck --- draft-ietf-quic-multipath.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 2d4c312d..13bbfab7 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -314,13 +314,13 @@ to each Path Identifier received from the peer. Endpoints use the same Path ID for one specific path in both directions. -For a client-initiated path, the client decides which Path ID used for the new path, -it picks one of the server allocated CID with the specified Path ID. -Then the client send a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, +For a client-initiated path, the client decides which Path ID is used for the new path +by picking one of the server allocated CID with the specified Path ID. +Then, the client sends a PATH_CHALLENGE with the chosen CID. If the server receives the PATH_CHALLENGE, it picks a Connection ID with the same path ID for sending the PATH_RESPONSE. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. -If the server receives a PATH_CHALLENGE before receiving MP_NEW_CONNECTION_ID +If the server receives a PATH_CHALLENGE before receiving a MP_NEW_CONNECTION_ID for the specific path, it MAY choose to ignore the PATH_CHALLENGE, or it can choose to send the PATH_RESPONSE frame upon reception of a MP_NEW_CONNECTION_ID frame containing the corresponding Path ID. From 1dddecbfe1e64a103db3dffb93be7bcce204f853 Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Fri, 17 May 2024 19:47:47 +0800 Subject: [PATCH 15/33] Update draft-ietf-quic-multipath.md Co-authored-by: mirjak --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 13bbfab7..e79659cd 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -487,7 +487,7 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). -PATH_ABANDON frame causes all the CID allocated for the specified Path ID to be retired. +PATH_ABANDON frame causes all CID allocated by both of the endpoints for the specified Path ID to be retired. When path validation of a new path fails, the client MUST consider the Path ID as consumed, and MUST abandon the path by sending a PATH_ABANDON frame. to inform the server that the Path ID can’t be used in the future. From d87795952c0f34af9540feaa11a966ed5f36e0bf Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Fri, 17 May 2024 19:49:29 +0800 Subject: [PATCH 16/33] Update draft-ietf-quic-multipath.md Co-authored-by: mirjak --- draft-ietf-quic-multipath.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index e79659cd..836adf36 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -489,8 +489,9 @@ the only way for an endhost to detect path closure (see PATH_ABANDON frame causes all CID allocated by both of the endpoints for the specified Path ID to be retired. -When path validation of a new path fails, the client MUST consider the Path ID as consumed, and MUST abandon the path by sending a PATH_ABANDON frame. -to inform the server that the Path ID can’t be used in the future. +When path validation of a new path fails, the used Path ID is anyway consumed, +and the endpoint MUST abandon the path by sending a PATH_ABANDON frame +on another path to inform the peer that the Path ID cannot be used anymore. Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a From d20519b0e74d753a8d9f549ec3b090c7293c5246 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 17 May 2024 13:54:19 +0200 Subject: [PATCH 17/33] whitespace --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 836adf36..08d11645 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -489,7 +489,7 @@ the only way for an endhost to detect path closure (see PATH_ABANDON frame causes all CID allocated by both of the endpoints for the specified Path ID to be retired. -When path validation of a new path fails, the used Path ID is anyway consumed, +When path validation of a new path fails, the used Path ID is anyway consumed, and the endpoint MUST abandon the path by sending a PATH_ABANDON frame on another path to inform the peer that the Path ID cannot be used anymore. From a77525b739afb048a691d666f88a26bebc7893c6 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:19:07 +0200 Subject: [PATCH 18/33] Move text to initiation section --- draft-ietf-quic-multipath.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 08d11645..29c75602 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -383,18 +383,6 @@ All new frames are sent in 1-RTT packets {{QUIC-TRANSPORT}}. ## Path Initiation -Connection IDs cannot be reused, thus opening a new path requires the -use of a new Connection ID (see {{Section 9.5 of QUIC-TRANSPORT}}). -Following {{QUIC-TRANSPORT}}, each endpoint uses MP_NEW_CONNECTION_ID frames -to issue usable connections IDs to reach it. As such to open -a new path by initiating path validation, both sides need at least -one Connection ID (see {{Section 5.1.1 of QUIC-TRANSPORT}}), which is associated with an unused Path ID. - -If the transport parameter "initial_max_paths" is negotiated as N, -and the client is already actively using N paths, the limit is reached. -If the client wants to start a new path, it has to retire one of -the established paths. - When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure with PATH_CHALLENGE and PATH_RESPONSE frames described in @@ -404,6 +392,26 @@ client on a new path, if the server decides to use the new path, the server MUST perform path validation ({{Section 8.2 of QUIC-TRANSPORT}}) unless it has previously validated that address. +If the transport parameter "initial_max_paths" is negotiated as N, +and the client is already actively using N paths, the limit is reached. +If the client wants to start a new path, it has to retire one of +the established paths. + +Connection IDs cannot be reused, thus opening a new path requires the +use of a new Connection ID (see {{Section 9.5 of QUIC-TRANSPORT}}). +Following {{QUIC-TRANSPORT}}, each endpoint uses MP_NEW_CONNECTION_ID frames +to issue usable connections IDs to reach it. As such to open +a new path by initiating path validation, both sides need at least +one Connection ID (see {{Section 5.1.1 of QUIC-TRANSPORT}}), which is associated with an unused Path ID. + +Endpoints use the same Path ID for one specific path in both directions. +The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. +An endpoint decides which Path ID is used for the new path +by picking one of the peer-allocated CID with the specified Path ID. +Then, the endpoint sends a PATH_CHALLENGE with the chosen CID. +If the peer receives the PATH_CHALLENGE, +it MUST pick a Connection ID with the same path ID for sending the PATH_RESPONSE. + If validation succeeds, the client can continue to use the path. If validation fails, the client MUST NOT use the path and can remove any status associated to the path initation attempt. From 6bf2d85fba26bed3dd70269c5f9ce9268935d35d Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:24:56 +0200 Subject: [PATCH 19/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 57af8714..e8c13c2a 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -456,7 +456,8 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). -PATH_ABANDON frame causes all CID allocated by both of the endpoints for the specified Path ID to be retired. +PATH_ABANDON frame causes all CIDs allocated by both +of the endpoints for the specified Path ID to be retired. When path validation of a new path fails, the used Path ID is anyway consumed, and the endpoint MUST abandon the path by sending a PATH_ABANDON frame From 6c8ea0331ee51f74e63042d6f406a22554e40688 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:26:20 +0200 Subject: [PATCH 20/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index e8c13c2a..0be9a69f 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -365,7 +365,7 @@ a new path by initiating path validation, both sides need at least one connection ID (see {{Section 5.1.1 of QUIC-TRANSPORT}}), which is associated with an unused Path ID. -Endpoints use the same Path ID for one specific path in both directions. +The same Path ID is used in both directions. The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. An endpoint decides which Path ID is used for the new path by picking one of the peer-allocated CID with the specified Path ID. From 62d367868f5e4a462007b0ad64899800c2b94ef8 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:33:46 +0200 Subject: [PATCH 21/33] Editorial clean up --- draft-ietf-quic-multipath.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 0be9a69f..efde4556 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -360,17 +360,11 @@ Opening a new path requires the use of a new connection ID (see {{Section 9.5 of QUIC-TRANSPORT}}). Instead of NEW_CONNECTION_ID frame as specified in {{QUIC-TRANSPORT}}, each endpoint uses MP_NEW_CONNECTION_ID frames -to issue usable Path ID-specific connections IDs to reach it. As such to open -a new path by initiating path validation, both sides need at least +to issue Path ID-specific connections IDs. +The same Path ID is used in both directions. As such to open +a new path, both sides need at least one connection ID (see {{Section 5.1.1 of QUIC-TRANSPORT}}), which is associated -with an unused Path ID. - -The same Path ID is used in both directions. -The client MUST choose a previously unused Path ID for which both endpoints have already issued at least one connection ID. -An endpoint decides which Path ID is used for the new path -by picking one of the peer-allocated CID with the specified Path ID. -Then, the endpoint sends a PATH_CHALLENGE with the chosen CID. -If the peer receives the PATH_CHALLENGE, +with the same, unused Path ID. If the peer receives the PATH_CHALLENGE, it MUST pick a Connection ID with the same path ID for sending the PATH_RESPONSE. If validation succeeds, the client can continue to use the path. From 60cf3fc61fc89e77951b6344daccb5a3d8a4bd08 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:38:30 +0200 Subject: [PATCH 22/33] Update intro --- draft-ietf-quic-multipath.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index efde4556..7920bd9f 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -129,15 +129,15 @@ parameter, as specified in {{nego}}. This extension specifies a new Path Identifier (Path ID), which is an integer between 0 and 2^32 - 1 (inclusive). Path identifies are generated -monotonically increasing and cannot be reused. +monotonically increasing and cannot be reused. -The Path ID is used to +The same Path ID is used in both directions to address a path in the new multipath control frames, such as PATH_ABANDON {{path-abandon-frame}}, PATH_STANDBY {{path-standby-frame}}}, PATH_AVAILABLE {{path-available-frame}} as well as ACK_MP {{ack-mp-frame}}. Further, connection IDs are issued per Path ID. -Each connection ID is associated with one path identifier -but multiple connection IDs can be associated with the same path identifier. +That means each connection ID is associated with exactly one path identifier +but multiple connection IDs are usually issued for each path identifier. The Path ID of the initial path is 0. Connection IDs which are issued by a NEW_CONNECTION_ID frame {{Section 19.15. of QUIC-TRANSPORT}} From f06069c70f0ae02437bd96cf110d0a304915fca1 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 10:38:58 +0200 Subject: [PATCH 23/33] whitespace --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 7920bd9f..4cf07bd5 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -129,7 +129,7 @@ parameter, as specified in {{nego}}. This extension specifies a new Path Identifier (Path ID), which is an integer between 0 and 2^32 - 1 (inclusive). Path identifies are generated -monotonically increasing and cannot be reused. +monotonically increasing and cannot be reused. The same Path ID is used in both directions to address a path in the new multipath control frames, From 06c8297ea073d95ff2a0050deb28429c96e4444b Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 11:50:29 +0200 Subject: [PATCH 24/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 4cf07bd5..67d658b9 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -370,6 +370,10 @@ it MUST pick a Connection ID with the same path ID for sending the PATH_RESPONSE If validation succeeds, the client can continue to use the path. If validation fails, the client MUST NOT use the path and can remove any status associated to the path initation attempt. +However, as the used Path ID is anyway consumed, +and the endpoint MUST abandon the path by sending a PATH_ABANDON frame +on another path to inform the peer that the Path ID cannot be used anymore. + {{Section 9.1 of QUIC-TRANSPORT}} introduces the concept of "probing" and "non-probing" frames. When the multipath extension is negotiated, the reception of "non-probing" @@ -453,10 +457,6 @@ the only way for an endhost to detect path closure (see PATH_ABANDON frame causes all CIDs allocated by both of the endpoints for the specified Path ID to be retired. -When path validation of a new path fails, the used Path ID is anyway consumed, -and the endpoint MUST abandon the path by sending a PATH_ABANDON frame -on another path to inform the peer that the Path ID cannot be used anymore. - Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a CONNECTION_CLOSE ({{Section 10.2 of QUIC-TRANSPORT}}) or a Stateless From 5bf27b0ff601c6de802458a3caf90f50ac631803 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 11:57:33 +0200 Subject: [PATCH 25/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 67d658b9..c29f9ae7 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -469,9 +469,9 @@ by sending a PATH_ABANDON frame (see {{path-abandon-frame}}) which requests the peer to stop sending packets with the corresponding Path Identifier. When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at -least three times the current Probe Timeout (PTO) interval as defined in -{{Section 6.2 of QUIC-RECOVERY}} after the last packet was sent on the path, -before sending the MP_RETIRE_CONNECTION_ID frame for all the corresponding Connection +least three times the current Probe Timeout (PTO) interval after the last +packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, +before sending the MP_RETIRE_CONNECTION_ID frame for all the corresponding connection IDs used for this path. This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}} to ensure that paths close cleanly and that delayed or reordered packets are properly discarded. From b712f6b0fa1cd4ef3d9dcc8f97ecc35710ec675d Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Fri, 24 May 2024 21:39:03 +0800 Subject: [PATCH 26/33] Update draft-ietf-quic-multipath.md Co-authored-by: mirjak --- draft-ietf-quic-multipath.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index c29f9ae7..8faf052a 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -454,8 +454,8 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). -PATH_ABANDON frame causes all CIDs allocated by both -of the endpoints for the specified Path ID to be retired. +When a path is abandoned, all CIDs allocated by both +of the endpoints for the specified Path ID need to be retired. Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a From ed01cd847025c0f55fdca4baa2c91dc95acc7f8a Mon Sep 17 00:00:00 2001 From: Yanmei Liu Date: Fri, 24 May 2024 21:40:07 +0800 Subject: [PATCH 27/33] Update draft-ietf-quic-multipath.md Co-authored-by: mirjak --- draft-ietf-quic-multipath.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 8faf052a..5232dd56 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -471,8 +471,10 @@ requests the peer to stop sending packets with the corresponding Path Identifier When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at least three times the current Probe Timeout (PTO) interval after the last packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, -before sending the MP_RETIRE_CONNECTION_ID frame for all the corresponding connection -IDs used for this path. This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}} +before sending MP_RETIRE_CONNECTION_ID frames. +This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}} +Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames +for all connection IDs associated to the Path ID of the abandoned path. to ensure that paths close cleanly and that delayed or reordered packets are properly discarded. The effect of receiving a MP_RETIRE_CONNECTION_ID frame is specified in the From 30a56a5def689b28816d0ef69f37d95d994055de Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 15:48:40 +0200 Subject: [PATCH 28/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 5232dd56..5e673472 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -472,7 +472,7 @@ When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at least three times the current Probe Timeout (PTO) interval after the last packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, before sending MP_RETIRE_CONNECTION_ID frames. -This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}} +This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}}. Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames for all connection IDs associated to the Path ID of the abandoned path. to ensure that paths close cleanly and that delayed or reordered packets From 6af816cc3e11b569eda3976707c7bc9abda10604 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 15:49:12 +0200 Subject: [PATCH 29/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 5e673472..88d25e22 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -474,7 +474,7 @@ packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, before sending MP_RETIRE_CONNECTION_ID frames. This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}}. Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames -for all connection IDs associated to the Path ID of the abandoned path. +for all connection IDs associated to the Path ID of the abandoned path to ensure that paths close cleanly and that delayed or reordered packets are properly discarded. The effect of receiving a MP_RETIRE_CONNECTION_ID frame is specified in the From 46b44c3075d2afdbd5e20211d1286e1fb1f22d7f Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 15:54:51 +0200 Subject: [PATCH 30/33] Move sentence and editorial fixes --- draft-ietf-quic-multipath.md | 33 ++++++++++++++++----------------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 88d25e22..34e4ae66 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -454,9 +454,6 @@ However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see {{idle-time-close}}). -When a path is abandoned, all CIDs allocated by both -of the endpoints for the specified Path ID need to be retired. - Note that other explicit closing mechanisms of {{QUIC-TRANSPORT}} still apply on the whole connection. In particular, the reception of either a CONNECTION_CLOSE ({{Section 10.2 of QUIC-TRANSPORT}}) or a Stateless @@ -468,18 +465,6 @@ Both endpoints, namely the client and the server, can initiate path closure, by sending a PATH_ABANDON frame (see {{path-abandon-frame}}) which requests the peer to stop sending packets with the corresponding Path Identifier. -When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at -least three times the current Probe Timeout (PTO) interval after the last -packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, -before sending MP_RETIRE_CONNECTION_ID frames. -This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}}. -Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames -for all connection IDs associated to the Path ID of the abandoned path -to ensure that paths close cleanly and that delayed or reordered packets -are properly discarded. -The effect of receiving a MP_RETIRE_CONNECTION_ID frame is specified in the -next section. - Usually, it is expected that the PATH_ABANDON frame is used by the client to indicate to the server that path conditions have changed such that the path is or will be not usable anymore, e.g. in case of a mobility @@ -492,6 +477,20 @@ The receiver of a PATH_ABANDON frame MAY also send a PATH_ABANDON frame to indicate its own unwillingness to receive any packet on this path anymore. +When a path is abandoned, all CIDs allocated by both +of the endpoints for the specified Path ID need to be retired. +When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at +least three times the current Probe Timeout (PTO) interval after the last +packet was sent on the path, as defined in {{Section 6.2 of QUIC-RECOVERY}}, +before sending MP_RETIRE_CONNECTION_ID frames. +This is inline with the requirement of {{Section 10.2 of QUIC-TRANSPORT}}. +Both endpoints SHOULD send MP_RETIRE_CONNECTION_ID frames +for all connection IDs associated to the Path ID of the abandoned path +to ensure that paths close cleanly and that delayed or reordered packets +are properly discarded. +The effect of receiving a MP_RETIRE_CONNECTION_ID frame is specified in the +next section. + PATH_ABANDON frames can be sent on any path, not only the path that is intended to be closed. Thus, a path can be abandoned even if connectivity on that path is already broken. @@ -510,8 +509,8 @@ CONNECTION_CLOSE frame. Note that PATH_ABANDON frame is also used as a signal for the retirement of the associated Path Identifier. When endpoint received PATH_ABANDON frame, -it SHOULD not use the associated Path Identifier in future packets, it can -only use the Path ID in ACK_MP frames for inflight packets or +it SHOULD NOT use the associated Path Identifier in future packets, except +in ACK_MP frames for inflight packets or in MP_RETIRE_CONNECTION_ID frames for CID retirement. ### Refusing a New Path From b22dbae0e21c36b193ef650bc966f987c60ba5c1 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 16:03:45 +0200 Subject: [PATCH 31/33] restructure path close section --- draft-ietf-quic-multipath.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 34e4ae66..1fe21a14 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -477,6 +477,18 @@ The receiver of a PATH_ABANDON frame MAY also send a PATH_ABANDON frame to indicate its own unwillingness to receive any packet on this path anymore. +The PATH_ABANDON frame is retires the associated Path Identifier. +When an endpoint receives a PATH_ABANDON frame, +it SHOULD NOT use the associated Path Identifier in future packets, except +in ACK_MP frames for inflight packets and +in MP_RETIRE_CONNECTION_ID frames for CID retirement. + +PATH_ABANDON frames can be sent on any path, +not only the path that is intended to be closed. Thus, a path can +be abandoned even if connectivity on that path is already broken. +Respectively, if there is still an active path, it is RECOMMENDED to +send a PATH_ABANDON frame after an idle time on another path. + When a path is abandoned, all CIDs allocated by both of the endpoints for the specified Path ID need to be retired. When sending or receiving a PATH_ABANDON frame, endpoints SHOULD wait for at @@ -491,12 +503,6 @@ are properly discarded. The effect of receiving a MP_RETIRE_CONNECTION_ID frame is specified in the next section. -PATH_ABANDON frames can be sent on any path, -not only the path that is intended to be closed. Thus, a path can -be abandoned even if connectivity on that path is already broken. -Respectively, if there is still an active path, it is RECOMMENDED to -send a PATH_ABANDON frame after an idle time on another path. - If a PATH_ABANDON frame is received for the only active path of a QUIC connection, the receiving peer SHOULD send a CONNECTION_CLOSE frame and enter the closing state. If the client received a PATH_ABANDON @@ -507,11 +513,7 @@ the server MAY wait for a short, limited time such as one PTO if a path probing packet is received on a new path before sending the CONNECTION_CLOSE frame. -Note that PATH_ABANDON frame is also used as a signal for the retirement -of the associated Path Identifier. When endpoint received PATH_ABANDON frame, -it SHOULD NOT use the associated Path Identifier in future packets, except -in ACK_MP frames for inflight packets or -in MP_RETIRE_CONNECTION_ID frames for CID retirement. + ### Refusing a New Path From 902ab7189342c65a374a42531246ba8364aa3be7 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 16:05:39 +0200 Subject: [PATCH 32/33] Update draft-ietf-quic-multipath.md --- draft-ietf-quic-multipath.md | 1 - 1 file changed, 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 1fe21a14..85b079a5 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -514,7 +514,6 @@ probing packet is received on a new path before sending the CONNECTION_CLOSE frame. - ### Refusing a New Path An endpoint may deny the establishment of a new path initiated by its From a865fea1f2a8a2ca3e9c7d9bba559a580d99d0a4 Mon Sep 17 00:00:00 2001 From: mirjak Date: Fri, 24 May 2024 16:18:51 +0200 Subject: [PATCH 33/33] whitespace --- draft-ietf-quic-multipath.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-multipath.md b/draft-ietf-quic-multipath.md index 85b079a5..d9ea9640 100644 --- a/draft-ietf-quic-multipath.md +++ b/draft-ietf-quic-multipath.md @@ -360,7 +360,7 @@ Opening a new path requires the use of a new connection ID (see {{Section 9.5 of QUIC-TRANSPORT}}). Instead of NEW_CONNECTION_ID frame as specified in {{QUIC-TRANSPORT}}, each endpoint uses MP_NEW_CONNECTION_ID frames -to issue Path ID-specific connections IDs. +to issue Path ID-specific connections IDs. The same Path ID is used in both directions. As such to open a new path, both sides need at least one connection ID (see {{Section 5.1.1 of QUIC-TRANSPORT}}), which is associated