Internet-Draft Satellite/Terrestrial Multipath April 2021
Deutschmann, et al. Expires 20 October 2021 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-deutschmann-sat-ter-multipath-01
Published:
Intended Status:
Informational
Expires:
Authors:
J. Deutschmann
Univ. of Erlangen-Nuernberg
K-S. Hielscher
Univ. of Erlangen-Nuernberg
R. German
Univ. of Erlangen-Nuernberg

Multipath Communication with Satellite and Terrestrial Links

Abstract

Multipath communication enables the combination of low data rate, low latency terrestrial links and high data rate, high latency links (e.g., geostationary satellite links) to provide a full-fledged Internet access. However, the combination of such heterogeneous links is challenging from a technical point of view. This document describes a possible solution, i.e. an architecture and scheduling mechanism. The applicability of this approach to encrypted transport protocols (e.g., Multipath QUIC) is also discussed.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 3 October 2021.

Table of Contents

1. Introduction

Some areas (e.g., rural areas) suffer from poor Internet connectivity (e.g., low data rate DSL lines or old generation cellular networks). On the other hand, geostationary satellite Internet access is available all over the world with data rates of up to 50 Mbit/s and more. Obviously, the combination of both Internet access types seems beneficial.

          high data rate, ______
          high latency          \
                                 +-----> high data rate,
          low data rate, _______/        low latency
          low latency
Figure 1

Motivation for combining very heterogeneous Internet access links.

However, the combination of very heterogeneous link types is challenging given currently deployed transport protocols. Some applications could be strictly assigned to either the high data rate, high latency link (e.g., bulk data transfer) or the low data rate, low latency link (e.g., VoIP). Other applications, especially Internet browsing, have more versatile requirements. Connection setup and interactive content require low latency, but transferring large objects requires high data rate. The combination of links as shown in Figure 1 cannot outperform a fast terrestrial Internet access which is able to provide high data rate and low latency simultaneously (e.g, as required for video conferencing or cloud gaming), but there still can be a significant improvement regarding quality of service and quality of experience.

Multipath protocols (e.g., Multipath TCP [RFC8684]) can be used for simultaneously using multiple Internet access links. However, scheduling is non-trivial in case of very heterogeneous links. In this document, an architecture based on Performance Enhancing Proxies and a scheduling mechanism called back-log based scheduling is described.

This document is based on the publication [MMB2020], which also contains performance evaluation results obtained with the discrete event simulator ns-3. Performance evaluation results with a Linux-based implementation and real networks will be published as soon as possible.

2. Architecture

                                Sat
                               /   \
                    #######___/     \___########
                    #Local#             #Remote#
         Host(s)----# PEP #-------------# PEP  #----Host(s)
                    #######     Ter     ########
Figure 2

Multipath-enabled PEPs in access network.

A PEP-based architecture, similar to Hybrid Access networks [HA2020], as shown in Figure 2 is chosen because of several reasons:

Unlike Multipath TCP [RFC8684], the multipath connection between both PEPs is provisioned statically. A way to interoperate between PEPs is out of scope for this document, configurations with SOCKS [RFC1928] or the 0-RTT TCP Convert Protocol [RFC8803] are under investigation.

There is a great difference between both delay and data rate of aforementioned links.

By putting both together

a threshold size can be obtained, which describes over which link a transmission finishes first:

with the assumption that DatarateSat > DatarateTer and DelaySat > DatarateTer.

Example:DatarateTer = 1 Mbit/s, DelayTer = 15 ms,DatarateSat = 20 Mbit/s, DelaySat = 300ms,leads to ThresholdTerSat = 37.5 kByte, which means that a sum of packets smaller than this size finishes on the terrestrial link first, whereas a sum of packets greater than this size finishes on the satellite link first.

4. Backlog-Based Scheduling

With the help of PEPs, data from TCP senders can be aggregated. Packets are then sent on the appropriate link based on ThresholdTerSat. As PEPs handle individual TCP flows, new connections and flows with little backlog are sent via the terrestrial connection, flows with large backlog are sent via the satellite link. For a detailed description and performance evaluation see [MMB2020]. Other multipath schedulers are currently also under investigation, as the combination of very heterogeneous links requires specialized scheduling strategies.

5. Applicability non-TCP / Enrypted Traffic and QUIC

The architecture described in Section 2 only works for non-encrypted TCP traffic. As it is the case for every PEP, it does not work for enrypted traffic (e.g., VPNs or QUIC).

However, the use case of bonding very heterogenous links and the scheduling mechanism can also be applied to end-to-end protocols (e.g., Multipath QUIC [I-D.deconinck-quic-multipath]), which is currently work in progress.

With Multipath QUIC, data and acknowledgements can be sent on different paths. By this, data sent over the high-latency satellite link can be acknowledged by the low-latency satellite link, effectively halving the round trip time.

6. Acknowledgements

This work has been funded by the Federal Ministry of Economics and Technology of Germany in the project Transparent Multichannel IPv6 (FKZ 50YB1705).

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

The same security considerations as in [RFC3135] apply.

9. References

9.1. Normative References

[RFC1928]
Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI 10.17487/RFC1928, , <https://www.rfc-editor.org/info/rfc1928>.
[RFC8684]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. Paasch, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, , <https://www.rfc-editor.org/info/rfc8684>.

9.2. Informative References

[HA2020]
Keukeleire, N., Hesmans, B., and O. Bonaventure, "Increasing Broadband Reach with Hybrid Access Networks", IEEE Communications Standards Magazine vol. 4, no. 1, pp. 43-49, , <https://doi.org/10.1109/MCOMSTD.001.1900036>.
[I-D.deconinck-quic-multipath]
Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft-deconinck-quic-multipath-06, , <http://www.ietf.org/internet-drafts/draft-deconinck-quic-multipath-06.txt>.
[MMB2020]
Deutschmann, J., Hielscher, KS., and R. German, "An ns-3 Model for Multipath Communication with Terrestrial and Satellite Links", In: Hermanns H. (eds) Measurement, Modelling and Evaluation of Computing Systems. Lecture Notes in Computer Science, vol 12040. Springer, Cham, , <https://doi.org/10.1007/978-3-030-43024-5_5>.
[RFC3135]
Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, , <https://www.rfc-editor.org/info/rfc3135>.
[RFC8803]
Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S., Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol", RFC 8803, DOI 10.17487/RFC8803, , <https://www.rfc-editor.org/info/rfc8803>.

Authors' Addresses

Joerg Deutschmann
Univ. of Erlangen-Nuernberg
Kai-Steffen Hielscher
Univ. of Erlangen-Nuernberg
Reinhard German
Univ. of Erlangen-Nuernberg