JW> The same is actually true for a German cable network ISP: Kabel
JW> Deutschland. They massively throttle UDP connections (depending on time
JW> of day, transfer volume and possibly other criteria, like port numbers).
And my situation is the opposite, here in Russia the main problem
is/are slow external internet channels, so ISP usually throttle down TCPs (as
they are HTTP, Youtube,music downloads, other sites, etc.). My ISP - Beeline
Moscow, throttles down any TCP connection to 1 MBit/s after some random period
of time (from 1 min to 2 hours) :(
So i too sign the petition to NOT remove the TCPOnly, even more, to be
a truly versatile solution, tinc needs to handle all these limitations and
squeeze the max out of the internet. I mean TCPOnly may sometimes be even
extended to UDPOnly, TCPFallbackThreshold, UDPFallbackThreshold, ProbingTime,
MAXProbingBandwith, LatencyOverBandwidthPriority and so on. (these parameters
have no direct relation to tinc, just my thoughts)
What i am to say is that traffic flow should not only "fall back" but
be really flexible and dynamic, being able to probe the channel (i.e. Internet)
constantly during the session and dynamically choose the best possible way to
transfer traffic.
Respect to the Creators, tinc is a really nice project, and it's
maintained. If developers have any extra time and extend it's functionality
with, say, channel probing and load balancing like in CloudVPN or better,
combined with tinc's UDP capability, that would be a really fantastic solution!
FYI, have a look at his poster
http://e-x-a.org/stuff/cloudvpn-poster.jpg in the mid-bottom section. I haven't
tried cloudvpn yet (as it does not have UDP support), but this particular idea
sound reasonable.
_______________________________________________
tinc mailing list
[email protected]
http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
