Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's worth remembering that there are cheaters on the internet. I have been one.

I built and sold a product that cheated on TCP in order to minimize negative customer experiences during periods of congestion.

It was a one line change in the linux networking code, and suddenly their crappy networks were no longer a problem!

(Just so you don't think me completely evil…

All traffic was across their own networks.

Their networking folks considered 5% packet loss to be acceptable.

The product's purpose was to aggregate and tunnel connections. Multiple TCP inside TCP gets unfairly punished by the congestion algorithms, which is why most VPNs don't use TCP, but sometimes you find yourself under the thumb of administrative rules and you have to do it.

I simply capped our back off time to something like 10 seconds. Short enough that no one thinks the device broke because "the network was stuck, but now I can ping but your device is hung so I'll power cycle it". If your network can't take 1 packet per 10 seconds on behalf of a few dozen aggregated connections, it isn't me that broke your network.)



I had been thinking of:

http://cseweb.ucsd.edu/~savage/papers/CCR99.pdf

(And Nate's right, I drastically oversimplified my summary of it). This is "cheating TCP" by Stefan Savage from '99. A great, great paper.


VPN's don't use TCP because having a reliable protocol with retransmission inside another reliable protocol with retransmission can cause lots of extra traffic when a packet is dropped and the data gets retransmitted multiple times, once from each of the protocols.


Ah, the joys of SSL VPNs it seems.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: