EMC Satcom Technologies

Vollsveien 21 N-1366
Lysaker, Norway

15 January 2015

TCP & HTTP Acceleration

Page 1

TCP & HTTP Acceleration

SatLink Technical Note
Doc # 200149

15 January 2015

TCP & HTTP Acceleration

Page 2

Background
TCP (Transmission Control Protocol) is a critically important protocol in TCP/IP (Internet Protocol Suite), providing reliable
bi-directional data transfer over IP (Internet Protocol). Well-known higher layer protocols that use TCP include: HTTP (for
the web); FTP (for file transfers); various mail protocols (SMTP, POP3); plus many others less well known. The throughput of
TCP connections can be quite slow over satellite links unless special steps are taken to provide acceleration. This is
because standard TCP implementations behave as follows:

The flow of TCP data is initially slow and is gradually incremented during the initial TCP exchanges until the
characteristics of the connection are learned by the transmitting TCP end-point.

Any sender of TCP data requires acknowledgements (ACKs) for at least some of a certain maximum flight size of
contiguous data sent, before sending any more data on the connection.

Any TCP packet loss (e.g., due to bit errors on the link or buffer overflows) will cause a slowdown of the transfer and
more severe loss will trigger extensive re-transmission, including data already received successfully.

The long (e.g., half-second) round-trip latency of geosynchronous satellite links worsens all of these TCP behavior patterns
and thus requires a TCP Acceleration solution that is highly optimized for satellite networks, especially when Adaptive
Coding and Modulation (ACM) is being used, because ACM alters satellite link capacity dynamically.
Furthermore, the requirements on the QoS (Quality of Service) for the network become especially important if TCP traffic is
sharing the same satellite links with other types of traffic (e.g., UDP for real-time voice and video) that are not subject to the
same flow-controls as TCP, and which needs special treatment to assure the lowest possible jitter and delay. Good QoS also
requires control over the minimum and maximum rates of transfer for various different traffic aggregates (i.e., QoS Classes)
on the network, which in turn requires traffic shaping of TCP flows.

TCP Acceleration in SatLink Networks

SatLink TCP Acceleration (TCPa) is performed by using TCP interception as described by the IETF in RFC 3135 on
Performance Enhancing Proxies. This is a common approach within the satellite industry. TCP Acceleration may be
implemented using many different methods for the acceleration itself, some better than others. Good TCP Acceleration is
tightly coordinated with traffic shaping to enhance QoS and also reduce total bandwidth consumption vs. the usual TCP
behavior (e.g., with less re-transmitted data and fewer acknowledgements used).
TCP Interception in SatLink networks is performed by the SatLink Network Accelerator (NetAcc) located at the Hub site and
by each SatLink VSAT IDU at the remote sites. The current NetAcc module (i.e., SatLink 6450 NetAcc) is capable of
supporting up to 50,000 TCP connections concurrently, including 25,000 accelerated connections over the satellite, and
25,000 corresponding connections to IP hosts on its terrestrial side. It can shape traffic individually for up to 10,000 VSATs
and many dozens of VSAT Groups for each of four (4) QoS Classes. Figure 1 shows the TCPa proxy software in the NetAcc
and one VSAT IDU.

15 January 2015

TCP & HTTP Acceleration

Page 3

Figure 1: SatLink TCP Acceleration in Star Topology

SatLink Optimized
TCP Acceleration & Shaping

IP Host
TCP

TCPa

IP

IP

Layer 2
Physical

IP Host
TCPa

TCP

IP

IP

IP

Layer 2

Layer 2

Layer 2

Layer 2

Physical

Physical

Physical

Physical

SatLink
VSAT IDU

PC

Satellite

FLS

NetAcc
RLS

Server

* FWD Link Capacity Feedback Loop

(FLS to NetAcc)

The SatLink TCPa software also works in SatLink mesh topologies, with a single-hop between VSATs, where the proxy
software in each mesh VSAT IDU communicates directly with the proxy in another mesh VSAT IDU. In this case, the SatLink
NetAcc is not involved.
This is shown in Figure 2, and has the same traffic shaping integration with the VSAT IDU.
Figure 2: SatLink TCP Acceleration for Mesh Topologies

SatLink Optimized
TCP Acceleration & Shaping

IP Host

IP Host

TCP

TCPa

TCPa

TCP

IP

IP

IP

IP

Layer 2

Layer 2

Layer 2

Layer 2

Physical

Physical

Physical

Physical

Satellite

PC

SatLink
VSAT IDU

Single-Hop
Mesh Link

SatLink
VSAT IDU

PC

Each VSAT IDU, whether used for mesh or star topology, is providing shaping for each SatLink QoS Class (on both its TCP
and UDP traffic) to match transmission load with available timeslot assignments from the SatLink Hub. However, the
shaping of TCP traffic by the IDU is the most critical, which must be done without packet loss. In this way, the proper
amount of capacity is provided for the desired UDP traffic, such as the real-time VoIP or video conferencing media.

15 January 2015

TCP & HTTP Acceleration

Page 4

Technical Features & Benefits

SatLink TCP Acceleration (TCPa) provides the following features and benefits, independent of the TCP/IP stack in use on the
IP hosts at the end-points.

A very large TCP flight size by using very large receive window size for the satellite link, resulting in 4 Mbps of IP
throughput per TCP connection, with further increases to 10 Mbps planned.

Very fast ramp-up for new TCP connections to the maximum data throughput, which is not affected by satellite link
delay.

NOTE: This is feasible because SatLink TCPa is combined with shaping of the channel and VSAT traffic otherwise this
aggressive ramp-up would be counterproductive.

Rapid and sparse re-transmission by utilizing Selective Acknowledgements (SACK), including those for user hosts
that do not natively support SACK.

Robust handling of packet loss with limited throughput back-off in the event of packet loss on the satellite link.

Suppression of TCP ACKs on the satellite link and limiting of the maximum ACK rate to 10 ACKs per second for very
high throughput connections.

In addition, the SatLink TCPa system sustains most of these benefits for Hub-to-VSAT downloads even when it is not
possible to intercept TCP connections in the VSAT IDU (e.g., as occurs with secure VPN tunnels which pass through the
VSAT IDU, such as IPsec).
NOTE: This requires the VPN Appliance at the Hub Site to be located between the NetAcc and the FLS/RLS.
This is possible because SatLink TCP Acceleration is based on IETF standard methods and is compatible with standard TCP
Reno implementations (the predominant TCP variant). Therefore, the NetAcc can communicate directly with current
standard TCP/IP protocol stacks as built-in to modern IP hosts (i.e., end-user devices such as PCs, servers, PDAs, smart
phones, etc.) and thus accomplish both acceleration and other TCP behavior improvements for traffic sent over the Forward
Link, without involvement of the TCP proxy in the VSAT IDU.
Nonetheless, the TCP proxy functions in SatLink IDUs are employed because IP hosts do not actively utilize many newer TCP
standard features to obtain the fastest possible acceleration of TCP connections. Much higher gains are feasible between
two highly optimized TCP proxies due to larger window sizes for satellite links, rapid & sparse re-transmission, faster startup and less back-off on packet loss than with TCP RENO, plus greater reduction in the use of TCP ACKs.
Also, the SatLink TCP proxy functions (in the NetAcc and the VSAT IDU) are fully integrated with SatLinks traffic shaping
and QoS features, which is very helpful to assure that TCP loads placed on satellite links do not exceed the link capacity or
the QoS Class limits for a given traffic aggregate. Otherwise, TCP packet drops could be caused by the TCP proxy functions
(e.g., by sending packets at rates that exceed buffer limits in the FLS), which would have the negative effect of reducing
average TCP throughputs. In advanced satellite networks using ACM, this is extremely important, since total link capacity
varies with weather conditions, as does the logical link capacity to/from individual VSATs.

15 January 2015

TCP & HTTP Acceleration

Page 5

SatLink Compliance with TCP Standards

In addition to RFC 3135 on Performance Enhancing Proxies, the following IETF standards covering advanced features for
TCP are utilized to accomplish TCP Acceleration in a SatLink network. These are fully or partially supported by many IP
hosts to enable acceleration even when the TCP proxy in the VSAT IDU cannot be used.

Maximum Segment Size (MSS) announcements (RFC 879)

Window Scaling (RFC 1323)

Selective Acknowledgement (SACK) (RFC 2018)

In SatLink, these are used in combination with rules optimized to give the best performance on geosynchronous satellite
links, with their characteristic latency and low packet error rates when using modern FEC methods.

Proprietary Approaches to TCP Acceleration

In contrast, there are several proprietary approaches to TCP Acceleration in the market today which use special nonTCP protocols (e.g., UDP) with non-standard messages for communications between the two proxy functions. These
proprietary methods do not attain any higher performance or throughput than is feasible using the advanced standardsbased methods employed in SatLink. Also, these proprietary approaches are not compatible with the standard TCP/IP stacks
in IP Hosts and so they do not allow for convenient fall-back options when VPN encryption is employed or when the
acceleration capacity of the proxy function is full or overloaded.
Furthermore, many do not provide effective flow control to prevent packet loss under heavy load or when other traffic (e.g.,
RTP/UDP traffic) has higher priority.

SatLink TCP Acceleration Performance Results

The graph below highlights the performance gains that can be expected from SatLink TCP acceleration when using it with
SatLink TCPa proxies at both ends of the link. It shows the download of a 5 Mbyte file.
Figure 3: Five Mbyte File Download

15 January 2015

TCP & HTTP Acceleration

Page 6

The graph shows the file is transferred much faster than without acceleration due to:

Much faster start-up behavior

Much higher maximum throughput rate

Minimal impact from packet loss

Conclusion
SatLink TCP Acceleration (TCPa) enables very high IP throughput and reduces the number TCP ACKs (lowering total
overhead) under good link conditions. When link errors do occur (which is rare), the quantity of data that has to be
retransmitted, as well as the slowdowns that occur, are quite small. Furthermore, SatLink TCPa does not drop packets due
to congestion on satellite links (e.g., when ACM reduces link capacity) and maintains excellent QoS, due to tight coupling
with SatLink traffic shaping.
SatLink TCPa also functions well to accelerate TCP traffic and reduce overhead for downloads to VSATs, even when secure
VPN tunnels are being used through the VSAT IDU.

15 January 2015

TCP & HTTP Acceleration

Page 7