Don't deprecate TCPOnly please!

[Vladislav]

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.