91–100 of 104 posts
Earlier quoted context omitted.
Someone paying for a premium phone is probably also inclined to pay for a premium mobile network.
Not all iPhones are 'premium' phones, and there are not really 'premium' cell phone networks in the US. Or anywhere.
I work supporting, debugging, fixing the Linux network stack and drivers. I am amazed how little adoption this has seen. Like everything which came along and tried to supplant regular TCP, such as SCTP, it seems MPTCP has also been confined to a niche of application developers who will use it forever while the rest of the world forgets about it.
Other folks have commented - Apple Siri uses mptcp so not exactly niche considering how many devices that is
Earlier quoted context omitted.
Other folks have commented - Apple Siri uses mptcp so not exactly niche considering how many devices that is
Similarly, I promise you everything you've ever done over a 4G or 5G phone has used SCTP inside the phone provider. That doesn't mean the general developer population know about it. I bet most developers have never even heard of it.
Earlier quoted context omitted.
Not all iPhones are 'premium' phones, and there are not really 'premium' cell phone networks in the US. Or anywhere.
Lol, have you ever been to Europe? iPhones are definitely considered premium and there definitely are networks that are more expensive but offer better reception. In Germany, that would be Telekom, in Switzerland, it's Swisscom.
iPhone isn't always 'premium', since they have their version of cheap phones as well. Point is cell network service quality is independent from phone quality.
Earlier quoted context omitted.
I created something like what you're describing with the addition of P2P communication using NAT traversal ( https://www.hyperpath.ie ) It will connect your devices in a P2P Mesh VPN and allow them to send and receive data using multiple links (e.g. multiple 5G or 5G + Satellite). It is significantly cheaper than Peplink's license, less latency and no bandwidth / data limits. You need to bring your own hardware thoug…
what about something like this? two minipcie slots which i suppose you could put two cellular modems into. not sure what OS it runs though but presumably some flavor of linux. https://mikrotik.com/product/rbm33g#fndtn-specifications maybe someone could make one that uses an RPi compute module instead.
I found this board on AliExpress (https://www.aliexpress.com/item/1005003540616473.html?spm=a2...) based on the CM4 and with 3 cellular modems. That could also be a good candidate.
Also found this one (https://www.gateworks.com/products/industrial-single-board-c...) US-made and has 3 minipcie slots (other options available with 2 and 4)
Earlier quoted context omitted.
I was excited about it because we were working on delivery robots and I wanted a good solution for instant failover given 2 cellular modems. We ended up going with PepLink's SpeedFusion to save engineering time. But the license was costly. I really hope for a free solution in the future for 2 cellular networks and Multipath UDP + OpenVPN would also probably be a viable solution.
Hehe, I also worked on a delivery robot with exactly the same problem. We ended up licencing phantom auto. Expensive and ... Not particularly amazing.
I've heard about MPTCP back in 2013. It made so much sense back then, when mobile apps were not that robust to networks changing, I assumed it's going to get adopted in no time due to how much of a ux improvement it would have been back in the day. It's incredibly depressing that this gained barely any traction in the last 10 years, and kernel options are appearing just recently, after everyone has wrapped they http…
I suspect that a lot of innovation energy moved to QUIC, because with TCP your nice new variant can be randomly nobbled by middleboxes. For example, see https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
Earlier quoted context omitted.
I suspect that a lot of innovation energy moved to QUIC, because with TCP your nice new variant can be randomly nobbled by middleboxes. For example, see https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
Nobody cares about those middleboxes, those are only relevant in corporate networks.
Earlier quoted context omitted.
If TCP didn't use L3 source and destination addresses to distinguish connections, it could be more easily taught to deal with: * Clients roaming between L3 addresses * Clients/servers with multiple L3 addresses
But... it doesn't? TCP has no notion of IP address in the protocol, only the port. TCP with changing IPs can work e.g. on top of an ip-ip tunnel with applications not being aware at all.
RFC793:
To allow for many processes within a single Host to use TCP
communication facilities simultaneously, the TCP provides a set of
addresses or ports within each host. **Concatenated with the network
and host addresses from the internet communication layer,** this forms
a socket. A pair of sockets uniquely identifies each connection.
That is, a socket may be simultaneously used in multiple
connections.
> TCP with changing IPs can work e.g. on top of an ip-ip tunnel with applications not being aware at all.
That's just because the IPs have not changed from its point of view: it receives the same frame with the same destination/source IP addresses the entire time.
Part of the reason why we need things like IP-IP tunnels is because L4 connections can't "move" with TCP. In scenarios where we're using tunneling for this, we're accepting worse performance than if we could just directly send TCP to its true destination and have it processed.