Multipath Communication with Satellite and Terrestrial Links

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, low data rate, _______/ low latency low latency ]]> 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 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 ) 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 , 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.

Multipath-enabled PEPs in access network. A PEP-based architecture, similar to Hybrid Access networks , as shown in is chosen because of several reasons: For the satellite link, PEPs and protocols suitable for high-latency links are required, anyway. As the PEPs are located at the Access network, there is better knowledge of the link characteristics used for multipath communication. The presence of PEPs enables the aggregation of transport layer data which can be used for scheduling decisions, as described later in . Unlike Multipath TCP , 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 or the 0-RTT TCP Convert Protocol are under investigation.

There is a great difference between both delay and data rate of aforementioned links. 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 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.

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 . Other multipath schedulers are currently also under investigation.

The architecture described in 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 ), which is currently work in progress.

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

This memo includes no request to IANA.

The same security considerations as in apply.