Multipath Communication with Satellite and Terrestrial Links
draft-deutschmann-sat-ter-multipath-00

Document Type Active Internet-Draft (individual)
Authors Jörg Deutschmann  , Kai-Steffen Hielscher  , Reinhard German 
Last updated 2020-10-19
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                           J. Deutschmann
Internet-Draft                                            K-S. Hielscher
Intended status: Informational                                 R. German
Expires: April 22, 2021                      Univ. of Erlangen-Nuernberg
                                                        October 19, 2020

      Multipath Communication with Satellite and Terrestrial Links
                 draft-deutschmann-sat-ter-multipath-00

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 April 22, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Deutschmann, et al.      Expires April 22, 2021                 [Page 1]
Internet-Draft       Satellite/Terrestrial Multipath        October 2020

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Comparison of Link Characteristics  . . . . . . . . . . . . .   4
   4.  Backlog-Based Scheduling  . . . . . . . . . . . . . . . . . .   4
   5.  Applicability to Non-TCP / Enrypted Traffic . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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

    Motivation for combining very heterogeneous Internet access links.

                                 Figure 1

   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

Deutschmann, et al.      Expires April 22, 2021                 [Page 2]
Internet-Draft       Satellite/Terrestrial Multipath        October 2020

   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     ########

                 Multipath-enabled PEPs in access network.

                                 Figure 2

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

   o  For the satellite link, PEPs and protocols suitable for high-
      latency links are required, anyway.

   o  As the PEPs are located at the Access network, there is better
      knowledge of the link characteristics used for multipath
      communication.

   o  The presence of PEPs enables the aggregation of transport layer
      data which can be used for scheduling decisions, as described
      later in Section 4.

   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

Deutschmann, et al.      Expires April 22, 2021                 [Page 3]
Internet-Draft       Satellite/Terrestrial Multipath        October 2020

   [RFC1928] or the 0-RTT TCP Convert Protocol [RFC8803] are under
   investigation.

3.  Comparison of Link Characteristics

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

   o  Low data rate, low latency terrestrial link: Suitable for
      connection setups and small objects.  Unsuitable for large amounts
      of data.  The transmission duration can be a approximated as

         TransmissionDurationTer = DelayTer + Size/DatarateTer

   o  High data rate, high latency link (geostationary satellite):
      Favorable for large objects.  Unsuitable for latency-sensitive
      data.  The transmission duration can be approximated as

         TransmissionDurationSat = DelaySat + Size/DatarateSat

   By putting both together

      TransmissionDurationTer = TransmissionDurationSat

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

      ThresholdTerSat
      = (DelaySat - DelayTer) / ((1/DatarateTer) - (1/DatarateSat))

   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

Deutschmann, et al.      Expires April 22, 2021                 [Page 4]
Internet-Draft       Satellite/Terrestrial Multipath        October 2020

   satellite link.  For a detailed description and performance
   evaluation see [MMB2020].  Other multipath schedulers are currently
   also under investigation.

5.  Applicability to Non-TCP / Enrypted Traffic

   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.

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, March 1996,
              <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, March
              2020, <https://www.rfc-editor.org/info/rfc8684>.

9.2.  Informative References

Deutschmann, et al.      Expires April 22, 2021                 [Page 5]
Internet-Draft       Satellite/Terrestrial Multipath        October 2020

   [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, 2020,
              <https://doi.org/10.1109/MCOMSTD.001.1900036>.

   [I-D.deconinck-quic-multipath]
              Coninck, Q. and O. Bonaventure, "Multipath Extensions for
              QUIC (MP-QUIC)", draft-deconinck-quic-multipath-05 (work
              in progress), August 2020.

   [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,
              2020, <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, June 2001,
              <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, July 2020,
              <https://www.rfc-editor.org/info/rfc8803>.

Authors' Addresses

   Joerg Deutschmann
   Univ. of Erlangen-Nuernberg

   Email: joerg.deutschmann@fau.de

   Kai-Steffen Hielscher
   Univ. of Erlangen-Nuernberg

   Email: kai-steffen.hielscher@fau.de

   Reinhard German
   Univ. of Erlangen-Nuernberg

   Email: reinhard.german@fau.de

Deutschmann, et al.      Expires April 22, 2021                 [Page 6]