Re:Upstreaming multipath TCP
by throw0101a on Friday September 27, 2019 @08:10AM
(#21090964)
> The problem is then how does the network know where my IP address is. When a packet aims at my loopback, how does it work its way to me?
Mobile IP:
> The basic idea behind the separation is that the Internet architecture combines two functions, routing locators (where a client is attached to the network) and identifiers (who the client is) in one number space: the IP address. LISP supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme (RFC 1955). In LISP, both identifiers and locators can be IP addresses or arbitrary elements like a set of GPS coordinates or a MAC address.[2]
* https://en.wikipedia.org/wiki/Locator/Identifier_Separation_...
Re:Upstreaming multipath TCP
by despair3435 on Friday September 27, 2019 @09:27AM
(#21091684)
Very complex solutions that don't scale.
And we still need to assign at least one /32 to every mobile device.
IPV6 and give a /64 to each device. That's fine, however you're still with a routing table of upto 2^64 entries. Currently BGP routing table is upto 2^24 entries, but it's really less than 1 million entries.
BGP is not the answer to multi path devices for many many reasons. Tackling it at higher levels (OSI 4-8) is the solution.
The problem is then how does the network know where my IP address is. When a packet aims at my loopback, how does it work its way to me?
The answer is the same as interface addresses - we use routing protocols for that, mainly today that's OSPF (in local networks) and BGP (globally).
Convergence takes a relatively long time for BGP, and BGP (at least at a global scale) is limited to /24s. ISPs won't accept your /32 advert.
Even if they did, traffic still only goes in one direction from a given host. On top of that, theoretically if every BGP peer rand BFD you might see failovers in a few seconds, but that's not the real world.