Some questions about SPTPS
Etienne Dechamps
etienne at edechamps.fr
Wed Aug 13 00:27:05 CEST 2014
On 12/08/2014 13:58, Sandy McArthur Jr wrote:
> On Mon, Aug 11, 2014 at 1:27 PM, Etienne Dechamps <etienne at edechamps.fr
> <mailto:etienne at edechamps.fr>> wrote:
>
> I believe we don't have the same perspective on the design
> philosophy - I prefer when failure modes are purely "black and
> white" - i.e. communication between two nodes either works or it
> doesn't. I dislike solutions where the system could "half-fail" in
> subtle and obscure ways - like a node ending up in the same "hash
> bucket" as another, flapping node, resulting in random packet loss.
> My rationale is that it's much easier to diagnose clear-cut issues
> (two nodes can't talk to each other) as opposed to spending hours
> trying to find out why some packets seem to get lost on some links
> at random times.
>
>
> As a VPN user I appreciate and value your caution. But, I selected and
> value that Tinc makes multiple attempts to work even in an unfavorable
> environment. eg: if direct UDP doesn't work: TCP fallback or relaying
> between other peers if necessary.
Yes, and these are fantastic features. However, I draw a clear
distinction between features that try to make the VPN as efficient and
reliable as possible even in hostile network environments (which tinc
has no control over), which are very desirable, and features that try to
"half-fix" problems that tinc brought on itself, which are not so clear-cut.
> Personally, I would like to see more fallback methods such as listening
> on multiple ports with protocol encapsulation (HTTP Proxy Connect
> tunneling) . The more situations Tinc works without me having to think
> about it post setup, the more value it provides to me.
I wholeheartedly agree. I often use tinc in "road warrior" scenarios
where it is very convenient to be able to connect to the VPN even in
extremely hostile network environments (the typical airport/hotel crappy
Wi-Fi). I believe Skype is the champion in that category, and we should
aspire to do the same.
tinc has improved tremendously in that aspect over the years: things
like UDP hole punching, TCP fallback, relay fallback, PMTU discovery,
tolerance for unknown UDP source addresses... these were very welcome
additions, and they work very well in practice (thanks Guus!). These
features save me an incredible amount of time, and I use tinc knowing
that I can trust it to provide me with the most efficient VPN connection
that I could possibly get regardless of the network environment it's
running in. Well, not if you're using SPTPS of course, since that's what
this whole thread is about :)
--
Etienne Dechamps
More information about the tinc
mailing list