101–104 of 104 posts
Earlier quoted context omitted.
Nobody cares about those middleboxes, those are only relevant in corporate networks.
Such middleboxes can also be seen in cellular networks. (And firewall in free access points / guest networks)
Complain to your ISP if they mingle with a layer they are not supposed to mingle with.
>(And firewall in free access points / guest networks
I consider those as "corporate".
Earlier quoted context omitted.
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.
> TCP has no notion of IP address in the protocol, 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 simu…
This doesn't make much sense to me. The hardest problem here is not assigning uuids to pipes, it's the routing/mapping of the "true destination".
- If you manage to solve it on L3, ip-ip tunnels or not — you have it, TCP works unmodified and so does UDP and everything else including quic and http/3.
- If you didn't solve it, then support for persistent connections in TCP is useless.
In another words I don't see what a "transmission control protocol" has to do with it. It's very reasonable to assume that addreses are already figured out when designing transmission control and that's exactly what TCP did.
Earlier quoted context omitted.
> TCP has no notion of IP address in the protocol, 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 simu…
So you want to implement persistent connections on L4 without implementing persistent addresses on L3 first? This doesn't make much sense to me. The hardest problem here is not assigning uuids to pipes, it's the routing/mapping of the "true destination". - If you manage to solve it on L3, ip-ip tunnels or not — you have it, TCP works unmodified and so does UDP and everything else including quic and http/3. - If you d…
SCTP and multipath TCP (which is what we're talking about) already do pretty much this. Assuming that endpoints to a stream connection have single, unchanging network addresses isn't a reasonable assumption anymore. But we're stuck with the assumption that hosts won't move in one of our most common protocols.
https://en.wikipedia.org/wiki/Multipath_TCP#/media/File:Diff...
https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
In the OSI model, you got similar functionality up at layer 5, but TCP only handles the connection/disconnection aspect of the session layer. In the internet world, we have a bunch of haphazard sets of retries, session balancing, multihoming and reconnecting behavior that are protocol specific (and completely missing from many well-used protocols) kludged on top. (Actually arguably MP-TCP is a session layer on top of TCP).
The only way you solve this on layer 3 is to build some kind of messy overlay network, because addresses have no real relation to where things are anymore. And we know that overlay networks are suboptimal and inefficient. Solving it at layer 4 doesn't have to be (but it's too late for that now).
Earlier quoted context omitted.
At home/lan we use LACP, VRRP... I mean link aggregation and HA needs are solved time ago. With multiple ISPs, or on a complex enough LAN, we can use multiple routing tables + weights too. Also, if the ISP at home can do 10Gbps, 1Gbps, 300 Mbps whatever... I want to be able to use them with a single path, so there is no gain using multiple paths. Eventually, when I have cable+wifi connected at the same time, I use to…
> Also, if the ISP at home can do 10Gbps, 1Gbps, 300 Mbps whatever... I want to be able to use them with a single path, so there is no gain using multiple paths. Eventually, when I have cable+wifi connected at the same time, I use to force one of both, cannot see a reason to prefer using both at the same time. > I don't understand why you would want to be able to use them with a single path. the gain would be being a…
So, If I already have a 10 Gbps path to the router, I don't want to add a 300 Mbps failing air path added to my way to the router.
In the context of the parent (at home networks), I think most people has two paths... WiFi or RJ45-UTP. And with that multipath setup (WiFi + RJ45, I don't get why other comments are talking about cellular networks "at home") is not usual to walk away; right, you could walk, as far as long is the rj45 cable, but...
To keep HA on WiFi when walking around, there are other technologies more battle tested than MPTCP.
