TN SatLink TCP Acceleration V12

7
15 January 2015 TCP & HTTP Acceleration Page 1 EMC Satcom Technologies Vollsveien 21 N-1366 Lysaker, Norway

description

TN SatLink TCP Acceleration

Transcript of TN SatLink TCP Acceleration V12

  • 15 January 2015 TCP & HTTP Acceleration Page 1

    EMC Satcom Technologies

    Vollsveien 21 N-1366

    Lysaker, Norway

  • 15 January 2015 TCP & HTTP Acceleration Page 2

    TCP & HTTP Acceleration

    SatLink Technical Note Doc # 200149

  • 15 January 2015 TCP & HTTP Acceleration Page 3

    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 4

    Figure 1: SatLink TCP Acceleration in Star Topology

    TCP

    IP

    Layer 2

    Physical

    IP Host

    Server SatLinkVSAT IDU

    PC

    Satellite

    TCPa

    IP

    Layer 2

    Physical

    FLS

    RLS

    NetAcc

    IP

    Layer 2

    Physical

    TCPa

    IP

    Layer 2

    Physical

    TCP

    IP

    Layer 2

    Physical

    SatLink Optimized TCP Acceleration & Shaping

    * FWD Link Capacity Feedback Loop(FLS to NetAcc)

    *

    IP Host

    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

    IP Host

    PC

    Satellite

    Single-Hop Mesh Link

    TCPa

    IP

    Layer 2

    Physical

    TCP

    IP

    Layer 2

    Physical

    SatLink Optimized TCP Acceleration & Shaping IP Host

    PC

    TCP

    IP

    Layer 2

    Physical

    SatLinkVSAT IDU

    TCPa

    IP

    Layer 2

    Physical

    SatLinkVSAT IDU

    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 5

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

    up 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 6

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

    TCP 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 standards-

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

    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.