8

On a VSat link with 800ms RTT latency and 10mbps bandwidth, that means 1MB bandwidth-delay product (data in flight).

According to this useful (but closed) Q/A, packets are injected on both sides of the TCP connection to acknowledge the packets immediately, enabling the senders on both sides to send more at once. However, that would clear the senders buffer making retransmision impossible (from the sender without modification). Obviously some packets would be lost. So how does such an optimising terminal accommodate? What are VSat TCP optimisers actually doing? A network engineer cannot efficiently troubleshoot connection issues without knowing the full details about the magic happening inside.

Do they effectively need to create another virtual TCP connection with a sufficiently large window size? Do they use RAM for this or fast disk? Do they rely solely on tuned Forward Error Correction (and if that fails the connection breaks)?

Improve this question
1
  • 4
    The system is effectively a proxy. The internet sender is not talking to the vsat CPE, but to an intermediary that doesn't suffer the same transmission delay. (the actual implementation is much more complicated, but that's the simplest way to think about it.)
    – Ricky
    Mar 20 '21 at 14:04
13

Pre-ACKing is only possible because the near accelerator keeps the segment data in queue. Therefore, it can ACK in stead of the far destination, prompting the sender to advance the send window and send out more segments than would be possible by delay-bandwidth alone.

Of course, the near accelerator needs to keep track of its internal, larger send window that it uses to resend the data on its own if no ACK is eventually received. Yes, this is actually an additional, hidden TCP connection if you like, a bit like a proxy.

Most accelerators use some kind of black-box techniques the vendor won't tell you all about. But essentially, it's about data compression, deduplication and enlarged send windows. If you try to model the latter you will discover that it's not trivial at all.

Improve this answer
4
  • 1
    And also error correction. E.g. fountain codes can replace a given amount of lost packets, without the latency of retransmission.
    – jpa
    Mar 21 '21 at 8:44
  • @jpa Thanks for pointing that out but afaik not all accelerators can correct transmission errors.
    – Zac67 ♦
    Mar 21 '21 at 10:57
  • When I went to college; they said they fail out the connection on a drop.
    – Joshua
    Mar 21 '21 at 18:27
  • Pre-acking won't be able to happen for every packet because there needs to be rate limiting. Otherwise, and infinitely large buffer will be required and also latency will increase. A proxy buffer is only workable for large file uploads.
    – Kind Contributor
    Dec 25 '21 at 5:04
2

In short:

The burden falls upon the TCP PEP to recover any data which is dropped after the PEP [locally] acknowledges it

see https://www.rfc-editor.org/rfc/rfc3135.html#section-3.1.2

Enhancing TCP Over Satellite Channels using Standard Mechanisms

see RFC2488

This is a an RFC indicated as "Best Current Practice". All controls recommended for use on Satellite, from section [5] Mitigation Summary:

  • Path-MTU discovery
  • Forward Error Correction
  • Slow Start [Required]. Don't try to optimise this part of TCP, it won't balance well with other connections.
  • Congestion Avoidance [Required]
  • Fast Retransmit
  • Fast Recovery
  • TCP Large Windows - Scaling - see https://www.rfc-editor.org/rfc/rfc1323#page-8
  • TCP Large Windows - PAWS - "Protection Against Wrapped Sequence Space)
  • TCP Large Windows - RTTM - "Round-Trip Time Measurements" - to adapt the window size
  • TCP SACKs - Selective Acknowledgements. see https://www.rfc-editor.org/rfc/rfc2018

Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations

see RFC3135

This specifically goes into the detail of how to implement a "Performance Enhancing Proxy" [PEP]. Notable extracts from this RFC about PEPs:

  • M-TCP - keeping connections alive during periods of disconnection in wireless networks
  • Transport Layer PEPs - "TCP PEP". Generating local acknowledgements. The term "TCP spoofing" is sometimes used.
  • Application Layer PEP - eg. Web Caching proxy
  • Connection symmetry - sometimes a connection is asymmetric (different upload/download speeds), and this requires special handling.
  • Split Connection: "A split connection TCP implementation terminates the TCP connection received from an end system and establishes a corresponding TCP connection to the other end system".
  • TCP Ack Handling
  • TCP Ack Spacing
  • Local TCP Acknowledgements - typically with split connection. "The burden falls upon the TCP PEP to recover any data which is dropped after the PEP [locally] acknowledges it". (aka Local TCP Retransmissions)
  • Local TCP Retransmissions
  • TCP ACK Filtering and Reconstruction
  • Tunneling
  • Compression
  • Handling Periods of Link Disconnection with TCP
  • Priority-based Multiplexing
  • Protocol booster schemes

(And that isn't even half-way through the RFC - it's highly recommended to read for Network Engineers working with PEPs)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.