tinc for Satellite connections (benchmarking)

[Nick Hibma]

> Here you can see the results [3]. In the 50 most visited, the clear
> winer is the raw connection because of these web-cache proxies which are
> somewhere in the path. However in the 50 less visited, the cache hits
> are smaller and the results are very similar.
> 
> RAW: 2536 ms (average)
> TINC: 2815 ms (average)
> 
> In addition, the TINC network is able to reach more sites (41 VS 46)!!
> So probably it is a huge part of the difference between both results
> (non reachable sites by RAW are usually reached by TINC with big latency).
> 
> In this point you would ask why am I saying all this stuff? Well, for
> three points:
> 
> - It could be useful for someone
> - I wanted to share it with some more people to see if someone has a
> comment related to it
> - I want to know from the tinc experts what more options might I modify
> to optimize the connectivity


Latency is latency, and there is nothing you can do about that, except for caching. But that is pretty useless in many cases, certainly for a site with a limited set of users.

You are actually having a pretty useless VSat experience IMHO. We use mobile VSat connections and using tinc on them (for moving sessions from one VSat to 3G and back without dropping them) actually drops our throughput to 10KB/s per TCP connection. This can be explained by the Bandwidth*latency product. You will need a PEP, a Performance Enhancing Proxy, to resolve this.

And here is the rub: These VSat modems contain a PEP. They do TCP interception to optimise the TCP connection over the VSat. And the modems we use (Newtec) actually do a pretty decent job to optimise a connection.

Nick