idnits 2.17.1 draft-hoang-mptcp-sub-rate-limit-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). -- The document date (July 08, 2019) is 1752 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPTCP Working Group V. Tran 3 Internet-Draft O. Bonaventure 4 Intended status: Informational Universite catholique de Louvain 5 Expires: January 9, 2020 July 08, 2019 7 Multipath TCP Subflow Rate Limit Option 8 draft-hoang-mptcp-sub-rate-limit-00 10 Abstract 12 This document defines a new MPTCP Option that enables hosts to 13 request their peers to limit the maximum transfer rate on a per- 14 subflow basis. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 9, 2020. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. The Multipath TCP Subflow Rate Limit (SRL) Option . . . . . . 3 53 3.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. SRL Option and Local Policies . . . . . . . . . . . . . . 4 55 4. Implementation and Interoperability . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 8.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 Multipath TCP [RFC6824] [I-D.ietf-mptcp-rfc6824bis] is used in 67 various use cases [RFC8040]. In several situations, a Multipath TCP 68 host would like its peer to limit the sending rate over a specific 69 subflow. 71 It is common for mobile clients to have limited cellular data 72 subscription. Even if this is not the case, mobile network operators 73 may still silently throttle the networking capacity of the customers 74 who have used up a large amount of cellular data. A good LTE or 5G 75 connection running at full speed during less than a few hours could 76 consume the entire monthly budget cellular quota of many users. This 77 is even more important when the mobile clients are roaming abroad 78 where the monetary cost for cellular data can be very high. A common 79 scenario is that mobile users want to limit the monetary cost of 80 using cellular networks or to avoid running out of their mobile data 81 quota. Smartphones can easily rate limit their upstream bandwidth, 82 but unfortunately, most smartphone applications mainly receive data. 83 For these applications, a rate limit must happen on the server side. 84 This rate limit could be enforced by the application, e.g. by 85 selecting a specific video coding scheme, but applying it at the 86 transport layer would be more generic and could be done from the 87 system level automatically. 89 As discussed on the multipathtcp IETF mailing list 90 [paasch_mptcpwg_2019], this rate-control mechanism can also be used 91 when a client wants to inform a server to close a subflow gracefully 92 by requesting a zero transfer rate. Though the client may send a 93 TCP-RST on this subflow instead, in-flight data would be lost and 94 must be reinjected over other subflows. Another solution is to send 95 an MP_PRIO option to the sender to put the cellular subflow into 96 backup mode, but this request could be overridden by the sender's 97 local policy. 99 2. Terminology 101 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 102 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 103 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 104 [RFC2119]. 106 3. The Multipath TCP Subflow Rate Limit (SRL) Option 108 This document proposes a Subflow Rate Limit option that indicates a 109 maximum receive rate for the subflow it is sent. Like other MPTCP 110 options, this option is not sent reliably. Hosts SHOULD resend is 111 several times, but not more frequently than once per second. 113 3.1. Option Format 115 The format of the SRL option is depicted in Fig. Figure 1: 117 0 1 2 3 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 119 +---------------+---------------+-------+-------+---------------+ 120 | Kind | Length = 5 |Subtype| (rsv) | Requested Rate| 121 +---------------+---------------+-------+-------+---------------+ 122 | Requested Rate | 123 +-----------------------------------------------+ 125 Figure 1: MPTCP Subflow Rate Limit Option Format 127 All reserved bits MUST be set to zero. 129 In the SRL option, the Requested Rate (32 bits) is specified in IEEE 130 754 binary32 format (single-precision binary floating-point format). 131 The same format is used in [RFC3630] to specify the maximum bandwidth 132 of a link. This format is as follows: 134 0 1 2 3 135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |S| Exponent | Fraction | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2: IEEE binary32 format 142 o Sign bit (1 bit) MUST be set to zero. 144 o Exponent (8 bits) is the exponent base 2 in "excess 127" notation. 146 o Fraction (23 bits) is the mantissa - 1, with an implied binary 147 point in front of it. 149 Thus, the above represents the value: 151 (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) 153 The unit of this value is Kilobits per second (Kbps). 155 3.2. SRL Option and Local Policies 157 Note that the SRL option is an indicative value. Upon reception of 158 this option, the receiver SHOULD set the maximum rate on the subflow 159 over which the option was received. 161 Like all Multipath TCP options, the SRL Option is exchanged without 162 any protection from TCP's reliability mechanisms. Therefore, 163 implementations MUST NOT assume that it is transferred reliably. 164 Implementations that use the SRL option can transmit the SRL option 165 at any time. Since the utilisation of this option is not negotiated 166 during the connection handshake, a host MUST NOT send more than three 167 SRL options on a connection where it has not received any SRL option. 169 4. Implementation and Interoperability 171 Implementations MAY use various mechanisms to implement the rate 172 control policy, for example using TCP Pacing or clamping the subflow 173 congestion window. 175 5. Security Considerations 177 Since the SRL option is neither encrypted nor authenticated, on-path 178 attackers and middleboxes could remove, add or modify the SRL option 179 on observed Multipath TCP connections. However, manipulating this 180 option doing not open new attacks compared to the ones documented in 181 [RFC6181] [RFC7430]. 183 For example, an on-path middle man could insert an option to throttle 184 the rate on a subflow to nearly zero, effectively stalling the 185 subflow. However, if an attacker has that capability, it could 186 instead drop all packets or inject the TCP-RST/MP-FASTCLOSE. 188 On the other hand, on-path middleboxes may increase the rate-limit 189 value in the exchanged option to a very high value. This effectively 190 has the same effect as filtering out the option. 192 6. IANA Considerations 194 IANA is requested to assign an MPTCP option subtype for the SRL 195 option from the "MPTCP Option Subtypes" available at 196 https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml 198 7. Acknowledgements 200 This work was supported by the ARC-SDN project and the Walinnov MQUIC 201 project, No. 1810018. 203 8. References 205 8.1. Normative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, 209 DOI 10.17487/RFC2119, March 1997, 210 . 212 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 213 Multipath Operation with Multiple Addresses", RFC 6181, 214 DOI 10.17487/RFC6181, March 2011, 215 . 217 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 218 "TCP Extensions for Multipath Operation with Multiple 219 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 220 . 222 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 223 Raiciu, "Analysis of Residual Threats and Possible Fixes 224 for Multipath TCP (MPTCP)", RFC 7430, 225 DOI 10.17487/RFC7430, July 2015, 226 . 228 8.2. Informative References 230 [I-D.ietf-mptcp-rfc6824bis] 231 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 232 Paasch, "TCP Extensions for Multipath Operation with 233 Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work 234 in progress), June 2019. 236 [paasch_mptcpwg_2019] 237 Paasch, C., "Regarding rate control at a subflow level", 238 May 2019, 239 . 242 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 243 (TE) Extensions to OSPF Version 2", RFC 3630, 244 DOI 10.17487/RFC3630, September 2003, 245 . 247 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 248 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 249 . 251 Authors' Addresses 253 Viet-Hoang Tran 254 Universite catholique de Louvain 256 Email: hoang.tran@uclouvain.be 258 Olivier Bonaventure 259 Universite catholique de Louvain 260 Pl. Ste Barbe, 2 261 Louvain-la-Neuve 1348 262 Belgium 264 Email: olivier.bonaventure@uclouvain.be