idnits 2.17.1 draft-huitema-quic-mpath-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '...ders can, indeed SHOULD, use the Path ...' RFC 2119 keyword, line 205: '...ng another value SHOULD terminate the ...' RFC 2119 keyword, line 209: '...tion values 1 or 3 MUST NOT send these...' RFC 2119 keyword, line 234: '...ANAGEMENT frames MUST only be sent in ...' RFC 2119 keyword, line 247: '... path identifier SHOULD match the valu...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2020) is 1284 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-08) exists of draft-huitema-quic-ts-03 ** Downref: Normative reference to an Experimental draft: draft-huitema-quic-ts (ref. 'I-D.huitema-quic-ts') == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-31 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Standards Track October 20, 2020 5 Expires: April 23, 2021 7 QUIC Multipath Negotiation Option 8 draft-huitema-quic-mpath-option-00 10 Abstract 12 The initial version of QUIC provides support for path migration. In 13 this draft, we argue that there is a very small distance between 14 supporting path migration and supporting simulatneous traffic on 15 multipath. Instead of using an implicit algorithm to discard unused 16 paths, we propose a simple option to allow explicit management of 17 active and inactive paths. Once paths are explicitly managed, pretty 18 much all other requirements for multipath support can be met by 19 appropriate algorithms for scheduling transmissions on specific 20 paths. These algorithms can be implemented on the sender side, and 21 do not require specific extensions, except maybe a measurement of one 22 way delays. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 23, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Path Management Requirement . . . . . . . . . . . . . . . . . 3 60 3. Path Management Extension . . . . . . . . . . . . . . . . . . 4 61 3.1. Path Management Support Transport Parameter . . . . . . . 4 62 3.2. PATH_IDENTIFICATION Frame (TBD) . . . . . . . . . . . . . 5 63 3.3. PATH_STATUS Frame (TBD) . . . . . . . . . . . . . . . . . 6 64 4. Sender side algorithms . . . . . . . . . . . . . . . . . . . 6 65 4.1. Packet Numbers and Acknowledgements . . . . . . . . . . . 6 66 4.2. Congestion Control and Error Recovery . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The QUIC Working Group is debating how much priority should be given 76 to the support of multipath in QUIC. This is not a new debate. The 77 the QUIC transport [I-D.ietf-quic-transport] includes a number of 78 mechanisms to handle multiple paths, including the support for NAT 79 rebinding and for explicit migration. 81 The processing of received packets by QUIC nodes only requires that 82 the connection context can be retrieved using the combination of IP 83 addresses and UDP ports in the IP and UDP headers, and connection 84 identifier in the packet header. Once the connection context is 85 identified, the receiving node will verify if the packet can be 86 successfully decrypted. If it is, the packet will be processed and 87 eventually an acknowledgement will inform the sender that it was 88 received. 90 In theory, that property of QUIC implies that senders could send 91 packets using whatever IP addresses or UDP ports they see fit, as 92 long as they carry a valid connection ID, and are properly encrypted. 93 Senders can, indeed SHOULD, use the Path Challenge and Response 94 mechanism to verify that the path is valid before sending packets, 95 but even that is optional. The NAT rebinding mechanisms, for 96 example, rely on the possibility of receiving packets without a 97 preliminary Path Challenge. However, in practice, the sender's 98 choice of sending paths is limited by the path migration logic in 99 [I-D.ietf-quic-transport]. 101 Path migration according to [I-D.ietf-quic-transport] is always 102 initiated by the node in the client role. That node will test the 103 validity of paths using the path challenge response mechanism, and at 104 some point decide to switch all its traffic to a new path. The node 105 in the server role will detect that data traffic (i.e., ack eliciting 106 frames) is sent on a new path, and on detecting that, will switch its 107 own traffic to that new path. After that, client and server can 108 release the resource tied to the old path, for example by retiring 109 the connection identifiers, releasing the memory context used for 110 managing per path congestion, or forgetting the IP addresses and 111 ports associated with that path. By sending data on a new path, the 112 client provides an implicit signal to discard the old path. If the 113 client was to spread data on several paths, the server would probably 114 become confused. 116 This draft proposes an explicit mechanism for replacing the implicit 117 signalling of path migration through data transmission, by means of a 118 new PATH_OPTION frame. 120 2. Path Management Requirement 122 Implicit path management, as specified in [I-D.ietf-quic-transport], 123 fulfills two goals: it direct a peers to switch sending through a new 124 preferred path, and it allows the peer to release resources 125 associated with the old path. Explicit path management will have to 126 fulfill similar goals: provide indications to the peer regarding 127 preferred paths for receiving data; and, signal to the peer when 128 resource associated with previous paths can be discarded. 130 We cannot mandate that path management signals be always carried on 131 the path that they affect. For example, consider a node that wants 132 to abandon a path through a Wi-Fi network because the signal strength 133 is fading. It will need to signal its peer to move traffic away from 134 that path, but there is no guarantee that a packet sent through the 135 old fading path will be promptly received. It is much preferable to 136 send such management signals on a different path, for example through 137 a cellular link. But if path management signals can be sent on 138 arbitrary paths, they need to identify the path that they manage. 140 Neither addresses nor connection identifiers are good identifiers of 141 paths. Because of NAT, addresses and ports can be changed during the 142 transfer of packets from source to destination. Multiple connection 143 identifiers can be used over the lifetime of a path, and there is 144 also no strict requirement that a given connection identifier be used 145 on a single path. On the other hand, one can imagine an inband "path 146 identification" frame that establishes an identifier for a specific 147 path. That identifier can then be used in other path management 148 frames. 150 The path management frames provides directions on how to use existing 151 paths. We could imagine a number of variations, but the simplest one 152 would be: 154 o Abandon a path, and release the corresponding resource. 156 o Mark a path as "available", i.e., allow the peer to use its own 157 logic to split traffic among available paths. 159 o Mark a path as "standby", i.e., suggest that no traffic should be 160 sent on that path if another path is available. 162 We could also envisage marking a path as "preferred", suggesting that 163 all traffic would be sent to that path, but the same functionality is 164 achieved by marking only one path as available. 166 There might be a delay between the moment a path is validated through 167 the challenge response mechanism, identified using path 168 identification frames, and managed using path management frames. 169 During that delay, the following conventions apply: 171 o If a path is validated but no ack-eliciting frames or path 172 management frames are received, the path is placed in the 173 "standby" state. 175 o If ack-eliciting frames are received on a path before path 176 management frames, the path is placed in the "available" state. 178 3. Path Management Extension 180 The path management extension is negotiated by means of the 181 "enable_path_management" transport parameter. When support is 182 negotiated, the peers can send or receive the PATH_IDENTIFICATION and 183 PATH_STATUS frames. 185 3.1. Path Management Support Transport Parameter 187 The use of the PATH_IDENTIFICATION and PATH_STATUS transport frame 188 extension is negotiated using a transport parameter: 190 o "enable_path_management" (TBD) 191 The "enable_path_management" transport parameter is included if the 192 endpoint wants to receive or accepts PATH_IDENTIFICATION and 193 PATH_STATUS frames for this connection. This parameter is encoded as 194 a variable integer as specified in section 16 of 195 [I-D.ietf-quic-transport]. It can take one of the following three 196 values: 198 1. I would like to send PATH_IDENTIFICATION and PATH_STATUS frames 200 2. I am able to process PATH_IDENTIFICATION and PATH_STATUS frames 202 3. I am able to process PATH_IDENTIFICATION and PATH_STATUS frames 203 and I would like to send them. 205 Peers receiving another value SHOULD terminate the connection with a 206 TRANSPORT PARAMETER error. 208 A peer that advertises its capability of sending PATH_IDENTIFICATION 209 and PATH_STATUS frames using option values 1 or 3 MUST NOT send these 210 frames if the other peer does not announce advertise its ability to 211 process them by sending the enable_path_management TP with option 1 212 or 3. 214 3.2. PATH_IDENTIFICATION Frame (TBD) 216 The PATH_IDENTIFICATION frames carry a single identifier, the path 217 identifier. " PATH_IDENTIFICATION Frame { Path Identifier (i) } " The 218 frame carries the identifier of the path over which it is received, 219 as defined by the peer sending data on that path. The identifier is 220 a positive integer lower than 2^62. 222 PATH_IDENTIFICATION frames are ACK-eliciting. 224 Due to delays and retransmissions, several PATH_IDENTIFICATION frames 225 may be received on the same path. In that case, the identifier with 226 the highest value is retrained for the path. For example, if a node 227 receives on the same path the identifiers 11, 17 and 13, the path 228 will be identified by the number 17. 230 If both peers have successfully negotiated the capability of sending 231 path management frames, each peer will send its own identifier over 232 the path. 234 PATH_MANAGEMENT frames MUST only be sent in 1-RTT packets. Receiving 235 such frames in Initial, Handshake of 0-RTT packets is a transport 236 violation. 238 3.3. PATH_STATUS Frame (TBD) 240 The PATH_STATUS frames carry three parameters: the identifier of the 241 path being managed, the new status of the path, and a management 242 sequence number. 244 " PATH_STATUS Frame { Path Identifier (i), Path Status (i), 245 Management Sequence Number (i) } " 247 The path identifier SHOULD match the value sent in a previous 248 PATH_IDENTIFICATION frame for an existing frame. If no such value is 249 found, the PATH_STATUS frame will be discarded. 251 NAT rebinding and retransmissions could cause the same identifier to 252 be received over different paths. If that happens, PATH_MANAGEMENT 253 frames will apply to all the paths sharing that identifier. 255 PATH_STATUS frames are ACK-eliciting. 257 Due to delays and retransmissions, PATH_STATUS frames may be received 258 out of order. If the Management Sequence Number is not greater than 259 the previously received values for that path, the PATH_STATUS frame 260 will be discarded. 262 If the frame is accepted, the status of the path is set to the 263 received Path Status, for which the authorized values are: 265 0- Abandon 1- Standby 2- Available 267 Receiving any other value is an error, which SHOULD trigger the 268 closure of the connection with a reason code PROTOCOL VIOLATION. 270 PATH_MANAGEMENT frames MUST only be sent in 1-RTT packets. Receiving 271 such frames in Initial, Handshake of 0-RTT packets is a transport 272 violation. 274 4. Sender side algorithms 276 In this minimal design, the sender is responsible for scheduling 277 packets transmission on different paths, preferably on "Available" 278 paths, but possibly on "StandBy" paths if all available paths are 279 deemed unusable. 281 4.1. Packet Numbers and Acknowledgements 283 The packet number space does not depend on the path on which the 284 packet is sent. ACK frames report the numbers of packets that have 285 been received so far, regardless of the path on which they have been 286 received. 288 If senders decide to send packets on paths with different 289 transmission delays, some packets will very probably be received out 290 of order. This will cause the ACK frames to carry multiple ranges of 291 received packets. Senders that want to control this issue may do so 292 by dedicating sub-ranges of packet numbers to different paths. We 293 expect that experience on how to manage such ranges will quickly 294 emerge. 296 4.2. Congestion Control and Error Recovery 298 Senders MUST manage per-path congestion status, and MUST NOT send 299 more data on a given path than congestion control on that path 300 allows. This is already a requirement of [I-D.ietf-quic-transport]. 302 In order to implement per path congestion control, the senders 303 maintain an association between previously sent packet numbers and 304 the path over which these packets were sent. When a packet is newly 305 acknowledged, the delay between the transmission of that packet and 306 its first acknowledgement is used to update the RTT statitics for the 307 sending path, and to update the state of the congestion control for 308 that path. 310 Packet loss detection MUST be adapted to allow for different RTT on 311 different paths. For example, timer computations should take into 312 account the RTT of the path on which a packet was sent. Detections 313 based on packet numbers shall compare a given packet number to the 314 highest packet number received for that path. 316 Acknowledgement delays are the sum of two one-way delays, the delay 317 on the packet sending path and the delay on the return path chosen 318 for the acknowledgements. It is unclear whether this is a problem in 319 practice, but this could motivate the use of time stamps 320 [I-D.huitema-quic-ts] in conjunction with acknowledgements. 322 5. Security Considerations 324 TBD. There are probably ways to abuse this. 326 6. IANA Considerations 328 This document registers a new value in the QUIC Transport Parameter 329 Registry: 331 Value: TBD (using value 0xe9a in early deployments) 332 Parameter Name: enable_path_management 334 Specification: Indicates support of the Path Management options. 336 This document also registers 2 new values in the QUIC Frame Type 337 registry: 339 Value: TBD (using value 0x9a1 in early deployments) 341 Frame Name: PATH_IDENTIFICATION 343 Specification: Identification of the path over which a packet is 344 sent. 346 Value: TBD (using value 0x9a5 in early deployments) 348 Frame Name: PATH_STATUS 350 Specification: Identification of the path over which a packet is 351 sent. 353 7. Acknowledgements 355 8. Normative References 357 [I-D.huitema-quic-ts] 358 Huitema, C., "Quic Timestamps For Measuring One-Way 359 Delays", draft-huitema-quic-ts-03 (work in progress), 360 August 2020. 362 [I-D.ietf-quic-transport] 363 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 364 and Secure Transport", draft-ietf-quic-transport-31 (work 365 in progress), September 2020. 367 Author's Address 369 Christian Huitema 370 Private Octopus Inc. 371 427 Golfcourse Rd 372 Friday Harbor WA 98250 373 U.S.A 375 Email: huitema@huitema.net