The spread and reach of TCP/IP will accelerate at a pace faster than that of the transition to IPv6 indefinitely, therefore we are saddled with IPv4 until the end of time.
If I were to list impediments to the technical development of the Internet, local telco monopolies would be much higher in the list, but it's another kettle of fish.
Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.
I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.
I would challenge you to find someone who knows the difference between Ethernet broadcast and multicast without looking up the answer. They are very similar mechanisms.
NAT64 is involved on the level of TCP & UDP, not lower level protocols.
Unless you were using Windows, where IIRC the IPv4 and IPv6 stacks were separate, and a single socket couldn't be used to listen to both at the same time. (This might already have been fixed in more recent Windows releases.)
IP is usable to the Moon but a lot of protocols would need latency constants adjusted and very large packets would be desirable. Store and forward with custom replication protocols might still be more efficient for large volumes of data.
But even if it is, TCP can be used with any latency if you configure the timeouts accordingly and maintain a large enough send buffer to allow retransmissions.
SSH's "master" mode connection sharing would benefit from QUIC / HTTP/3 head of line blocking elimination just as much as browsers would. Run a heavy rsync using connection sharing with an interactive session and you'll notice the interactive sessions latency suffering noticably.
Long-lived SSH connections would benefit from QUIC / HTTP/3 session survivability.
All the mobility benefits of QUIC mean nothing when the rest of the software stack isn't designed to let it work.
* Android lets an application talk over both wifi and 5G at the same time.
* Android exposes information about signal strength on a per packet basis, so that the application can decide at some point that too many packets are too close to not being received, so it's time to send data over 5G in addition. It should also expose data about packet retransmissions at the physical layer (ie. collisions and backoff times due to another device using the media).
* When the 5G data flow is established and channel parameters like delay and loss are characterized, then stop sending data over wifi.
* And since this process never involved delaying any data by a roundtrip, nor any packet loss, there is no need to drop any frames.
Note that the cell network has been able to handoff voice calls from one cell tower to another without glitches since the 80's!.
I wonder if you don't see this with cell phones because the latency is generally identical, or if it's just less noticeable with audio than with video? I guess I'd also wonder if cell towers really do hand off without glitches, since there always seem to be glitches when you're driving, but you don't have the slightest idea whether they're from tall buildings or interference or Bluetooth or handoffs or what, or even on your end or the other person's end.
But networks absolutely can add major latency, have you never had a slow Zoom call? It's because of congestion building up and radio interference. That's what leads to things like 1,000 ms latency, which makes back and forth conversation very difficult. Perceptible latency issues are always because of the network.
And yes products do time stretching but that's also what people often call glitches because it's very weird.
Why not? It is not obvious to me why a seamless transition is impossible?
Isn't the whole point of TCP that individual packets can take different paths over different networks and when they reach the destination they can be sequenced? Why should changing the network disrupt the individual packets from traveling independently?
- Find the new address; i.e. Cell provider vs. Residential/Business ISP - Associate the new address with the same flow - Duplicate packets and reassemble them, or change to "better" path interface.
I don't know the details, but some iOS network apis (Network Kit?) allow you to set a required interface type somehow. https://developer.apple.com/documentation/network/nwparamete...
If you design for this use case, you can make it work today; especially since the user is on a video call and only asking for the audio to be glitchless. Sending audio over both wifi and cell is possible and simple and would solve audio at the expense of double the audio bandwidth. More bandwidth efficient methods are left to the reader.
The Linux desktop will arrive if we just wait for Microsoft to keep making Windows worse. Linux doesn’t have to get better. MS just needs to incorporate more ads.
Depends on the ISP. E.g. a lot of Verizon/Frontier FiOS residential customers don't have ipv6. Google statistics say USA is ~47% ipv6. Frontier FiOS is less % than that.
Example recent thread: https://old.reddit.com/r/frontierfios/comments/v9azjj/june_2...
Google's statistics: https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
99.9% of the time, modern Linux works out of the box everytime.
So I'd say it's on par with Windows versions, except I practically never need to download install drivers, or to face ads.
Maybe I'm on a different planet on which the year of the Linux desktop has arrived for longer than a decade.
This lets your server take a dial string and listen on any network - even if that network isn't IP! So say you wanted to bring IPX/SPX back from the dead and use it in any program: so you write an IPX/SPX stack that binds over /net, then tell your server to listen on spx!*!555. Now your client also runs an IPX/SPX stack bound over /net and you hand the client program the dial string spx!server!555 and your program starts communicating over IPX/SPX to the server. Done. Want to use connect to an ssh server using quic on plan 9 (Assuming an imaginary quic stack)? just change the dial string to quic!host!port. Done.
Once you use an OS with clean and simple abstractions you are left craving more of it. I wish more people took an interest in building much more radical operating systems.