StarDreamer

It’s been a couple years now but…

CrossCode

You are not a network guy or you would accept just because someone occasionally fat fingers a table entry on BGP it doesn’t brink a hard link down to the less reliable wireless links.

If it wasn’t for me trying to keep my anonymity on the platform, I would love to give credentials for this. You refuse to see anything other than the densest approach with zero regard in proper networking theory, algorithmics, and beyond. YOU are not a networking guy, you are a cable install guy. You refuse to give any evidence other than ad-hoc experience, refusing to elaborate other than repeat the same thing over and over again, now claiming my “amateur understanding” as your defense. As soon as I mentioned BGP issues, your mind defaulted to “a guy making typos”, not the difficulty of algorithmic verification for BGP or the implementation differences between different vendors hardware, or the different use of metrics between different ISPs. YOU are the amateur here, exhibited by your refusal to address any of my points heads on, and misconstruing my point of practical networking errors makes it similarly impossible of hitting certain SLAs on residential networks, regardless of wireless or not. The fact that it’s wireless or not does not matter, you are NOT hitting 4 nines availability, you do NOT NEED 4 nines availability. And you are the one making strawman arguments claiming I don’t know wireless going through BGP.

Everything you said just re-enforces the problems of industry - move fast, break things, fix them never. No need to understand anything because “everything current just works and anything else is the spawn of Satan”. It’s people like you that IP is dead, nothing but TCP and UDP can make it across the Internet.

1. I’m not moving around from one point to another. I am simply stating that a majority of home users do not need the reliability and operate off of larger tolerances. Reliability costs money. If you need it, good for you. But a majority of people (including those in tech) do not need it, otherwise we’d all be on infiniband and ditching Ethernet by now. There is nothing wrong with a wireless transport, beam forming tech has come a long way to minimize interference, and direct point to point wireless IS faster than underground fiber with no retransmissions.

2. I’ve been in networking research for more than half a decade now, spanning from various forms of wireless (RFID, LoRA, wifi, 4G, 5G, etc) to wired Ethernet (1Gbps, 100Gbps, 800Gbps), at both the transport level and protocol level (Ethernet, IP, NDN, RoCE, TCP, QUIC, BGP). I’ve taught courses on how these things work. Before that, I was in IT networking for 4 years. From what we’ve seen, no matter how good you say they are, ISP and carrier operators inevitably screw it up on the configuration end (because they are human). BGP, NAT, 5G mobility are all a buggy mess because of this. When it comes to deploying new tech, corners are always cut and it comes back to bite people in the end. Wireless transport is fine, it’s human error that plagues both wired and wireless tech.

3. Shortwave for trading isn’t some “legacy shit”, it’s where industry and research is headed in the last decade. Your dismissal of new technology and skills is indicative of what this argument has been about: you start from your conclusion and dismiss all evidence before you even think. Issuing blanket statements that are too broad in scope. Everything I said has been quantified with specific assumptions and conditions.

You’re still missing my point. What type of application are you running at home that requires that level of SLA? If you are somehow running something that has that type of reliability/QoS constraints, how can you guarantee that your residential ISP with a fiber connection isn’t oversubscribing the links, causing the same sorts of periodic service disruption outside of the end user’s control?

I see no reasonable situation where user experience for home applications would degrade over wireless any more than bgp policy misconfigurations or congested links would. Especially when Spectrum drops packets to NTT almost every Monday night.

As a side note, high frequency trading uses shortwave instead of fiber for transferring data due to latency reasons. There is nothing saying wireless is always worse in latency than fiber. But that’s no longer in the realm of home use, so I don’t really think it matters.

I’ve mentioned plenty of times under ideal conditions. If the condition is as you say (where there is known massive interference) I’d say that’s a good indicator to either 1. figure out what the interference is and whether it’s possible to mitigate it or 2. Switch to a hard link. This is very much the right tool for the right place problem.

For a majority of users wireless is definitely sufficient and that they can tolerate a reasonable amount of disconnects/drops/latency spikes. I’m not saying for every scenario wireless is a good substitute, but it can definitely handle certain scenarios good enough for home users for a fraction of the cost.

Besides, if I’m not having any major sources of interference now but somehow that develops later, that’s no different than getting a congested link at peek hours, or a faulty switch somewhere along the path 2 years down the line. It’s just another form of network disruption, those can develop in the same way in hard links.

Side note: I’ve done work over ssh and webapps with a constant 200-500ms latency and periodic disconnects for prolonged (months) periods of time. It is absolutely usable though a bit slow. I’ve even played PvP in MMOs (SWTOR, ESO) with those network stats back in the day and still managed to do well enough. People overestimate the quality of Internet service they need all the time.

They were checking against a whitelist of IMEIs to force people to migrate to 5G phones. While my new phone was 5G, it was acquired internationally and thus not on the whitelist. So as soon as it got on the network, the line got terminated.

0. I agree LEO Sat is different from 60GHz. But the detrimental effects of wireless is completely overblown. People running into issues should just run a signal test first to make sure it’s not their setup that’s the problem.

1. There is no such thing as weather in SoCal (other than that one week of continuous rain each year).

2. If you are just looking at 4 9s or 3 9s latency while the link is not saturated, it’s fine for general use (assuming my first bullet point holds). It’s not like I’m running aws off of my home network.

3. Even in the rain, the latency is mostly fine. It’s usually just the minute it starts raining that the latency goes through the roof. My assumption is that it’s sampling and adjusting the modulation/coding scheme.

I don’t run starlink, but I run Starry (fixed point wireless) when AT&T and Spectrum are available because:

1. I do networking for a living, including wireless (or technically my coworkers do). I know how this thing works and what it’s limitations are
2. I live in an area where it almost never rains, so little to no attenuation
3. AT&T is on my banlist after shutting down my account for migrating to a 5G phone not on their approved list. Customer service didn’t even let me transfer the sim back to the old 4G phone. The account termination was immediate. I ended up convincing customer service that I needed my phone number for emergency contact, and immediately transferred the number elsewhere upon it being restored.
4. Spectrum routing is shit
5. Wireless can be as good (or even better) than wired in ideal conditions (see 1), my current 1Gbps plan also only costs $20/month.

Sorry, but the fungus has been burping and slurping on radiation.

The point I’m making is that IP addresses are useful/used because they are the canonical way of reaching a service. If you have a name (via DNS), it still needs to be translated into an address because routing depends on arbitrary numerical addresses.

But they shouldn’t be, and they don’t have to be. They identify an interface, not the host. We have services on a single host running across multiple interfaces (multiple ports), or in some cases multiple services running on a single interface (k8s, cloudflare), or even sometimes multiple interfaces/servers masquerading as a single interface (DNS root servers).

The correct way to handle this is to identify services by a name, which means routing itself should be handled via name, not IP addresses. This is one of the things Named Data Networks (NDN) tries to solve. In this scheme, everything has a name. Not a numeric address. Memorizing 10.0.0.1 becomes a lot less important when you can always reach your service at “foo/bar/service”.

Needless to say, this is currently not feasible because every single IP router in the world needs to be replaced with a NDN router, in which nobody would do. Vendors have already shown that when they can adapt new technologies or implement NAT, they will implement NAT.

Edit NDN wikipedia article https://en.wikipedia.org/wiki/Named_data_networking

link local

IPv4 has this too. It’s normally not routable so it’s safe to ignore in both IPv4 and IPv6.

Instead of DHCP…

The following is a gross simplification, but works for understanding the most common cases:

The original (heavy emphasis on this word) idea of IP is that addresses are unique for every interface. Additionally MAC addresses (48 bits) are also unique for every interface.

In IPv4, you’re trying to make interfaces that are unique in 48 bit IDs unique in 32 bit IDs. It doesn’t take a pigeon to realize there will be collisions. Therefore you need a person to manually assign addresses. If you automate that person, that becomes DHCP.

In IPv6, you’re making a 48 bit unique ID unique in a 128 bit namespace. You literally don’t need to do anything and you can still guarantee it’s unique. That’s how you automatically assign IPv6 addresses without DHCPv6.

As for how MAC addresses are assigned uniquely, the first 24 bits are a vendor prefix. The vendors then ensure each device they produce is unique.

With ipv6 the address is too long and incomprehensible to remember.

The problem is that nobody should be memorizing arbitrary 128 bit numbers, or even 32 bit arbitrary numbers. Especially since the numbers don’t even correspond to a machine, but instead an interface on the machine. Yes, 32 bit IPv4 addresses are easier to memorize, but you shouldn’t be memorizing them in the first place. Services run off of names. If the names aren’t working, fix the name service.

Ideally NDN solves this problem completely. Every host/packet is identified by a name, not an address. If you need to fetch something, all you need to do is provide the name and somebody (doesn’t have to be the original machine) will provide it to you.

How is IPv6 harder to understand? It’s just IPv4 with all the uncommon stuff stripped out and put into optional headers (which IPv4 also has), and a much longer address now written in hex.

CGNAT is just a fancy term for NAT done by a carrier. They get a special private IP address range for doing so, but fundamentally it’s still NAT.

Now IP multicast, THAT is complicated for humans to understand. Especially the whole subscriber logic.

that one NetBSD user bursts into flames