idnits 2.17.1 draft-paulo-quic-migration-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: ACKs or other non-probing frames might be inflight to the server when the client decides to switch to an alternative path. It's possible that the ACK on the previous path is delayed and arrives at the server after a non-probing frame has been delivered on the new path. This will create a situation where the server is switching back and forth between the two paths. To avoid this problem, servers SHOULD not switch to sending on the previous path if they have received a larger packet number on the new path. Similarly, clients MAY ignore path validation requests on a path they have deemed unreliable. -- The document date (March 11, 2019) is 1835 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) == Unused Reference: 'RFC0768' is defined on line 234, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 248, but no explicit reference was found in the text -- No information found for draft-ietf-quic-transport-latest - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'QUIC-TRANSPORT' -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Paulo 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track March 11, 2019 5 Expires: September 12, 2019 7 Exploring QUIC Connection Migration 8 draft-paulo-quic-migration-00 10 Abstract 12 This document explores QUIC connection migration and suggests 13 possible improvements. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 12, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Connection migration strategies . . . . . . . . . . . . . . . 2 51 2.1. Failover mode . . . . . . . . . . . . . . . . . . . . . . 2 52 2.2. Standby mode . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Improvements to connection migration . . . . . . . . . . . . 3 54 3.1. Dealing with loss and congestion . . . . . . . . . . . . 3 55 3.2. Keeping the alternate path alive . . . . . . . . . . . . 4 56 3.3. Estimating RTT . . . . . . . . . . . . . . . . . . . . . 4 57 3.4. Migrating without data to send . . . . . . . . . . . . . 4 58 3.5. Path validation privacy . . . . . . . . . . . . . . . . . 4 59 3.6. Path MTU discovery . . . . . . . . . . . . . . . . . . . 5 60 3.7. Interaction with loss recovery . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 7.2. Informative References . . . . . . . . . . . . . . . . . 5 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 This document explores QUIC connection migration in detail and 72 suggests improvements. Familiarity with QUIC as defined in 73 [QUIC-TRANSPORT] is necessary. For reference, QUIC considers 74 PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID and PADDING frames 75 as "probing frames". All other frames are "non-probing frames" 77 2. Connection migration strategies 79 Protocols supporting multiple paths (such as MPTCP [RFC6824]) often 80 have three modes of operation that we call failover, standby and 81 aggregation. 83 QUIC currently supports only the first two. 85 2.1. Failover mode 87 In failover mode, the networking stack monitors the quality of the 88 connection or link and, when they are not operating normally, the 89 QUIC connection is migrated to an alternative path. 91 QUIC doesn't require any packets to be exchanged before migrating to 92 a new path, so this migration is seamless. However, if the new path 93 hasn't been validated, there's less confidence that it will work. 95 2.2. Standby mode 97 In standby mode, the networking stack establishes and validates an 98 alternative path shortly after establishing a connection on the main 99 path. When the link or the connection deteriorate, QUIC can switch 100 to the alternative path. 102 Even though QUIC connections can migrate without validation, this 103 mode improves migration confidence and performance, as explained 104 below. 106 3. Improvements to connection migration 108 In contrast with failover mode, applications operating in standby 109 mode must ensure the alternative path is alive for a significant 110 amount of time. 112 The improvements described below apply only to standby mode because 113 failover mode migrates to an alternative path quickly which doesn't 114 give implementations enough time to determine the characteristics of 115 the new path. 117 3.1. Dealing with loss and congestion 119 In the simplest case, when endpoints have no inflight packets, the 120 connection migrates after the path has been validated. In this case, 121 the endpoints reset their congestion controller and don't have to 122 deal with packet loss. However, more commonly, connection migration 123 happens when the main path is quickly losing quality but it's not 124 completely unusable (i.e., not 100% packet loss) and there are plenty 125 of packets inflight. To better deal with packet loss, endpoints 126 SHOULD process packets from both paths for a certain amount of time. 127 Since the ACK frame is a non-probing packet, implementations can only 128 acknowledge packets on the new path, but this acknowledgement SHOULD 129 include packet numbers received on the previous path during 130 connection migration. 132 ACKs or other non-probing frames might be inflight to the server when 133 the client decides to switch to an alternative path. It's possible 134 that the ACK on the previous path is delayed and arrives at the 135 server after a non-probing frame has been delivered on the new path. 136 This will create a situation where the server is switching back and 137 forth between the two paths. To avoid this problem, servers SHOULD 138 not switch to sending on the previous path if they have received a 139 larger packet number on the new path. Similarly, clients MAY ignore 140 path validation requests on a path they have deemed unreliable. 142 If an endpoint decides to use a single congestion controller during 143 migration, it will reset it during migration. This is acceptable as 144 the migration will require a new congestion feedback. However, if 145 the migration was spurious (due to an attacker or due to link quality 146 policies), the endpoint should restore the previous congestion 147 controller state. 149 3.2. Keeping the alternate path alive 151 Due to shorter NAT timeouts for UDP flows, QUIC connections typically 152 exchange PING frames to maintain the NAT binding alive. However, the 153 PING frame is considered a non-probing frame, so it can't be used to 154 maintain a NAT binding associated with an alternative path alive. 156 To maintain this NAT binding alive, implementations MAY send periodic 157 PATH_CHALLENGE frames. Since a PATH_CHALLENGE triggers a 158 PATH_RESPONSE, the NAT binding is refreshed on both directions. 160 3.3. Estimating RTT 162 Clients can compute the RTT of an alternative path by recording the 163 time the PATH_CHALLENGE frame was sent and measuring the RTT when the 164 corresponding PATH_RESPONSE frame is received. 166 Servers can't use the client's PATH_CHALLENGE to measure the RTT, but 167 since they will issue their own PATH_CHALLENGE, they can measure the 168 RTT once they receive the respective PATH_RESPONSE. 170 In standby mode, endpoints can follow the advice on the previous 171 section to gather more RTT samples. 173 3.4. Migrating without data to send 175 If an implementation detects the link quality is not acceptable 176 anymore, it can send a non-probing frame, such as a PING or ACK, to 177 migrate the connection to the new path. 179 This is especially useful for clients that are monitoring the link 180 quality because they can react faster to last mile link problems. 182 3.5. Path validation privacy 184 To improve privacy, endpoints MAY randomly pad path validation 185 packets (which include PATH_CHALLENGE and PATH_RESPONSE frames) to 186 make it harder for observers to identify connection migrations. This 187 might be unnecessary when the path validation frames are bundled with 188 other non-probing frames. 190 3.6. Path MTU discovery 192 To improve performance, endpoints MAY try to discover the alternative 193 path's MTU before connection migration happens. Endpoints can use 194 the same method described in section 14.3 of [QUIC-TRANSPORT] but 195 instead of using PING frames combined with PADDING frames, they can 196 use PATH_CHALLENGE frames combined with PADDING frames. 198 3.7. Interaction with loss recovery 200 Since path probing sends QUIC packets that might not reach the 201 server, implementations SHOULD avoid probing too many paths 202 simultaneously to avoid issues with loss recovery, specifically with 203 the re-ordering threshold. The issue occurs when the number of 204 probing packets that are lost is higher than kPacketThreshold and 205 then the client sends a packet on the main path. Once the ACK 206 arrives, the loss recovery algorithm will assume the probing packets 207 were lost and reduce the congestion window unnecessarily. As a more 208 general improvement, implementations SHOULD ignore lost path probing 209 packets with regards to congestion window reductions. 211 4. Security Considerations 213 None. 215 5. IANA Considerations 217 None. 219 6. Acknowledgments 221 Christoph Paasch and Tommy Pauly. 223 7. References 225 7.1. Normative References 227 [QUIC-TRANSPORT] 228 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 229 Multiplexed and Secure Transport", draft-ietf-quic- 230 transport-latest (work in progress). 232 7.2. Informative References 234 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 235 DOI 10.17487/RFC0768, August 1980, 236 . 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 244 "TCP Extensions for Multipath Operation with Multiple 245 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 246 . 248 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 249 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 250 May 2017, . 252 Author's Address 254 Rui Paulo 255 Apple Inc. 256 One Apple Park Way 257 Cupertino, California 95014 258 United States of America 260 Email: rpaulo@apple.com