idnits 2.17.1 draft-an-multipath-quic-application-policy-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 Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2020) is 1387 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 (-07) exists of draft-deconinck-quic-multipath-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC Q. An 3 Internet-Draft Alibaba Inc. 4 Intended status: Standards Track Z. Li 5 Expires: January 7, 2021 ICT-CAS 6 Y. Liu 7 Alibaba Inc. 8 July 6, 2020 10 Enabling application policy-awareness in Multipath QUIC 11 draft-an-multipath-quic-application-policy-00 13 Abstract 15 This document describes an application policy-awareness method for 16 Multipath QUIC, to enable taking applications' demands into account 17 when managing paths or scheduling packets in Multipath QUIC. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 55 3. What is Application Policy-awareness in Multipath QUIC . . . 3 56 4. Per-connection Policy . . . . . . . . . . . . . . . . . . . . 4 57 5. Per-stream Intent . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. Informative References . . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 62 1. Introduction 64 The availability of multiple network interfaces in devices enables 65 the use of multiple paths between two end points for robust and 66 (possibly) fast data delivery. Multi-path TCP (MPTCP) was designed 67 to leverage off such an availability. It has been adopted by 68 operating systems and ISPs. A major design principle of MPTCP is 69 that it must be usable by applications through existing SOCKET APIs. 70 That said, it shields the underlying multiple paths for the 71 applications, which may be not even aware the use of multiple path 72 transmission. While this implements the backward compatibility with 73 TCP, it also leaves the applications out of the control loop of the 74 transport. Nevertheless, applications may have completely different 75 QoE requirements---the interactive applications are delay sensitive, 76 while the video streaming are more throughput sensitive. There is 77 thus a trend of cross-layer design that tries to take applications' 78 demands into account when managing paths or scheduling packets in 79 MPTCP [MP-DASH][WN][AD-MPTCP][SMAPP]. 81 We thus advocate the idea of application policy awareness in multi- 82 path transport, which is to separate the 'control plane' from the 83 `data plane' like in software defined networking. The 'control 84 plane' takes applications' high-level demands (a.k.a intent) as input 85 to generate the corresponding policies, which later are deployed on 86 the 'data plane'. The 'data plane' maps users policies to the 87 'actions', which control the path management, packet scheduling and 88 other functionalities that the transport implements. For instance, 89 the 'actions' for path management may include "backup", "full mesh" 90 and "ndiffports", while the 'actions' for packet scheduling may 91 designate whether ECF [ECF] or DEMS [BSC] is used for path selection, 92 and may also impose a traffic split ratio among paths. Each 93 connection then can have a customized multipath transport. 95 Since MPTCP is implemented in OS kernel, it is not easy for 96 application providers to incorporate the above idea into MPTCP to 97 improve the applications' performance. QUIC, on the other hand, 98 implements a UDP-based transport, which enables the transport to be 99 bundled into applications and quickly deployed in end users' devices. 100 MPQUIC extends QUIC to multipath scenarios. Nevertheless, the basic 101 MPQUIC [MPQUIC-Design] acts much like MPTCP, except it uses QUIC (as 102 opposed to TCP). That said, the current MPQUIC implementation does 103 not support application policy-aware transport. 105 A straight solution for MPQUIC to enable the interaction between 106 applications and transport is to let applications to access/change 107 every single logic of the packet scheduling and path management, or 108 export callback functions as in [SMAPP]. This however will result in 109 a complex mix between applications and transport because of limited 110 abstraction. And perhaps more importantly, it requires application 111 developers to understand the details of the underlying transport. 113 This document describes an application policy-awareness method for 114 Multipath QUIC, to enable taking applications' demands into account 115 when managing paths or scheduling packets in Multipath QUIC. The 116 method remains compliant with the current Multipath Extensions for 117 QUIC [I-D.deconinck-quic-multipath] design. 119 2. Notational Conventions 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. What is Application Policy-awareness in Multipath QUIC 127 We advocate a more practical alternative (See Figure 1), where 1). 128 the `control plane' provides primitives to applications to express 129 their policies (intent); 2). the `data plane' abstracts execution 130 models for application policies and generates the corresponding 131 composed `actions'. 133 per-stream intent per-conn policy 134 Control e.g. stream prioirity e.g. path preference, path mode, 135 Plane deadline-aware etc 136 | | 137 -----------|----------------------------------------|------------- 138 V V 139 Data +--------+ - +------------------------+ 140 Plane | | | | | 141 +--------+ | | +-----+ | 142 | | +->| ... | | 143 +--------+ | | | +-----+ | 144 | | | | | +-----+ | 145 +--------+ | | +->| ... | | 146 | | | +-----+ | 147 +--------+ | +----------+ chunks |+----------+ | | 148 | | ->| stream |------->|| packet |-+ ... | 149 +--------+ | |scheduling| ||scheduling| | | 150 ... | +----------+ |+----------+ | +-----+ | 151 +--------+ | | +->| ... | | 152 | | | | | +-----+ | 153 +--------+ | | | +-----+ | 154 | | +->| ... | | 155 +--------+ | | +-----+ | 156 | | | | path manager | 157 +--------+ - +------------------------+ 158 streams 160 Figure 1: Application Policy Awareness in Multi-path QUIC framework 162 4. Per-connection Policy 164 An application imposes per-connection policy through the primitives 165 provided by the control plane. Some examples of policies are path 166 preference (e.g. a Wi-Fi path is preferred twice than a cellular 167 path), path model (e.g. full mesh, ndiffports, backup). The packet 168 scheduling component and the path manager at the data plane will act 169 based on these indications for path selection and data transmission. 170 We assume the policies are 'soft'---the policies are not a must. 171 Instead, the data plane will follow the policies as much as possible. 173 Let us take real-time interaction applications as an example to 174 illustrate the basic idea. The applications are indeed delay 175 sensitive but data volume is often low. 3 types of policies may be 176 used by different applications, as shown in Table 1 where we assume 177 only two paths are available (Wi-Fi and Cellular) 178 +-----+-----------------+-------------+------------+----------------+ 179 | No. | Application | Application | Underlying | Underlying | 180 | | defined policy: | defined | action: | action: Path | 181 | | Path mode | policy: | Packet | mngm. | 182 | | | Path | Scheduling | | 183 | | | Preference | | | 184 +-----+-----------------+-------------+------------+----------------+ 185 | 1 | Wi-Fi=full, | Wi-Fi=1, | full | / | 186 | | Cellular=full | Cellular=1 | redundant | | 187 | | | | | | 188 | 2 | Wi-Fi=full, | Wi-Fi=1, | full | activate | 189 | | Cellular=backup | Cellular=1 | redundant | backup | 190 | | | | | interfaces | 191 | | | | | when the | 192 | | | | | active one's | 193 | | | | | performance is | 194 | | | | | lower than X | 195 | | | | | for 5s | 196 | | | | | | 197 | 3 | Wi-Fi=full, | Wi-Fi=2, | partially | / | 198 | | Cellular=full | Cellular=1 | redundant | | 199 +-----+-----------------+-------------+------------+----------------+ 201 Table 1: Example policies of a real-time interaction application 203 The first type of policies would like to use two paths equally, and 204 because the applications are delay sensitive, the actions will be 205 'full redundant' for the packet scheduling---two paths send the same 206 data. The second type of policies, on the other hand, would like to 207 use the Wi-Fi interface (possibly because of data charge) if 208 possible. But if two paths have to be activated at the same time due 209 to the lower performance of Wi-Fi, then the two paths are with same 210 the preference. So, the corresponding actions will be will be 'full 211 redundant' for the packet scheduling, and the path management 212 component will monitor the performance of the active interface and 213 activate the backup one if the performance is lower than a threshold 214 for a short period of time (e.g. 5 seconds). The third type of 215 policies would like to use the two interfaces at the same time, but 216 Wi-Fi is preferred twice as the cellular one. The actions will take 217 this into consideration, and implement partial redundant transmission 218 over the cellular Interface. 220 Likewise, we can define a mapping between the policies of different 221 types of applications and the actions in the data plane. We leave 222 the design of such a mapping to the designers. 224 TODO: Add design of such a mapping. 226 5. Per-stream Intent 228 Per-stream intent is a unique feature provided by (MP)QUIC---it is 229 implemented through the multiple streams in QUIC. Streams can be 230 associated with priorities to implement applications intent. For 231 instance, objects in a web page may be dependent on others and thus 232 have different priorities [MPQUIC-Scheduler]. A priority-aware 233 packet scheduling algorithm will improve the performance notably. 235 High priority /\ +---------+ 236 || | | 237 || +---------+ 238 || +---------+ 239 || | | 240 || +---------+ 241 || ... User-defined priority 242 || +---------+ 243 Low priority || | | 244 || +---------+ 245 ----------------------------------------------------------- 246 High priority /\ +---------+ 247 || | | 248 || +---------+ 249 || +---------+ 250 || | | 251 || +---------+ 252 || ... Default priority 253 || +---------+ 254 Low priority || | | 255 || +---------+ 257 Figure 2: Stream priority 259 We envision a priority management scheme of two separated priority 260 ranges (see Figure 2). The user-defined priority ranges are those 261 streams that the applications explicitly designate the priorities, 262 where the default priority ranges include the streams with no 263 priority values set by the applications. Only when the streams in 264 the user-defined ranges have no data sent, the data in the streams in 265 the default priority ranges can be sent. In the same range, one can 266 use the weighted round robin for scheduling---the higher-priority 267 streams get more quantum for data sending in each round. One can 268 also dynamically set/change the priorities of the streams in the 269 default priority ranges to enable short stream first if needed. 271 We list in Table 2 some applications that can be benefited from the 272 above priority-aware stream management scheme. 274 +---------------------+-----------------------------+----------------+ 275 | Application | Priority setting | Benefits | 276 +---------------------+-----------------------------+----------------+ 277 | Web | Setting stream priority | Reduced page | 278 | | based on the objects' | load time | 279 | | priorities | | 280 | | [MPQUIC-Scheduler] | | 281 | | | | 282 | Photo album | Default setting; dynamical | Reduced load | 283 | | changing priority to mimic | time of the | 284 | | shorted stream first like | first image; | 285 | | in flow scheduling in data | images of | 286 | | centers [CDC] | small size | 287 | | | will be | 288 | | | displayed | 289 | | | first | 290 | | | | 291 | Live streaming | The chunks or GoPs with the | Low startup | 292 | (viewing) / VoD | closest deadline are put | delay, low | 293 | | into the stream with higher | buffering | 294 | | priorities. This | ratio | 295 | | essentially implements | | 296 | | deadline-aware data | | 297 | | transmission | | 298 | | | | 299 | Live streaming: | The original segments are | Enhanced | 300 | broadcaster->server | put into the streams in the | shift-viewing | 301 | | user-defined priority | quality of | 302 | | range, while the enhanced | services | 303 | | segments are put into the | [Vantage] | 304 | | streams in the default | | 305 | | priority range | | 306 +---------------------+-----------------------------+----------------+ 308 Table 2: Example applications benefited from priority-aware stream 309 management scheme 311 TODO: Add priority management solution. 313 6. IANA Considerations 315 This document makes no request of IANA. 317 7. Informative References 319 [AD-MPTCP] 320 Froemmgen, A., Rizk, A., Erbshaeusser, T., Weller, M., 321 Koldehofe, B., Buchmann, A., and R. Steinmetz, "A 322 programming model for application-defined multipath TCP 323 scheduling", Proceedings of the 18th ACM/IFIP/USENIX 324 Middleware Conference (Middleware '17). Association for 325 Computing Machinery, New York, NY, USA, 134-146., 2017, 326 . 328 [BSC] Guo, Y., Nikravesh, A., Mao, Z., Qian, F., and S. Sen, 329 "Accelerating Multipath Transport Through Balanced Subflow 330 Completion", Proceedings of the 23rd Annual International 331 Conference on Mobile Computing and Networking (MobiCom 332 '17). Association for Computing Machinery, New York, NY, 333 USA, 141-153., 2017, 334 . 336 [CDC] Bai, W., Chen, L., Chen, K., Han, D., Tian, C., and H. 337 Wang, "Information-agnostic flow scheduling for commodity 338 data centers", Proceedings of the 12th USENIX Conference 339 on Networked Systems Design and Implementation (NSDI'15). 340 USENIX Association, USA, 455-468., 2015. 342 [ECF] Lim, Y., Nahum, E., Towsley, D., and R. Gibbens, "ECF: An 343 MPTCP Path Scheduler to Manage Heterogeneous Paths", 344 Proceedings of the 13th International Conference on 345 emerging Networking EXperiments and Technologies (CoNEXT 346 '17). Association for Computing Machinery, New York, NY, 347 USA, 147-159., 2017, 348 . 350 [I-D.deconinck-quic-multipath] 351 De Coninck, Q. and O. Bonaventure, "Multipath Extensions 352 for QUIC (MP-QUIC)", draft-deconinck-quic-multipath-03 353 (work in progress), August 2019. 355 [MP-DASH] Han, B., Qian, F., Ji, L., and V. Gopalakrishnan, "MP- 356 DASH: Adaptive Video Streaming Over Preference-Aware 357 Multipath", Proceedings of the 12th International on 358 Conference on emerging Networking EXperiments and 359 Technologies (CoNEXT '16). Association for Computing 360 Machinery, New York, NY, USA, 129-143., 2016, 361 . 363 [MPQUIC-Design] 364 De Coninck, Q. and O. Bonaventure, "Multipath QUIC: Design 365 and Evaluation", Proceedings of the 13th International 366 Conference on emerging Networking EXperiments and 367 Technologies (CoNEXT '17). Association for Computing 368 Machinery, New York, NY, USA, 160-166., 2017, 369 . 371 [MPQUIC-Scheduler] 372 Wang, J., Gao, Y., and C. Xu, "A Multipath QUIC Scheduler 373 for Mobile HTTP/2", Proceedings of the 3rd Asia-Pacific 374 Workshop on Networking 2019 (APNet '19). Association for 375 Computing Machinery, New York, NY, USA, 43-49., 2019, 376 . 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 [SMAPP] Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O. 384 Bonaventure, "SMAPP: towards smart multipath TCP-enabled 385 applications", Proceedings of the 11th ACM Conference on 386 Emerging Networking Experiments and Technologies (CoNEXT 387 '15). Association for Computing Machinery, New York, NY, 388 USA, Article 28, 1-7., 2015, 389 . 391 [Vantage] Ray, D., Kosaian, J., Rashmi, K., and S. Seshan, "Vantage: 392 optimizing video upload for time-shifted viewing of social 393 live streams", Proceedings of the ACM Special Interest 394 Group on Data Communication (SIGCOMM '19). Association for 395 Computing Machinery, New York, NY, USA, 380-393., 2019, 396 . 398 [WN] Cui, Y., "Wireless Network Instabilities in the Wild: 399 Measurement, Applications (Non)Resilience, and OS Remedy", 400 2019 IEEE/ACM Transactions on Networking, vol. 27, no. 1, 401 pp. 214-230., 2019, <10.1109/TNET.2018.2885872>. 403 Authors' Addresses 405 Qing An 406 Alibaba Inc. 408 Email: anqing.aq@alibaba-inc.com 409 Zhenyu Li 410 ICT-CAS 412 Email: zyli@ict.ac.cn 414 Yanmei Liu 415 Alibaba Inc. 417 Email: miaoji.lym@alibaba-inc.com