Achieve the Actual Subscribed Bandwidth

Despite the last mile bandwidth is is big enough, that is over 10 Mb/s, and despite the LTE (G4) promises 40 Mb/s, downloading a big file still takes a long time as if the bandwidth was just a few kb/s

What are the issues

The Bandwidth Delay Product Issue

Lets consider a subscriber connected to through a 20 Mb/s ADSL. Now Imagine that a full SMT1 link, that is a 155 Mb/s link is entirely dedicated to this user. You then may expect this user to be able to download a file at nearly 20 Mb/s that is roughly 2MB/s.

Unfortunately the user and its ISP is located in an island and is connected to the Internet through a 10000 km long submarine cable and thus the RTT is 200ms. The result is that this user will never download faster than 4.5 Mb/s and this limitation is a consequence of the bandwidth delay product: once the maximum inflight packet number is reached, the TCP protocol forces the application (the user's browser or any user-agent used to download file) to wait for the ACK packet.

End to end Acknowledgement Issue

TCP protocol uses a end-to-end Acknowledgement. This makes the core network simpler since it works at the network L.3 layer and lets the transport control being achieved by the software running the TCP stack at both ends. The drawback is that is a part of the network is not reliable, packets retransmissions will traverse the entire networks.

The Solution

Deploying OverSea over the submarine cable and enabling the TCP optimization at both ends will solve the bandwidth delay product and enable the user to actualy get the expected bandwidth.

moreover, packet retransmission will be segmented and will no longer traverses the whole network. This fasterizes the packet delivery, saves bandwidth and improve the actual bandwidth per TCP session


Read more ▶