On Oct 9, 2019, at 14:43 , bzs@theworld.com wrote:
OK OK OK.
Can I summarize the current round of objections to my admittedly off-beat proposal (use basically URLs rather than IP addresses in IP packet src/dest) as:
We can't do that! It would require changing something!
No… You can summarize it as “Doing things that way would break lots of useful things without yielding much in the way of practical benefit.”
I've no doubt many here are comfortable with the current architecture.
Well, sure, but I bet most of us would jump at the chance for something better if we actually saw such a thing. I’m all for trying out the wild and crazy ideas that might yield benefit. I just don’t think that what you have proposed so far actually qualifies on that last part.
Bits is bits.
Yes and no. At the lowest possible layer, a bit is a bit is a bit. However, when you add abstraction and assign meaning, such as ASCII characters, double-precision floating point, URLs, IPv6 (or if you must, IPv4) addresses, OSPF Areas, Autonomous System Numbers, etc., then groups of bits start to take on additional significance. It matters how we represent, process, interpret, store, and manage those bits. Different methodologies of each of those tasks are more or less appropriate for each given application. For example, a straight twos-compliment binary numeric interpretation of a 64-bit wide field with the MSb for sign and the remaining bits as significant digits is fantastic for integer arithmetic, but nearly useless for arbitrary precision manipulation of fractions. On the other hand, IEEE 754 floating point format of 32 bits where the MSb is for sign, the next 8 bits represent the exponent, and the remaining 23 bits represent the significant digits (“fraction” in IEEE terms) is very useful for arbitrary precision manipulation of fractions, but not at all good at integer math, especially for integer numbers that require low order precision, but have values greater than 2^23. Similarly, the current structure of IPv6 (and if you must, IPv4) addresses provides tremendous utility for moving packets about the internet. It’s not great at providing human-readable destination addresses. It’s also not great at providing geographic location information. Both of those are tasks for which those particular representations were never intended. There’s a reason that we have compact cars and B-trains (double trailer tractor-trailer rigs). A compact car is lousy at moving massive quantities of products. OTOH, a B-Train doesn’t fit in the average parking space very well and is hard to maneuver down most residential streets. (It also gets really lousy gas mileage for single-person transportation). We purpose build things in different ways to optimize them for different tasks throughout human history. Addresses are no different.
URLs are, to a machine, just bit strings though they do incorporate a hierarchical structure which isn't that dissimilar from current network/host parts of IP addresses.
Well, yes and no. For example, it’s not uncommon for a domain, say toyota.com, to be widely distributed across multiple networks of wildly different topologies. With the exceptions of anycast and multicast, it’s very unusual (I’d even venture to say unheard of) for a globally scoped address to be usefully deployed on multiple connected disparate networks without some sort of translator in the middle). Neither end of a URL provides anything resembling network topological hierarchy.
URLs are an obvious candidate to consider because they're in use, seem to basically work to identify routing endpoints, and are far from a random, out of thin air, choice.
In reality, you’re not really talking about URLs here, even. You’re talking about DNS host names. (The part before the // isn’t really part of what you want to consider in your network routing scenario, neither is anything that comes after the first /). It’s not that we couldn’t use some form of hierarchically structured human- readable name for this purpose… It’s that using DNS host names _REALLY_ wouldn’t work well.
Given the vast improvements in hardware since we last seriously thought about this (ca. 1990, IPv6) perhaps this worship of bit-twiddling and bit-packing may be a bit (haha) like those who once objected to anything but machine language programming because HLLs were so inefficient!
Or, perhaps, it’s not actually a love of bit-twiddling so much as a recognition that there are serious flaws with the idea of trying to use DNS host names for routing decisions. Come back with a more useful naming scheme that takes topology into consideration and lines up where routing decisions need to, and let’s discuss it more seriously. Continue pounding on DNS host names and you’re not going to make much headway because, well, it’s not quite the dumbest thing I’ve ever heard, but it isn’t that far off.
P.S. It was from a talk I gave in Singapore to the local HackerSpace and intended to provoke thought and discussion but not just "no, we can't do that because that's not the way we do things.”
I think dismissing the comments here as “no… that’s not how we do things” really fails to take proper heed of some of the comments. Owen