Hi, Owen and list.
On 23 May 2014 01:22, Owen Kirby <o...@exegin.com> wrote:
> 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.
I know that TCP over TCP is not a good idea.
>>
>> 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.
My network environment is a limited one. PPPoSSH is only used as an
alternative route to sites that are either blocked completely by the
ISP, or speed-limited by the campus network admin. The SSH server I
use can provide better experience than without it.
>
> 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.
Well, I still use local/remote/dynamic port forwarding a lot. SOCKS
proxy is different in that you have to configure every client that
need it. In addition to that, devices like smart phones and tablets
cannot use SOCKS proxy in an easy way. I prefer PPP over PTY because
it will provide more flexibility.
>
> 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.
Opening multiple concurrent link to saturate the link between me and
the SSH server should also do the job. I'd like to try pressure
testing it later. Hmm, the link is doomed I guess...
Thanks for your input.
Regards.
yousong
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
