5 ms·

So correct me if I am wrong but this is doing IP in TCP right ? Iirc, this is a big issue for tcp flow control, which relies on packet loss to detect congestion

So correct me if I am wrong but this is doing IP in TCP right ? Iirc, this is a big issue for tcp flow control, which relies on packet loss to detect congestion: as you encapsulate stuff in tcp stream, there will be no more packet loss and the tunelled tcp will not throttle correctly. Did not read the code yet, so maybe there is something to simulate congestion packet loss.

lox 7y ago
From the README: TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).
- ay 7y ago
  This is an intriguing quote. The biggest problem I saw with tcp over tcp is not during the regular operation, but when there was a noticeable packet loss present on the line. Then the the accumulated retransmits on stacked TCP most of the time killed it. Admittedly it was maybe a decade ago after which I concluded it’s just a BadIdea(Tm) and never revisited it. I had similar experience lately whenever using the mobile internet in poorer coverage cases (eg. a high speed train Brussels-Paris or Brussels-London) which result in frequent and big variations of latency. Of course that all is decoupled congestion control. If anyone compared the performance of this solution on poor connections with and without BUFFERBLOAT_CONTROL, would be very very interesting to know the results!
  - Fnoord 7y ago
    WireGuard reconnects in less than a second whereas OpenVPN takes a good 8 (!!) seconds to reconnect. If you have an unstable connection, that's awful. If you only need SSH, Mosh (which utilizes UDP) could be suffice though.
deleted 7y ago
[deleted]

lox 7y ago

From the README: TCP-over-TCP is not as bad as some documents describe. It works surprisingly well in practice, especially with modern congestion control algorithms (BBR). For traditional algorithms that rely on packet loss, DSVPN has the ability to couple the inner and outer congestion controllers, by setting the BUFFERBLOAT_CONTROL macro to 1 (this requires more CPU cycles, though).

ay 7y ago
This is an intriguing quote. The biggest problem I saw with tcp over tcp is not during the regular operation, but when there was a noticeable packet loss present on the line. Then the the accumulated retransmits on stacked TCP most of the time killed it. Admittedly it was maybe a decade ago after which I concluded it’s just a BadIdea(Tm) and never revisited it. I had similar experience lately whenever using the mobile internet in poorer coverage cases (eg. a high speed train Brussels-Paris or Brussels-London) which result in frequent and big variations of latency. Of course that all is decoupled congestion control. If anyone compared the performance of this solution on poor connections with and without BUFFERBLOAT_CONTROL, would be very very interesting to know the results!
- Fnoord 7y ago
  WireGuard reconnects in less than a second whereas OpenVPN takes a good 8 (!!) seconds to reconnect. If you have an unstable connection, that's awful. If you only need SSH, Mosh (which utilizes UDP) could be suffice though.

deleted 7y ago

[deleted]