On 14-05-22 06:01 AM, Yousong Zhou wrote: > I saw that link too when I found the pvpn project. If I understand > the theory correctly, the problem is mainly that TCP as a > connection-oriented protocol is not suitable for being used in > long-alive, lossy environment because once the underlying connection > hangs or aborts, upper layer applications all suffer. In the early days of the internet, the naive approach to packet loss was to simply retry the lost segment but it was found that when encountering a congested link this only makes things worse. When there is too much traffic out on a congested link, the stacks respond by generating even more traffic. This creates a positive feedback loop that leads to a meltdown.
Similarly, when tunnelling IP traffic over a TCP connection, you will run into the same problem as soon as you encounter a congested link. The underlying TCP connection will respond to the loss by "pausing" the connection as it reduces its bandwidth and backs off, but at the same time your tunnelled IP traffic will get retried by the upper stack. However, because the underlying TCP connection is reliable and cannot drop anything it now has twice as much data to send (the original segments plus the retries), with half as much bandwidth to do so because it just backed off due to a lost segment. The amount of data to send will increase dramatically while the bandwidth available drops off, and it will again lead to a meltdown. Now, this meltdown will only screw up your connections and not those of everyone else out on the congested link, but it will probably not provide satisfactory performance. If you are still not convinced that IP over TCP is a bad idea, I suggest that you try your PPPoSSH tunnel with an SSH server out on the internet and download a large file over that tunnel*. You will likely find that it appears to work OK for small files, but it will hang and die as the TCP window size scales up and saturates the link between you and the SSH server. > > PPP over SSH may be too specific for `pty' option of pppd. Something > like the following should also do its job. > > while true ; do nc -ulp 7001 -c '/usr/sbin/pppd noauth nodetach > notty' ; read x ; [ -n "$x" ] && break; done > > But busybox netcat does not support UDP mode yet, so I just keep it > the SSH way. I am using PPPoSSH with ipset-enabled dnsmasq [1] mainly > for accessing and accelerating the speed of several websites. Well, > I myself quite enjoy the outcome. PPPoSSH will not accelerate anything, at best it will allow you to hide your packets from traffic shaping firewalls that artificially slow down your connections. For this purpose, you would be far better suited by using the port forwarding features of SSH. For example, to tunnel your web browser's traffic over SSH configure it to use a SOCKS proxy at localhost:8080, and then start an SSH connection with the -D8080 option (for example: ssh -D8080 usern...@ssh.example.com) This should be much more reliable than PPPoSSH, and it will not suffer from the meltdown condition when it encounters congestion on the internet. Cheers, Owen * To reproduce this failure mode, you want to make sure that the link between you and the SSH server is slower than link from the SSH server to the file you want to download. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
