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)?


1 Answer 1


TCP Headers occur when a connection between client and server is established before data can be sent. The server must be listening (passive open) for connection requests from clients before a connection is established. Three-way handshake (active open), retransmission, and error-detection adds to reliability but lengthens latency. Applications that do not require reliable data stream service may use the User Datagram Protocol (UDP), which provides a connectionless datagram service that prioritizes time over reliability. TCP employs network congestion avoidance. However, there are vulnerabilities to TCP including denial of service, connection hijacking, TCP veto, and reset attack.

The question is: Consider the figure below. Choose the correct option for the OSPF DR/BDR election. All interfaces are configured with a subnet mask

One might say that the sender's window size will shrink when bytes are sent, and expand when acknowledgements are received.

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