Protocol Wars
en.wikipedia.org
en.wikipedia.org
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.
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.
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, not Zoom's software. That's what leads to things like 1,000 ms latency, which makes back and forth conversation very difficult. Moderate-to-major perceptible latency issues in conversation are always because of the network.
And yes some 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.
From Google you can see that IPv6 usage is around 40% now and steadily increasing: https://www.google.com/intl/en/ipv6/statistics.html
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.
But all the stuff that seems obvious now couldn't have been learned without the decades of kind of terrible hackery that is OSI and the associated awful stuff like DNS.
I'm not sure what the moral of that story is or how anything could have been done any better. Maybe the software APIs could have been less coupled to the actual protocol, they could have designed things so app code had to be agnostic to the number of bits in an IP address, etc.
I’m not really a network guy, but the thing I find interesting about QUIC is that it’s upgradable. Normalising regular browser updates was a godsend for the web, while TCP/IP remains hard to upgrade because you still, in 2023, have to upgrade your whole OS.
Protocols like TLS that sit outside the OS seem to have been much more dynamic, and that too is the promise of QUIC. It might be interesting to find operating system primitives that enable use of the networking hardware without having to implement the protocol itself. Although that stuff is above my pay grade.
It only takes a few more steps for this model to trickle down to general applications, as HTTP and RPC stacks pick it up.
Both io_uring and eBPF would allow us to handle more complex tasks inside the kernel, reducing context switch losses yet still allowing the benefits of a upgrade-able structure without having to upgrade the OS or even the kernel itself.
But still, it seems conceivable that a networking kernel module could talk exclusively to an adaptor shim that is part of the kernel.
idk, I actually haven’t so much as compiled a kernel since the late 90s, so I’m pretty much talking out the wrong end :)
On the one hand, the fact the TCP is unchanging has led to network cards supporting TCP directly. You can shove a large segment of data in the network card and it will split the data up in TCP segments and transmit them. There are also big content companies that let the kernel do all TLS encryption, in some cases that can also be offloaded to hardware.
The big problem for TCP is all the boxes on the internet that understand TCP and don't understand TCP extensions. That could be home routers doing NAT, firewalls, etc. Those boxes are not only hard to upgrade, they also break things. QUIC fixes this by making sure that as much as possible is encrypted.
Some ISPs monitor TCP headers and from retransmissions they can figure out where problems are in the network. QUIC will take that ability away.
So QUIC is a mixed blessing.
If there’s a financial incentive (better performance or whatever) then the server side will upgrade; it’s a financial and timing decision with strong motivators.
But the client side problem is 5-6 orders of magnitude larger than the server side problem - and to make things worse, they basically don’t care.
People seem happy enough to upgrade their browser, but upgrading their OS is a big deal. Even I don’t like doing it, and I consider it important.
So I think a reasonable rule of thumb would be, the server side will take care of itself. But if you need your clients to reboot their computer to upgrade the network stack to improve your server performance, well, it ain’t gonna happen.
I wish we all could learn that "because it works now" is a valid reason to resist change, and that assuring back compatibility is a condicio sine qua non for every change that we want adopted by people at large.
I think an IPv8(Apparently we skip odd numbers) could be a real practical thing one day though, because a lot of things really do with quite work that well. The classic "it's always DNS" meme seems to be very real, tying TLS to domains instead of IPs impedes anything on LAN, IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
Insecure DNS doesn't need to exist outside of MDNS, and even MDNS could at least have pairing prompts, if all records are signed and everything is secured at the IP level(Embedding key hashes in the IP), then certificate authorities don't need to exist either.
MACs don't really need to be a thing either outside industrial niche stuff, if we mostly just do IP traffic, that extra framing and the lookup/translation layer can go away.
Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.
A lucky few of us have had the pleasure of working with ST-II, AKA IPv5:
TLS doesn't care what's in the certs, that's an application concern. IP addresses work fine in x.509 certs, but are discouraged because of difficulty of validating that control of the IP will continue through the certificate validity period. But this wouldn't much help for your LAN use case, assuing you're using RFC1918 addresses, because no one can prove control of those, so no publicly trusted CA should issue certs for them. Same thing if you use ipv6 link local, although I don't know too many people typing those addresses, mostly people want to type in a domain name, and if you make a real one work (which is doable), you can use a real cert; if not, not.
> IPv6 has too much inconsistency in how many bits are allocated to customers, and would be much saner with a more structured ISP/Region/Subnet/DeviceChosenIDThatIsTheSameEvenIfYouChangeISPs scheme so every ISP got the same number of bits.
DeviceChosenID that is the same everywhere is kind of a huge privacy thing that we already had and mostly rejected. Giving every ISP the same number of bits is silly anyway; Comcast needs more bits than [ISP that only serves California], and heirachical addressing is lovely for humans, but not necessarily a great way to manage networks; each regional portion of the network is going to end up doing its own BGP anyway, at which point, the heirarchy doesn't make a huge difference.
> Some level of onion routing could probably just be built right into IP itself, there's not much reason an ISP or even the local wifi router needs to know the destination I'm sending a packet to, if there's a fixed heirarchal structure, it just needs to know the recipients ISP, and the rest could potentially be encrypted at the cost of some negotiation setup complexity.
Source routing exists in RFCs but was quickly dropped. There's a lot of security reasons, but also it just doesn't work that well. The destination is needed to make the best routing decisions.
Say you're in Chicago, sending to me near Seattle, and our ISPs peer in Virginia and Los Angeles (which is a bit contrived, but eh). If you send to the nearest peering, traffic will go east to Virginia, then west to Seattle. If you look up by destination, you'll more likely go west to LA, then north to Seattle and total distance will be much less.
If you need to renew, you just get a new IP and tell DNS about it, if you're using fixed IPs and can't easily renew without manual work, you're still better off than no encryption.
Instead of proving control of a domain, you'd be proving that an IP is one of the correct ones for a domain.
Tech is advanced enough now that we don't need to conserve every single bit. What you lose in efficiency, you gain in easily being able to tell what part of the IP corresponds to one customer for antiDDOS ratelimiting and the like.
Source routing would probably be best as an optional feature. But if you had a hierarchy with a part explicitly tied to the region, you could source route to the county level at least or even data center level without needing to reveal the exact destination.
https://en.wikipedia.org/wiki/Lindy_effect
by the way DNS is wonderful.
It does seem to suggest that frequently switching protocols all the time like we switch web frameworks would be awful though. The benefits of having any universal standard at all can outweigh the flaws in just about anything, even Ipv4 or in some cases even analog stuff.
https://www.mcgill.ca/oss/article/student-contributors-did-y...
You missed the point. Lindy law proves that being optimal is not necessary for an idea to be successful. Your association with natural selection is valid from this point of view, too.
Something like DNS is necessary, but I'd use individually digitally signed records except for mdns, and if you couldn't reach upstream, you wouldn't ever just drop stuff out of the cache.
I'd get rid of certificates entirely though. Without any insecure DNS, you
I'd also change IP addresses to be longer, maybe even 256 bits. 48 would be reserved for identifying an ISP (And large ISPs would have different codes for different regions), 16 would be reserved for whatever the ISP wanted to do with them, 32 bits would mark a customer, 16 would be for a customer subnet, and the rest would be chosen by the device, based on the hash of a public key.
All communication would be secured at the IP level, if you have the right IP, it's all good, if you want to refresh your "certificate" you just get a new IP and tell DNS about it.
Since the last section of the address is enough to uniquely identify the device, you can move between providers while still keeping your cryptographic identity.
Which also means that any kind of decentralized DHT routing can work transparently, the first half of the address is just routing info you can ignore if you have a better route, like being in the same LAN.
DNS servers could also also let you look up the routing info just given the crypto ID of a node, so you don't need a true static IP.
You could also do the same lookup with a local broadcast, and then cache the result for later use, so your phone can find your IoT devices, and then access them on the go with the cached routing info, if DNS is down.
A special TLD could exist that's just the crypto ID in base64, that doesn't require any registration. You can't spam too many of them, because you can reliably IP identify customer numbers unlike with ipv6 which makes that rather hard.
The people supporting TCP/IP had a head start and out-executed the OSI committees and it wasn’t even funny.
Another one of the "well-done in theory, but left in the dust by reality" approaches: X.25.
But IETF, with their emphasis on practicality, on "rough consensus and running code", was far more on the agile end of the spectrum than OSI was. IETF would recognize a problem, have an RFC, and have working implementations before OSI had done anything. This meant that if you wanted something, your first chance to get it (often by years) was on the IETF road, not on the OSI road. Repeat that a bunch of times and the people who could benefit from new things all moved to the IETF standards.
Then the next (?) year there was access to the "PAD" (Packet Assembler Disassembler) to JANET, from which one could issue a command to connect to an X.25 address. I still remember the number of NSFNet relay, 00004001018057 [1], which in turn allowed you to telnet to other internet services. I think I logged into Nyx and a few other BBS-like things.
Then I did an industry year at ICL, a British computer company long-since engulfed by Fujitsu, where they were also X.25 focused for big networks and Novell Netware focused for small networks - but the web was starting to be a big deal and I couldn't get anyone to listen. I have an anecdote about downloading the SLS Linux distro via an archive re-mailer that I won't bore you with right now :)
Then, in my final year back at the university, the web seemed to explode and the X.25 stuff had more or less disappeared.
In retrospect it's amazing how quickly this changeover happened, even if it had been bulbbing away in the background for a long long time. From my perspective the WWW looked like the catalyst that pushed everything in favour of TCP/IP.
[1] If I remember rightly, the adjacent address 00004001018056 was another Vax somewhere that hosted a bunch of LaTeX stuff?
Then people who went to school in the late 80s took that to $WORK in the early 90s, and by the mid-90s everything that wasn't TCP/IP had died. Novell's IPX, for example, was a thing still in the mid-90s, but a dying thing. Winsock for Windows 95 was the last thing that was needed to make TCP/IP rule -- after that there was just no way to do anything but TCP/IP.
It was a matter of network effects.
I'd have friends over, and we'd want to play DOOM multiplayer. The only problem was that as kids we had no idea how networking worked. We'd fiddle around on the Windows networking setup, and there'd be a list of protocols like IP and IPX. Words like Token Ring would appear. Just a blur that 15 year old kid had no chance against.
Curiously despite being a network with only two computers, you couldn't just assign any IP address you wanted. The mask was also an interesting thing, examples would have a bunch of 255s but sometimes a smaller number like 248, and then zeros. I never figured this out until I grew up.
So then we'd goof around a bit more and set it to IPX, which sounded related. Somehow we got that to work eventually.
Nowadays if you just understand IP, you're mostly fine. It's probably easier to learn as well without competing protocols with similar jargon.
I vaguely remember Age of Empires had some options for more esoteric network options, but it was pretty obvious pretty quickly that they were hopeless.
Earlier, as you mention, networking was for grown-ups to figure out only. Nowadays you don’t need to learn anything about networks to play most AAA games (I bet some folks learned a lot setting up Minecraft servers though).
I didn't understand why it wasn't a mere footnote. The professor came across as a sore loser, because it was unambiguously clear that OSI was firmly dead.
That's a bunch of time I'll never get back.
That was nothing, though, compared to the X.400 course...
For example, the fact that presentation and application are separate layers, and that compression/encryption are better in their own layer (presentation) rather than totally integrated in the application.
CRIME attack enters the chat
Compression is not better in its own layer. See the CRIME attack on TLS compression.
Encryption is better at as low an end-to-end layer as possible so that we can have a hope that we can off-load the work to hardware.
Parts of the internet are still stuck in the 1980s, my pet peeve being the DNS resolution protocol which calls on recursing resolvers to try TCP after receiving a successful UDP response with TC=1. (Where did this become "only"? When did it become ok not to support TCP?)
Seems like IP works just fine on top of ATM. Maybe the MTU isn't the same as ethernet; too bad.
By the way UDP frags are bad; don't do that. Guess it's not completely transparent afterall and relying on a kludge mechanism as the answer to knowing the terrain (MTU) isn't the One True Way.
TCP is a reliability mechanism built on top of IP. It has enough popularity to have its own protocol designator so that you can't say it's "built on top of UDP". Don't want that mechanism? Don't use it.
Want messaging? Use a datagram protocol; that would be UDP (unless you decide to use your own special protocol ID). It's unreliable? Do something about it. (See where I'm going with this?) Craft your messages so that they fit in a single packet. Invest in some decent networking gear that reports dropped packets and allows traffic shaping. Bonus: get one-to-many and transit-based destination editing.
If you refuse to compromise on your abastraction and are too cheap to afford SDN, create a virtualization layer for your network traffic like everybody before you... it's virtual turtles all the way down or hasn't that occurred to you?
The big deal for operators is resource consumption and latency. In the vast majority of cases where the UDP reply is not truncated, using UDP is both cheaper and faster.
Given the context of where we're discussing this, mind if I ask: Why is UDP so attractive for DNS operators? Is it that it encapsulates the message query / response paradigm so well?
Why isn't encryption of greater concern? How can DoT or DoH be "faster" than UDP? Is it really the protocol or a misattribution of causality actually based on LFNs, buffer bloat, and mis- or mal- construction of the tenet that UDP traffic can be dropped with no consequence (instead of employing traffic shaping, for instance).
Honestly, lay it on me: explain to me about messaging versus pipes using DNS as an example.
DoT and DoH are certainly not faster than UDP. It is only in the long tail that DoT and DoH work better.
If encryption is required for DNS, then obviously UDP and plain TCP not suitable. But operators of authoritative DNS servers are very reluctant to support DoT. The IETF is still trying to hash out how to use DoT between recursive resolvers and authoritative server.
It's not fair to conflate "DNS operators" with the relationship between authoritative and recursive operators.
The (main) problem with encryption has to do with context. In order to achieve privacy, key and/or secret material needs to be negotiated between the ends and this context needs to be retrievable for reference. There is no provision in the DNS for that. There is no provision in the transport per se either. I argue that this is appropriate and correct, that generating and negotiating this material is a separate concern and developing the protocols to do so proceeds on a different track (QED).
A better term than "connection" for the concept we are about to discuss would be "circuit". Once in possession of the approprate key material (and the out of band signaling this implies) it's possible for the parties to exchange individually encrypted messages in the open, but this ignores network issues such as dropped packets and fragmentation to name a couple. This could be dealt with but it is not a general solution.
If you're going to solve problems it's generally accepted that it's prudent to solve them generally: hence the notion of a circuit. (Frags and dropped packets are other general problems to be solved by a circuit implementation.)
It's easy to see that such a generalized circuit is a tunnel and that UDP (or TCP) packets of arbitrary size (up to architectural limits, but significantly larger than either ATM or ethernet frames) can transit such a tunnel with guarantees of no loss and no fragmentation.
DNS specifies a very lightweight convention of its own for encapsulating UDP traffic in a TCP tunnel: the payloads are prepended with with a (2 byte) length word [0]. The tunnel protocol (carefully) doesn't even specify that responses via this tunnel need to preserve the ordering of requests. Bearing in mind that context needs to be preserved for each (active) request, the context required for the tunnel itself is amortized by the number of requests using the particular tunnel instance or circuit. (No need to worry about frags, all messages are preserved up to the architectural limit specified by the underlying DNS protocol.)
So, this is one example of solving the message-vs-stream dilemma in the real world. We can see that IP-over-IP is a real thing and that DNS provides a point solution for eliding frame size issues but that more general solutions also exist which also support e.g. encryption.
The key architectural consideration is mostly who maintains the circuit context and where it is maintained.
[0] Yes of course the redundant IP header is omitted for the encapsulated messages.
In the general case frags are always bad, and instead of blocking DNS over TCP your firewall should be alerting on them.
In the case of the DNS resolution protocol, UDP frags are double-bad. The protocol (not updated since the 1980s) specifies that TCP retry should only occur if a UDP response is received with TC=1; if the UDP response is dropped, TCP retry never occurs. In the case of a UDP frag if a portion of the original datagram is dropped the response is never reassembled, TC=1 is never observed, and TCP retry never occurs.
> During a dispute within the Internet community, Vint Cerf performed a striptease in a three-piece suit at the 1992 Internet Engineering Task Force (IETF) meeting, revealing a T-shirt emblazoned with "IP on Everything"; according to Cerf, his intention was to reiterate that a goal of the Internet Architecture Board was to run IP on every underlying transmission medium.