I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”?> On 30 Sep 2017, at 11:23 AM, Ryan Mounce <ryan at mounce.com.au> wrote: > > I'm not aware that BBR claims nor attempts to resolve any of the > inherent issues with TCP-over-TCP. This should still be avoided if > possible. > > TCP BBR would be beneficial if configured on the sending host when > there is a UDP tinc tunnel in the middle. > > On 29 September 2017 at 19:34, Bright Zhao <startryst at gmail.com> wrote: >> We knew the TCP-BBR developed by google and try to optimize the transport efficiency of TCP, I’m wondering will this be beneficial if we put tinc in TCP mode plus the TCP-BBR? >> _______________________________________________ >> tinc mailing list >> tinc at tinc-vpn.org >> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
On Sat, Sep 30, 2017 at 11:28:40AM +0800, Bright Zhao wrote:> I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”?It is *ALWAYS* better to have tinc tunnel packets via UDP instead of TCP. Regardless of which congestion algorithm is used, TCP-over-TCP is bad for performance, due to interactions between the two TCP layers. UDP has no congestion algorithm, so TCP-over-UDP has the same performance as that TCP layer. Note that tinc normally autodetects whether UDP is possible or not, and if not it falls back to TCP, so you should never need to set TCPOnly. It's mainly a relic from older versions of tinc that did not automatically detect this. (Though, there are perhaps networks that give more bandwidth to TCP traffic than UDP traffic, or do other weird things to UDP traffic, that might benefit from manually forcing TCP.) -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20171001/73c980ea/attachment.sig>
> On 01 Oct 2017, at 21:45 , Guus Sliepen <guus at tinc-vpn.org> wrote: > > On Sat, Sep 30, 2017 at 11:28:40AM +0800, Bright Zhao wrote: > >> I understand the concern of uncertain for TCP-over-TCP by BBR, as the BBR is natively designed to optimize TCP, instead of TCP-over-TCP, but could you articulate a bit more about the beneficial of “sending host when there is a UDP tinc tunnel” in the middle”? > > It is *ALWAYS* better to have tinc tunnel packets via UDP instead of > TCP.I would’ve stated the above as: "It is *ALWAYS* better to have *any* VPN tunnel packets via UDP _or any other non-congestion/retransmission protocol_ instead of TCP”, as it is a general VPN related issue, not just tinc when it gets to retransmissions, and the retransmission of retransmissions with packet losses ;)> Regardless of which congestion algorithm is used, TCP-over-TCP is > bad for performance, due to interactions between the two TCP layers. UDP > has no congestion algorithm, so TCP-over-UDP has the same performance as > that TCP layer.