idnits 2.17.1 draft-deutschmann-sat-ter-multipath-01.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 date (April 18, 2021) is 1097 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-06 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Deutschmann 3 Internet-Draft K-S. Hielscher 4 Intended status: Informational R. German 5 Expires: October 20, 2021 Univ. of Erlangen-Nuernberg 6 April 18, 2021 8 Multipath Communication with Satellite and Terrestrial Links 9 draft-deutschmann-sat-ter-multipath-01 11 Abstract 13 Multipath communication enables the combination of low data rate, low 14 latency terrestrial links and high data rate, high latency links 15 (e.g., geostationary satellite links) to provide a full-fledged 16 Internet access. However, the combination of such heterogeneous 17 links is challenging from a technical point of view. This document 18 describes a possible solution, i.e. an architecture and scheduling 19 mechanism. The applicability of this approach to encrypted transport 20 protocols (e.g., Multipath QUIC) is also discussed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 20, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Comparison of Link Characteristics . . . . . . . . . . . . . 4 59 4. Backlog-Based Scheduling . . . . . . . . . . . . . . . . . . 4 60 5. Applicability non-TCP / Enrypted Traffic and QUIC . . . . . . 5 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 9.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Some areas (e.g., rural areas) suffer from poor Internet connectivity 72 (e.g., low data rate DSL lines or old generation cellular networks). 73 On the other hand, geostationary satellite Internet access is 74 available all over the world with data rates of up to 50 Mbit/s and 75 more. Obviously, the combination of both Internet access types seems 76 beneficial. 78 high data rate, ______ 79 high latency \ 80 +-----> high data rate, 81 low data rate, _______/ low latency 82 low latency 84 Motivation for combining very heterogeneous Internet access links. 86 Figure 1 88 However, the combination of very heterogeneous link types is 89 challenging given currently deployed transport protocols. Some 90 applications could be strictly assigned to either the high data rate, 91 high latency link (e.g., bulk data transfer) or the low data rate, 92 low latency link (e.g., VoIP). Other applications, especially 93 Internet browsing, have more versatile requirements. Connection 94 setup and interactive content require low latency, but transferring 95 large objects requires high data rate. The combination of links as 96 shown in Figure 1 cannot outperform a fast terrestrial Internet 97 access which is able to provide high data rate and low latency 98 simultaneously (e.g, as required for video conferencing or cloud 99 gaming), but there still can be a significant improvement regarding 100 quality of service and quality of experience. 102 Multipath protocols (e.g., Multipath TCP [RFC8684]) can be used for 103 simultaneously using multiple Internet access links. However, 104 scheduling is non-trivial in case of very heterogeneous links. In 105 this document, an architecture based on Performance Enhancing Proxies 106 and a scheduling mechanism called back-log based scheduling is 107 described. 109 This document is based on the publication [MMB2020], which also 110 contains performance evaluation results obtained with the discrete 111 event simulator ns-3. Performance evaluation results with a Linux- 112 based implementation and real networks will be published as soon as 113 possible. 115 2. Architecture 117 Sat 118 / \ 119 #######___/ \___######## 120 #Local# #Remote# 121 Host(s)----# PEP #-------------# PEP #----Host(s) 122 ####### Ter ######## 124 Multipath-enabled PEPs in access network. 126 Figure 2 128 A PEP-based architecture, similar to Hybrid Access networks [HA2020], 129 as shown in Figure 2 is chosen because of several reasons: 131 o For the satellite link, PEPs and protocols suitable for high- 132 latency links are required, anyway. 134 o As the PEPs are located at the Access network, there is better 135 knowledge of the link characteristics used for multipath 136 communication. 138 o The presence of PEPs enables the aggregation of transport layer 139 data which can be used for scheduling decisions, as described 140 later in Section 4. 142 Unlike Multipath TCP [RFC8684], the multipath connection between both 143 PEPs is provisioned statically. A way to interoperate between PEPs 144 is out of scope for this document, configurations with SOCKS 146 [RFC1928] or the 0-RTT TCP Convert Protocol [RFC8803] are under 147 investigation. 149 3. Comparison of Link Characteristics 151 There is a great difference between both delay and data rate of 152 aforementioned links. 154 o Low data rate, low latency terrestrial link: Suitable for 155 connection setups and small objects. Unsuitable for large amounts 156 of data. The transmission duration can be a approximated as 158 TransmissionDurationTer = DelayTer + Size/DatarateTer 160 o High data rate, high latency link (geostationary satellite): 161 Favorable for large objects. Unsuitable for latency-sensitive 162 data. The transmission duration can be approximated as 164 TransmissionDurationSat = DelaySat + Size/DatarateSat 166 By putting both together 168 TransmissionDurationTer = TransmissionDurationSat 170 a threshold size can be obtained, which describes over which link a 171 transmission finishes first: 173 ThresholdTerSat 174 = (DelaySat - DelayTer) / ((1/DatarateTer) - (1/DatarateSat)) 176 with the assumption that DatarateSat > DatarateTer and DelaySat > 177 DatarateTer. 179 Example: 180 DatarateTer = 1 Mbit/s, DelayTer = 15 ms, 181 DatarateSat = 20 Mbit/s, DelaySat = 300ms, 182 leads to ThresholdTerSat = 37.5 kByte, which means that a sum of 183 packets smaller than this size finishes on the terrestrial link 184 first, whereas a sum of packets greater than this size finishes on 185 the satellite link first. 187 4. Backlog-Based Scheduling 189 With the help of PEPs, data from TCP senders can be aggregated. 190 Packets are then sent on the appropriate link based on 191 ThresholdTerSat. As PEPs handle individual TCP flows, new 192 connections and flows with little backlog are sent via the 193 terrestrial connection, flows with large backlog are sent via the 194 satellite link. For a detailed description and performance 195 evaluation see [MMB2020]. Other multipath schedulers are currently 196 also under investigation, as the combination of very heterogeneous 197 links requires specialized scheduling strategies. 199 5. Applicability non-TCP / Enrypted Traffic and QUIC 201 The architecture described in Section 2 only works for non-encrypted 202 TCP traffic. As it is the case for every PEP, it does not work for 203 enrypted traffic (e.g., VPNs or QUIC). 205 However, the use case of bonding very heterogenous links and the 206 scheduling mechanism can also be applied to end-to-end protocols 207 (e.g., Multipath QUIC [I-D.deconinck-quic-multipath]), which is 208 currently work in progress. 210 With Multipath QUIC, data and acknowledgements can be sent on 211 different paths. By this, data sent over the high-latency satellite 212 link can be acknowledged by the low-latency satellite link, 213 effectively halving the round trip time. 215 6. Acknowledgements 217 This work has been funded by the Federal Ministry of Economics and 218 Technology of Germany in the project Transparent Multichannel IPv6 219 (FKZ 50YB1705). 221 7. IANA Considerations 223 This memo includes no request to IANA. 225 8. Security Considerations 227 The same security considerations as in [RFC3135] apply. 229 9. References 231 9.1. Normative References 233 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 234 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 235 DOI 10.17487/RFC1928, March 1996, 236 . 238 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 239 Paasch, "TCP Extensions for Multipath Operation with 240 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 241 2020, . 243 9.2. Informative References 245 [HA2020] Keukeleire, N., Hesmans, B., and O. Bonaventure, 246 "Increasing Broadband Reach with Hybrid Access Networks", 247 IEEE Communications Standards Magazine vol. 4, no. 1, pp. 248 43-49, 2020, 249 . 251 [I-D.deconinck-quic-multipath] 252 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 253 QUIC (MP-QUIC)", draft-deconinck-quic-multipath-06 (work 254 in progress), November 2020. 256 [MMB2020] Deutschmann, J., Hielscher, KS., and R. German, "An ns-3 257 Model for Multipath Communication with Terrestrial and 258 Satellite Links", In: Hermanns H. (eds) Measurement, 259 Modelling and Evaluation of Computing Systems. Lecture 260 Notes in Computer Science, vol 12040. Springer, Cham, 261 2020, . 263 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 264 Shelby, "Performance Enhancing Proxies Intended to 265 Mitigate Link-Related Degradations", RFC 3135, 266 DOI 10.17487/RFC3135, June 2001, 267 . 269 [RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., 270 Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", 271 RFC 8803, DOI 10.17487/RFC8803, July 2020, 272 . 274 Authors' Addresses 276 Joerg Deutschmann 277 Univ. of Erlangen-Nuernberg 279 Email: joerg.deutschmann@fau.de 281 Kai-Steffen Hielscher 282 Univ. of Erlangen-Nuernberg 284 Email: kai-steffen.hielscher@fau.de 285 Reinhard German 286 Univ. of Erlangen-Nuernberg 288 Email: reinhard.german@fau.de