[HN Gopher] TCP over TCP is a bad idea (2000)
___________________________________________________________________
TCP over TCP is a bad idea (2000)
Author : Deeg9rie9usi
Score : 29 points
Date : 2024-10-24 12:50 UTC (1 days ago)
(HTM) web link (web.archive.org)
(TXT) w3m dump (web.archive.org)
| dang wrote:
| Related:
|
| _Why TCP over TCP is a bad idea (2001)_ -
| https://news.ycombinator.com/item?id=25080693 - Nov 2020 (68
| comments)
|
| _Why TCP Over TCP Is a Bad Idea (2001)_ -
| https://news.ycombinator.com/item?id=9281954 - March 2015 (43
| comments)
|
| _Why TCP Over TCP Is A Bad Idea_ -
| https://news.ycombinator.com/item?id=2409090 - April 2011 (26
| comments)
| Svip wrote:
| I notice that the earliest version of this post[0] is dated 1999,
| whilst the latest version is modified in 2001 (see the main
| link). Which year would be appropriate to mark it on HN? 1999?
| 2001?
|
| [0]
| https://web.archive.org/web/20000310230940/http://sites.inka...
| dmitrygr wrote:
| sqrt(1999 * 2001)
| schmidtleonard wrote:
| (1999^-1 + 2001^-1)^-1
| exe34 wrote:
| 2000ish
| pif wrote:
| (|1999> + |2001>)*Sqrt(1/2)
| Shared404 wrote:
| IMO the latest update is the best option. Or a syntax like
| (<original date>, updated <update date>) if the update was not
| super substantial.
| 01HNNWZ0MV43FF wrote:
| Port forwarding doesn't count, right?
| duskwuff wrote:
| Correct, because that doesn't transform the TCP stream.
|
| "TCP over TCP" specifically means a TCP stream whose payload
| represents a sequence of TCP packets.
| AStonesThrow wrote:
| TCP doesn't use "packets". They're called "segments".
| aarmenaa wrote:
| I've just spent the last month learning exactly why I definitely
| do want a TCP over TCP VPN. The short answer is almost every
| cloud vendor assumes you're doing TCP, and they've taken the
| "unreliable" part of UDP to heart. It is practically impossible
| run any modern VPN on most cloud providers anymore.
|
| Over the last month, I've been attempting to set up a fast
| Wireguard VPN tunnel between AWS and OVH. AWS killed all internet
| access on the instance with zero warning and sent us an email
| indicating that they suspected the instance was compromised and
| being used as part of a DDOS attack. OVH randomly performs "DDOS
| mitigation" anytime the tunnel is under any load. In both cases
| we were able to talk to someone and have the issue addressed, but
| I wanna stress: this is one stream between two IPs -- there's
| _nothing_ that makes this anything close to looking like a DDOS.
| Even after getting everything properly blessed, OVH drops all UDP
| traffic over 1 Gbps. It took them a month of back-and-forth
| troubleshooting to tell us this.
|
| The really terrible part is "TCP over TCP is bad" is now so
| prevalent there's basically no good VPN options for it if you
| need it. Wireguard won't do it directly, but there's hacks
| involving udp2raw. I tried it, and wasn't able to achieve more
| than 100 Mbps. OpenVPN can do it, but is single-threaded and
| won't reasonably do more than 1 Gbps without hardware
| acceleration, which didn't appear to work on EC2 instances.
| strongSwan cannot be configured to do unencapsulated ESP anymore
| -- they removed the option -- so it's UDP encapsulated only.
| Their reasoning is UDP is necessary for NAT traversal, and of
| course everybody needs that. It's also thread-per-SA so also not
| fast. The only solution I've found than can do something not UDP
| is Libreswan, which can still do unencapsulated ESP (IP Protocol
| 50) if you ask nicely. It's also thread-per-SA, but I've managed
| to wring 2 - 3 Gbps out of a single core after tinkering with the
| configuration.
|
| For the love of all that's good in the world, just add performant
| TCP support to Wireguard. I do not care about what happens in
| non-optimal conditions.
|
| /rant
| throwing_away wrote:
| Did you go down the shadowsocks path at all?
| kwantam wrote:
| The whole point of this article is that performant Wireguard-
| over-TCP support in Wireguard simply does not work. You're not
| fighting the prevalence of an idea, you're fighting an inherent
| behavior of the system as currently constituted.
|
| In more detail, let's imagine we make a Wireguard-over-TCP
| tunnel. The "outer" TCP connection carrying the Wireguard
| tunnel is, well, a TCP connection. So Wireguard can't stop the
| connection from retransmitting. Likewise, any "inner" TCP
| connections routed through the Wireguard tunnel are plain-
| vanilla TCP connections; Wireguard cannot stop them from
| retransmitting, either. The retransmit-in-retransmit behavior
| is precisely the issue.
|
| So, what could we possibly do about this? Well, Wireguard
| certainly cannot modify the inner TCP connections (because then
| it wouldn't be providing a tunnel).
|
| Could it work with a modified outer TCP connection? Maybe---
| perhaps Wireguard could implement a user-space "TCP" stack that
| sends syntactically valid TCP segments but never retransmits,
| then run that on both ends of the connection. In essence, UDP
| masquerading as TCP. But there's no guarantee that this faux-
| TCP connection wouldn't break in weird ways because the network
| (especially, as you've discovered, any cloud provider's
| network!) isn't just a dumb pipe: middleboxes, for example,
| expect TCP to behave like TCP.
|
| Good news (and oops), it looks like I've just accidentally
| described phantun (and maybe other solutions):
| https://github.com/dndx/phantun I'd be curious if this manages
| to sidestep the issues you're seeing with AWS and OVH.
| aarmenaa wrote:
| > The retransmit-in-retransmit behavior is precisely the
| issue.
|
| But you're concerned about an issue I do not have. In
| practice retransmits are rare between my endpoints, and if
| they did occur poor performance is acceptable for some period
| of time. I just need it to me fast _most of the time_. To
| reiterate: I do not care about what happens in non-optimal
| conditions.
|
| > it looks like I've just accidentally described phantun (and
| maybe other solutions): https://github.com/dndx/phantun
|
| I'll definitely look into that. They specifically mention
| being more performant than udp2raw, so that's nice.
___________________________________________________________________
(page generated 2024-10-25 23:00 UTC)