[londons_explore]

The internet and the IP protocol is kinda incompatible with mesh networks.

A city-spanning mesh network which connected to the internet at peoples home broadband connections couldn't reasonably function. Someone who was downloading a file over the mesh wouldn't be able to have their data use any connection to the internet - they would have to keep using the same gateway from the mesh to the internet, because if they switched gateways their IP would change and existing connections would fail.

It's the same reason switching from WiFi to Mobile data and back causes a reconnect in video calls.

[freedomben]

Not trying to nitpick, but IP handles that just fine (see mosh[1] for a great example of flawless roaming).

It's the TCP that doesn't handle it. Unfortunately HTTP and most other protocols are on top of TCP so suffer from the same problem.

[1]: https://mosh.org/

[londons_explore]

IP doesn't handle it fine.

If I roam from network A to network B, then someone else cannot send me an IP packet till they know my address on network B.

I can only send out a "Hey, I'm now at this address" message to them if I know they will be wanting to contact me, and I know my own address has changed. Neither of those is guaranteed.

[freedomben]

You're not wrong about the other party needing to know your changed IP address, but that's still a result of higher level protocols that are leaking the abstraction of IP for addressing. You could use hostnames instead, or put some other addressing method on top of it to adapt. It's not commonly done since you'd have a DNS lookup before each packet, which would be horribly inefficient, but it's possible because IP itself doesn't handle the details of connections. IP itself is connectionless/stateless.

There is no concept in IP of a "user", "client", or other party that exists beyond the lifetime of that packet. IP is basically a stateless logical address sitting on top of some physical address with a few delivery options to facilitate traffic flow (like congestion handling).

Any connection state or concept of user/client/server/etc is held at either the TCP level, or for UDP-based protocol higher up the stack (commonly at the application level).

If you still insist on IP being at fault here, let's consider an analogue. If a user sets up an Amazon subscribe-and-save, and then moves to another city and has a different physical address, but the user does not inform Amazon by updating their address in Amazon's system (the higher level protocol), would you say that the postal service is at fault when the delivery ends up reaching the an incorrect party?

[monocasa]

It's unfortunate that WebRTC's use of SCTP doesn't require the multihoming features of SCTP. We had a great chance to sneak that into ubiquitous use, but that ship has sailed at this point. : \

Seamless jumps from mobile networks to wifi were in our grasp.

[teeray]

This is part of the special sauce that LTE adds, so that you can pretend that IP handles roaming just fine. That and also QoS guarantees, which IP also doesn’t do out of the box.

[Nextgrid]

I believe "Mobile IP" was designed to solve this exact problem.

[ajsfoux234]

There's the Multipath TCP protocol for use cases like this:

https://en.wikipedia.org/wiki/Multipath_TCP

For example, Apple already uses it when you ask Siri a question on an iOS device. Hopefully this standard gains more usage.

[londons_explore]

Multipath TCP sadly seems to have died... I believe it was incompatible with internal load balancing systems at some big companies, so nobody deployed it.

[ryukafalz]

I mean, I haven't deployed it on my own servers just because it still requires a kernel fork to enable on Linux. There was an effort to upstream it as of late 2019 though; not sure if that's stalled, but I can understand it taking a long time as I believe it's a pretty big change to the Linux networking stack.

[toast0]

Apple deployed it in iOS and macos. You can access it as a developer of either.

There is a load balancing issue, but I don't think it's any worse than http/3 which also allows for peers to change IP (http/3 has a much limited scope of changes).

[marcthe12]

IP breaks but there are way to workaround if layer 4 allows. Unfortunately TCP also breaks. UDP allow a workaround over that. So MOSH(SSH) and QUIC(HTTP/3) can deal with this due basically due to having nachnism to handle it and also they are UDP. Also both have some kind of cryptography layer such as SSH or TLS so prob that is use to handle it.

[rjsw]

There is MobileIP [1]. I have MobileIPv6 compiled into all my mobile devices and home gateway.

[1] https://en.wikipedia.org/wiki/Mobile_IP

[mordechai9000]

You currently can't change your endpoint address on existing connections without breaking them, unless you have a protocol that's aware of the possibility and uses a broker or some other method to re-establish the link. This wouldn't really be any different. I don't think you'd want your network address to change on a mesh, it would just find a different path to reach it.

It might make sense to use something similar to MPLS that can encapsulate IP, to hide the details of the mesh network.

[josephkern]

SCPS-TP and SCPS-NP are probably a good starting point for further protocol research into bit-efficient and "hostile" communications environments (long-delay, error prone, etc).

https://en.wikipedia.org/wiki/Space_Communications_Protocol_...

[perryizgr8]

> It's the same reason switching from WiFi to Mobile data and back causes a reconnect in video calls.

This used to be true, but new apps like Duo handle it like a champ. Uninterrupted switchovers between mobile data and wifi.

[londons_explore]

If I switch off wifi of my phone mid call, it drops 20+ frames. That isn't exactly seamless. It's far worse if I just walk out of range

[perryizgr8]

Hmmm, I don't know what's different in your case. For me it switches very seamlessly if I walk out of wifi range. No dropped frames. I haven't tried manually switching off the wifi though.