Bandwidth Throttling App Feature

Hi,

I'm interested in building a prototype swift app that can run on MacOS and IOS that can throttle both upload and download speeds. This would have to work along side an IKEv2 VPN connection which is controlled via the app (we have an existing app to manage the VPN connection built by an external team).

I'm brand new to MacOS/IOS development apart from the beginner tutorials to build a basic app. It's fair to say I'm struggling a bit to know where to start. I've looked at Network Extensions and thought maybe I could add a sleep timer in between packets in App Proxy Provider or Packet Tunnel Provider but would that require me to write my own VPN client?

I'm really just looking to add throttling capability for the existing IKEv2 connection managed by the app. We'd then get the user's bandwidth profile when they connect via our app, and set the throttling rate.

I've checked out Network Link Conditioner and this is type of control I want to achieve in my app just with better accuracy.

Cheers

You don’t have a lot of options on iOS. The APIs available to you there are much more limited than on macOS [1]. On that front you wrote:

I've looked at Network Extensions and thought maybe I could add a sleep timer in between packets in App Proxy Provider or Packet Tunnel Provider

Something like that [2].

but would that require me to write my own VPN client?

Yes.

I have a question about the scope of your intended product. Do you want to limit bandwidth of:

  • Your app

  • The system as a whole

  • Some specific apps on the system

ps If you start looking at NE providers, make sure you read TN3134 Network Extension provider deployment beforehand. You don’t want to invest time in, say, an app proxy, if its deployment options don’t align with your requirements.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Largely this is because macOS, having a much longer history, has APIs that shipped before we started being careful about what constituted an API. Many of those APIs wouldn’t pass muster in the modern world.

[2] That’s a very naïve way of looking at bandwidth throttling. If you get serious about this, I recommend that you research industry best practices for this. There’s nothing special about Apple platforms in that regard.

We want to limit traffic heading out the IKE tunnel (and coming back)

We want to limit traffic heading out the IKE tunnel (and coming back)

OK.

There’s no built-in way to do that on iOS. It’s feasible to do this with an NE packet tunnel provider but that does means that you’d have to reimplement IKEv2, which is a lot of work.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Would it be possible to run a local tunnel server to send packets through and from the tunnel server forward the packets out? So then we continue to use built in IKE, and just create a UDP tunnel server which can then send IP packets out the wire via the built in IKE

They other way we were thinking about was to use a local socks5 server, and just rate limit tcp/udp traffic

There’s what’s possible. And then there’s what DTS supports. This crops up a lot with iOS NE providers because they are so limited in scope. See TN3120 Expected use cases for Network Extension packet tunnel providers.

If you try to twist the NE provider architecture into doing things that it wasn’t intended to do, you will run into weird-o problems during development, deployment, or maintenance (and possibly all three!). And so DTS has to draw a line, beyond which we won’t provide support.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Bandwidth Throttling App Feature
 
 
Q