sstp vs pptp performance

littlebill · Tue Oct 14, 2014 4:41 am

anyone notice a big hit between pptp and sstp?

i have a 5 mbit up on both isps

sstp barely can break 350k across tunnel

pptp is pushing well over 550k?

any comments anyone agree? does not seem to be cpu related, neither are maxxed out

Tue Oct 14, 2014 8:47 am

I have much more over sstp.

hedele · Tue Oct 14, 2014 8:53 am

As SSTP is a purely TCP based tunnel, it can suffer from TCP meltdown problem and may generally not deliver optimal performance on links that are not 100 percent clean and stable. You have the same issues when using OpenVPN TCP tunnels.
PPTP is using GRE to transmit encapsulated data, and does therefore not have this problem. However, SSTP is way better at working through NAT Firewalls. You need to select the correct tool for the situation at hand

littlebill · Tue Oct 14, 2014 5:21 pm

hmm,

im aware of the advantage, im trying to just understand the differences

my tunnel is stable with a 20ms response

same isp even

this is consistent across all my routers

what routers are you using where you are seeing better performance?

i know the cpu overhead is higher on sstp, but does it have more bandwidth overhead?

Tue Oct 14, 2014 6:36 pm

For example. Rb2011 as sstp server, omnitik as client with upload line capacity of 10mbit passes 9.3mbit thru the sstp tunnel.

littlebill · Tue Oct 14, 2014 8:56 pm

im looking see more toward wan connections, as i have no need to test a vpn tunnel over local lan

Tue Oct 14, 2014 11:29 pm

It's thru Internet, it means wan to wan tunnel. What else you want?

littlebill · Wed Oct 15, 2014 12:47 am

It's thru Internet, it means wan to wan tunnel. What else you want?

sorry it seemed like a local connection,

what code level are you running?

i am using a 2011 with a 750 as a client and see the reduction

leonset · Wed Oct 15, 2014 12:56 pm

That seems way too low... I remember getting more than 4Mbps using pure IPSEC/AES-192 and the old RB450 (not g). Sorry, I don't have values for SSTP not PPTP...

Wed Oct 15, 2014 2:29 pm

It's thru Internet, it means wan to wan tunnel. What else you want?

sorry it seemed like a local connection,

what code level are you running?

i am using a 2011 with a 750 as a client and see the reduction

2011 with 6.19 and omnitik with 6.18. Omnitik is the same like 750. I also tested sstp between two 750s on lan running 6.20 with about 80mbit passed, if I remember well - did not note the values, so hope it's correct.

Jeroen1000 · Tue Feb 17, 2015 9:31 pm

Same issue here. I've got a rock solid ISP cable connection. SSTP server: It has 160 megabit down, 10 megabit up.
I'm connecting from another line with the same ISP. This line's profile is 60 megabit down, 3 megabit up.

PPTP: 8-9 megabit per second. Tested for 30 minutes downloading an Ubuntu ISO and with various speedtests.

Then SSTP: between 4.5 and 5 megabit. Often fluctuating below 4.5. Thus SSTP is about 50% slower.

Hardware:

Routerboard 850Gx2 using ROS 6.27
Windows 7 SSTP client

Notes:

Setting MTU did not help. I've tried 1460 and 1500 bytes.
RC4 or AES256 cipher is of little importance (RC4 is about 0.5 megabit faster on average)

littlebill · Wed Feb 18, 2015 12:14 am

my pptp numbers are much better then that, but yes i have a 100/100 connection that is barely breaking 3 mbit, support has stopped responding to my support request, even when i provide mounds of data, this is across a variety of devices at this point

Wed Feb 18, 2015 1:12 am

What is the latency between the two points and what consumes cpu on both sides when tunnel goes at maximum?

littlebill · Wed Feb 18, 2015 1:38 am

latency is 30-40ms, cpu never maxes out, barely breaks 35% on a MAP2N,

on a pptp connection with both sides having 28/6 i can see over 600KBit, which is great, simply changing to sstp, both sides see 350mbit max, its a huge hit

i have a map2n behind a router doing sstp 100/100, it barely breaks 3/2mbit, using a win7 with sstp client, speeds are significantly better, i have also notice it changes over mikrotik levels, my best speeds on sstp were version 6.7

all of this is repeatable easily

NathanA · Wed Feb 18, 2015 7:13 am

I consider TCP-based tunnels like SSTP to be tunnels "of last resort"; see Why TCP Over TCP Is A Bad Idea. You only run them if you have absolutely no other alternative (e.g., either end of the tunnel is behind a firewall that you have no direct control over, or perhaps in the case of SSTP specifically, security is valued over performance).

Experiences will vary wildly depending on exact conditions, and running a tunnel like that over the internet instead of over a LAN exponentially compounds the number of variables that you have to account for (most of which you have absolutely NO control over) in order to have a "perfect" experience. I doubt there is anything that MikroTik can do about this. If you want to prove this to yourself, substitute an SSTP concentrator that isn't RouterOS based on one end and an SSTP client that isn't RouterOS based (e.g., Windows) on the other, and repeat your experiments. I bet that your experience will not be that much different than what you see with MikroTik gear.

As they say, "your mileage may vary".

-- Nathan

Jeroen1000 · Wed Feb 18, 2015 10:20 am

@Nathan,

To recap:

SSTP-server:

850Gx2 on a 160/10 megabit connection (getting about 9 megabit upload on average - untunneled). Running ROSv 6.27

SSTP-client:

Windows 7 on a 60/4 connection (getting about 3.2 upload on average - untunneled)

My latency is pretty low: 12 - 18 ms without SSTP and around 30 - 35 with SSTP. Moreover, the RB850Gx2 SSTP-server is only 6 kilometres from the location where I connect to it with my Windows 7 SSTP-client. Note that the 850Gx2 forwards traffic to the internet - so traffic is flowing through the router - and a doubling in latency is just what I would expect when using the tunnel. CPU does not go over 10% I believe. CPU load is definitely NOT an issue.

Can you recommend another SSTP server? I've got a Windows server 2008 but it's hard to move to the 160/10 location. Are there dedicated SSTP concentrators available?

funny note: when using the 60/4 connection as the SSTP server, I do get the complete 3.2 megabit of bandwidth. A Routerboard 450G with ROS 6.15 is running there.

Jeroen1000 · Wed Feb 18, 2015 10:23 am

latency is 30-40ms, cpu never maxes out, barely breaks 35% on a MAP2N,

on a pptp connection with both sides having 28/6 i can see over 600mbit, which is great, simply changing to sstp, both sides see 350mbit max, its a huge hit

How can you get over 600 megabit if the maximum upload on both sides is only 6 megabit?

littlebill · Wed Feb 18, 2015 10:55 pm

typo i fixed it

littlebill · Wed Feb 18, 2015 10:57 pm

I consider TCP-based tunnels like SSTP to be tunnels "of last resort"; see Why TCP Over TCP Is A Bad Idea. You only run them if you have absolutely no other alternative (e.g., either end of the tunnel is behind a firewall that you have no direct control over, or perhaps in the case of SSTP specifically, security is valued over performance).

Experiences will vary wildly depending on exact conditions, and running a tunnel like that over the internet instead of over a LAN exponentially compounds the number of variables that you have to account for (most of which you have absolutely NO control over) in order to have a "perfect" experience. I doubt there is anything that MikroTik can do about this. If you want to prove this to yourself, substitute an SSTP concentrator that isn't RouterOS based on one end and an SSTP client that isn't RouterOS based (e.g., Windows) on the other, and repeat your experiments. I bet that your experience will not be that much different than what you see with MikroTik gear.

As they say, "your mileage may vary".

-- Nathan

simply connecting with a windows 7 client, and the speeds greatly increase, from the same connection point, back to the same sstp server.

i also have shown a huge difference in performance on 6.7 vs newer versions of 6.x but some of my devices can't run at 6.7

Jeroen1000 · Thu Feb 19, 2015 9:42 am

I've got some more interesting information.

A friend has a 10/10 connection and has connected to my 160/10 SSTP-server. Limiting the SSTP connection to 7/7 got a stable 784 kilobyte per second connection (+- 6.3 megabit). Limiting to 8/8 got the connection to 900 kilobyte per second. (+- 7.2 megabit). The connection was stable the whole time downloading a 982 megabyte large Ubuntu ISO. At most it fluctuated 50 - 60 kilobyte per second when capping tot 8/8. When capping to 7/7 it did not seem to fluctuate at all!

Not limiting the SSTP connection got a fluctating connection between 1100 kilobyte per second and 500 kilobyte per second. Numbers went up and down all the time.

So why on earth is a 10/10 connection getting 900 kilobyte out of the SSTP when I, with my 60/4 connection, am only getting about 560 kilobyte per second (+- 4.5 megabit).

Oh yeah, the friend is about 50 kilometres away from the SSTP server. Me only 6.

littlebill · Thu Feb 19, 2015 4:18 pm

how are you limiting? simple queue?

Jeroen1000 · Thu Feb 19, 2015 8:18 pm

I got the idea from here: http://forum.mikrotik.com/viewtopic.php?t=85568 kudos to stefan803.
It is an excellent read, I promise.

You can set the limit going to PPP profiles and selecting the profile that is used for a particular user (see screenshot attached). What I'm going to do next is eliminate some variables:

- Going to use my friends laptop for tests (there might be software on my laptop inspecting SSL traffic, although I have disabled this software during my tests).
- So far I was on testing on Wifi so I'm going to use a wired connection
- I stupidly forgot to limit MY PPP user profile to 8/8 (should still get way over 4.5 megabit even when haven forgotten this)

So far the only thing that offers some hint of an explanation is:

- My friends upload is 10M but that should not matter when traffic is flowing FROM the SSTP-server TO the client. My friend can receive 10M and I can receive 60M (download direction for the client). The only difference is that MY upload is 4M and my friends is 10M. But again, this should only matter for traffic from the client to the SSTP server.

EDIT: SOME progress: Now that I'm limiting to 8M/8M for my profile I'm getting between 650 and 750 kilobytes per second. So about 5 to 6 megabit. There is a lot of fluctuation though. It doens't stay at 750 for more than a few seconds and then ramps down again and then up and down...you get the point.

limit PPP.jpg

littlebill · Fri Feb 20, 2015 3:59 am

i will give this a try in a few days, my internet is acting up due to weather, thanks for the info so far

Jeroen1000 · Tue Feb 24, 2015 10:09 am

Latest update/conclusions:

For a WIRED connection:
- When rate limiting to 8M/8M, the wired connection is getting 7.3 megabit out of SSTP. So same conclusion as Stefan in viewtopic.php?t=85568
It not ALL that I can get but 7.3 out of 9 megabit is acceptable nonetheless. Speed fluctuates with about 0.5 megabit per second.
- When rate limiting to 7M/7M thoughput is ofcourse less (+- 6.3 megabit), but connection is stable at 784 kilobyte per second for the entire download.

Since for wireless my quite old AP and newer laptop don't get along, I'm holding off conclusions until my new AP is in place.

Now does anyone know whether rate limiting = shaping? Beacause, when you shape below max bandwidth the router will queue, and then you are essentially sacrificing latency for throughput. The question is, how deep is the queue?

This also leaves to ponder why SSTP is all over the place in terms of throughput when not shaping. In order to discover this I would require a different SSTP server (non-Mikrotik) to repeat these tests with. I firmly believe it is NOT the WAN connection as my upload is very stable and the geographical distances are very small (prime testing location is only 6 kilometres away from SSTP server).
To be clear PPTP does not suffer from this issue at all. I don't know whether anyone has an idea how to diagnose whether it is TCP-meltdown? When keeping the untunneled networks bandwidth HIGHER than the tunneled networks bandwidth, I'm also essentially avoiding this:-)

bajodel · Tue Feb 24, 2015 11:02 am

Latest update/conclusions:
.. [ CUT] ..
To be clear PPTP does not suffer from this issue at all. I don't know whether anyone has an idea how to diagnose whether it is TCP-meltdown? When keeping the untunneled networks bandwidth HIGHER than the tunneled networks bandwidth, I'm also essentially avoiding this:-)

Reading SSTP Wiki ( http://en.wikipedia.org/wiki/Secure_Soc ... g_Protocol ):

SSTP suffers from the same performance limitations as any other IP-over-TCP tunnel. In general, performance will be acceptable only as long as there is sufficient excess bandwidth on the un-tunneled network link to guarantee that the tunneled TCP timers do not expire. If this becomes untrue, performance falls off dramatically. This is known as the "TCP meltdown problem"

littlebill · Tue Feb 24, 2015 5:56 pm

i tried rate limiting, it did not seem to really make a difference for me. can you provide the cli export of your ppp? just to confirm, i will test again.

what code you running?

Tue Feb 24, 2015 6:02 pm

You can make the queue long as you wish if you have enough memory and the delay will not be so long that the connection will be considered down by one of the ends.

Jeroen1000 · Tue Feb 24, 2015 8:19 pm

i tried rate limiting, it did not seem to really make a difference for me. can you provide the cli export of your ppp? just to confirm, i will test again.

what code you running?

I'm on ROS 6.27. I'll add the export hopefully in a few hours (I'm testing another config ATM). You must rate limited below your connection upload + download speed*. So run a bunch of speedtests on the SSTP server end and substract 1 megabit. I get 9 megabit on average upload so I filled in 8 megabit in the rate limiter for both up and download*. If your upload is unstable, rate limit to the lowest stable value.

/ppp profile
add change-tcp-mss=yes dns-server=192.168.x.x incoming-filter=\
    internet-only-in local-address=192.168.x.x name=internet-only \
    outgoing-filter=internet-only-out rate-limit=8M/8M remote-address=\
    VPN-users use-encryption=yes

@ Jarda

I think it is important to keep both upload and download queues filled to get a stable througput. Considering that my ISP's upload is VERY stable and packet loss is non-existent on the testing link, there must be something else causing a fluctuation when not rate limiting: either a milder form TCP meltdown or Mikrotik SSTP implementation. Too bad not much useful info is available on TCP-meltdown.

So what could be happenig is that the tunneled network is eating up too much bandwidth when not rate limiting. Packet loss/ack timer issue could then occur? The tunneled connection will throttle back. Then untunneled bandwidth is again > than tunneled bandwidth. Connection speeds up again and the cycle restarts. Limiting prevents this and everything is happy:-). I just wish I could produce evidence for this as this is merely a guess.

Here is a Mikrotik reply as to what the rate limiter for PPP profile does:

PPP profile rate limiter simply adds dynamic simple queue with default-small queue
size. It is not exactly shaping, it will queue small amount off packets and start
dropping when the queue is full. You can also remove the rate limit and add the
queue yourself and have the ability to change queue type and size.

* if you have clients connecting with a kick ass upload you can fill in a larger number ofcourse:-). It has to be lower than your SSTP server's max. download, in my case 160 megabit. I filled in 8M for download limiting for no good reason.