>>> 2020-11-28 the verboten band

To start: yes, long time no see. Well, COVID-19 has been like that. Some days I
feel accomplished if I successfully check my email. I finally managed to clear
out a backlog of an entire handfull of things that needed thoughtful responses,
though, and so here I am, screaming into the void instead of at anyone in
particular.

That said, let's talk a bit about radios. It is probably unsurprising by now
that I have a long-running interest in radio and especially digital radio
communications---but people who come to radio from all kinds of different
perspectives run into one odd problem: the curious refusal of any receiver
to tune to certain frequencies in the 800-900MHz range.

A lot of people have a general knowledge that this has to do with some kind of
legal prohibition on reception of cellular phones. That's roughly correct, but
to fully explain the matter requires going into some depth on two different
topics: FCC regulation of radio devices, and the development of cellular
phones. The first sounds more boring, so let's hit that one first.

Generally speaking, most electronic products manufactured or imported into the
United States are subject to regulation by the Federal Communications
Commission. Specifically, they generally require an "Equipment Authorization"
from the FCC prior to being marketed. For purposes of this regulatory scheme,
electronic devices can be broadly divided into two categories: intentional
radiators and unintentional radiators.

An intentional radiator is something that is specifically intended to broadcast
a radio signal, like, say, a cellular phone. Intentional radiators must be
certified to comply with the specific Part of the FCC regulations relevant to
the service for which they will be used. For example, cellular phones must be
certified against Part 27, Wireless Communications Service, among others. The
exact process varies by the part and can be involved, but it generally
involves the manufacturer paying a certified test lab to perform certain tests
and complying with various other filing requirements which include placing a
label on the device which specifies its FCC approval. Device manufacturers
must file with the FCC a description of how this label will appear before they
receive approval to market the device, which is why the rough designs of
unreleased devices are sometimes revealed by the rough drawings in these
filings---tech journalists will watch these to get the dimensions of new
iPhones, for example.

By the way, when I say the "FCC Regulations," if you want to follow along at
home these are promulgated as 47 CFR. So Part 27, for example, refers to 47 CFR
27. The ever lovely Cornell LII has the whole thing for your entertainment:
https://www.law.cornell.edu/cfr/text/47. There's some reading for when you need
help falling asleep.

But that's all besides the point, I'm more interested in talking about
unintentional radiators, devices which are not intended to produce RF radiation
but may still do so as a result of the operation of the electronics---this is
generally called a spurious emission, which is basically any RF emitted by
accident. These devices are certified under Part 15 of the FCC regulations[1], and
so are sometimes called "Part 15 devices." Part 15 essentially limits the type
and amplitude of spurious emissions to prevent random devices causing harmful
interference due to defects in their designs.

What would we call a radio *receiver*, then? It is explicitly a radio device,
but is not intended to transmit anything. As a result, radio receivers are Part
15 devices. Most of Part 15 is very general and doesn't really say anything
specific about radio devices, it just limits spurious emissions and other
design standards. However, 15.121 gets a great deal more specific in
discussing "Scanning receivers.' A scanning receiver is specifically defined
earlier in the regulation as a device capable of tuning to two or more frequency
bands in the range of 30-960Mhz. This has the fun result that nothing for the
GHz range is technically a scanner, but for practical reasons this doesn't
matter too much.

So what's in 15.121? This is:

47 CFR 15.121(a): ... scanning receivers and frequency converters designed or
marketed for use with scanning receivers, shall: (1) Be incapable of operating
(tuning), or readily being altered by the user to operate, within the frequency
bands allocated to the Cellular Radiotelephone Service in part 22 of this
chapter (cellular telephone bands). ... (b) Be designed so that the tuning,
control and filtering circuitry is inaccessible. The design must be such that
any attempts to modify the equipment to receive transmissions from the Cellular
Radiotelephone Service likely will render the receiver inoperable. 

The rest of paragraph (a) gives a pretty long clarification of "readily being
altered by the user," and it's amusing to think of a bunch of FCC characters
sitting around a table trying to think up every alteration that is easy.
Jumper wires and reprogramming micro-controllers are both right out.

It gets even better:

47 CFR 15.121(b): ... scanning receivers shall reject any signals from the
Cellular Radiotelephone Service frequency bands that are 38 dB or lower based
upon a 12 dB SINAD measurement, which is considered the threshold where a
signal can be clearly discerned from any interference that may be present. 

So, here's this actual weird rule about scanners. Scanners are specifically
prohibited from being able to tune to any bands allocated to the Part 22
Cellular Radiotelephone Service. This raises questions, and as you can imagine
from the way I got here, I am about to spend a long time answering them.

When the FCC says "Cellular Radiotelephone Service," they aren't talking about
cell phones in general. The CRS as I'll call it refers to a *very specific*
cellular service, and that is AMPS.

AMPS, the Advanced Mobile Phone System, is the most common in the US of the
"1G" cellular services. Most carriers that were around when it was offered
called it "Analog" service, and indeed, AMPS was entirely analog. And, due to
an odd detail of the regulation, large cellular carriers were *required* to
offer AMPS service until 2008, long after AMPS phones were no longer produced.
You may have had a candy bar phone back when you would occasionally see an "A"
for analog service, but I hope not into the late 2000s.

There are a few things that we might infer from AMPS being an analog service.
One of those things is that it probably did not employ strong encryption. In
fact, AMPS employed no scrambling or enciphering of any kind. Your phone
conversations were just flapping in the wind for anyone to hear. This posed a
major practical problem for carriers in the '90s as it was discovered that it
was not particularly difficult to intercept the call setup process from an AMPS
phone and swipe its identification numbers, allowing you to basically steal
someone else's cellular service. You can imagine that this was popular with
certain criminals with a need for untraceable but convenient communications.

There was also a problem for consumers: their phone conversations could be
fairly easily overheard. There were a number of ways to do this, using any
radio scanner that covered that band for example. One particularly well-known
option was a particular model of phone, the Oki 900, that had an unusually
open design (in terms of modifiability) that led to reverse engineered and
modified firmware being developed that made eavesdropping on other people's
calls just, well, a feature it had.

The scale of this problem was fairly large, and it was fairly well known. For
example, let's turn to *my* favorite source of late-night reading, newspaper
archives. A lovely piece in the 30 May 1990 issue of The News and Observer,
from Raleigh NC, takes the cheesy headline "Monitoring Megahertz" and goes
into some depth on the issue.

"I've heard men call their wives and tell them they'll be home late, then call
their girl friends," quipped one electronics store owner who had "accidentally"
eavesdropped on cellular calls using a scanner. We've all fat-fingered our
ways into someone else's affairs I'm sure, pun intended. Another person said
"when you look at the fact that there are how many thousands of people out
there who know my name, my mailing address and my salary...I put cellular
eavesdropping down as being no different from that." In the face of technology,
even in 1990, people had begun to abandon their privacy.

Cellular carriers were not so happy about this, viewing it as an embarrassment
to their operation. I have heard before that cellular carriers went so far as
to lobby for banning scanners entirely, although I am not aware of much hard
evidence of this. What they did do was convince congress to stick an extra few
paragraphs onto an otherwise only tangentially related bit of legislation
called the Telephone Disclosure and Dispute Resolution Act of 1992. This has
largely to do with abusive 1-900 numbers, which is its whole own topic in
telephone regulation that I ought to take on sometime. But it also brought
along just a bit more, an extra section that was subsequently amended several
times at the behest of cellular carriers. Let's read part of it, as amended,
and with some editing for readability.

The Commission shall prescribe and make effective regulations denying equipment
authorization for any scanning receiver that is capable of---(A) receiving
transmissions in the frequencies allocated to the domestic cellular radio
telecommunications service, (B) readily being altered by the user to receive
transmissions in such frequencies, or (C) being equipped with decoders that
convert digital cellular transmissions to analog voice audio.

Well, we've made it full circle: we've seen the regulation, and we've seen the
legislation that kicked the FCC to write the regulation. But how does this
translate today? Things get a bit weird there.

You see, the FCC seems to have (sensibly) interpreted the legislation as
applying directly to the Cellular Radiotelephone Service, even though the
legislation actually uses the term "domestic cellular radio communications
service" which seems almost equally lively to have been (1) intended to be more
general in its applicability or (2) a result of someone drafting legislation
having read "Cellular Radiotelephone Service" in the FCC regulations but then
forgetting exactly how it was worded.

The Cellular Radiotelephone Service was allocated 824-849MHz and later
869-894MHz. That's it. You see, all of the digital cellular systems we use
today are considered completely different services from Cellular Radiotelephone
(usually called Wireless Communications Service although the details get
complex). As a result, and to this day, those two sections in the 800MHz band
are verboten to scanners, and nothing else.

And about those frequencies... after the requirement for AMPS service ended,
all US carriers ceased AMPS operations. The old AMPS bands remain allocated for
cellular service, and Verizon and a couple of smaller carriers use the same
frequencies for digital cellular services, which employ encryption and cannot
be intercepted by radio scanners. The prohibition on tuning scanners to these
frequencies no longer makes any sense, especially since this ban has never been
extended to the AWS, PCS, and WCS bands that are more widely used by modern
cellular phones.

My suspicion is that the fact that this regulation was mandated by congress
makes it difficult for the FCC to remove or modify, even though it no longer
makes technical sense. Unless congress finds some time for minutiae we are
unlikely to see a change in this rule.

In general, the whole thing is sort of bizarre. Broadly speaking, it is legal
to listen in on any radio communications in the US, but cellular phones have
repeatedly gotten a special carve-out.

Repeatedly? That's right. The whole AMPS band and scanners rule is the only
specific *technical* regulation, but the Electronic Communications Privacy Act
of 1986 had actually already made it illegal to intercept or listen in on
cellular calls, and this remains true to the present day... but there was
virtually no enforcement, and that hasn't really changed to this day.

And of course the whole thing has always felt like a farce. The solution to the
poor (or rather nonexistent) security design of AMPS was never legislation, but
cellular carriers and the congress will be damned if they didn't try. In
practice, the rule swept the entire eavesdropping problem under the rug for
some years, allowing carriers to continue operating the insecure AMPS system
for far longer than they should have (...but exactly as long as the FCC
required them to).

Because listening to the modern digital cellular modes wouldn't be particularly
interesting or useful anyway, and this rule doesn't really deter anyone with
the motivation and ability to decode those modes anyway, there are two lasting
impacts of this rather particular rule:

1) SDRs and other receivers made today must implement this particular and
peculiar restriction in order to receive US equipment authorization, which is
probably part of the reason that a lot of SDRs... don't.

2) To comply with the specifics of the regulation about rejection, many
receivers use a notch filter around 850MHz in their frontend. This means that
reception throughout the 800-900MHz range is particularly poor, a real
irritation as various public agencies and private agencies (especially
railroads) use land-mobile radios elsewhere in the 800-900Mhz range.

Basically, more than a decade after any of this made sense, we're all still
hassling with it.

[1] Part 15 is actually a lot more general and unintentional radiators are
specifically discussed under 47 CFR 15.101, but everyone just says Part 15.

>>> 2020-10-18 internet to your door

Let's talk a bit about how internet is delivered to consumers today. This will be unusually applied material for this venue, and I will be basing it on a presentation I gave a while ago, so it is not entirely original. However, it is something that impacts us in a material way that few technologists are currently very familiar with: last-mile network technology.

In the telecom industry, the term "last-mile" refers generally to the last link to the consumer premises. It may be roughly a mile a long, but as we will see it can be both longer and shorter. The "last mile" is particularly important because most, or depending on how you look at it, all internet service providers employ a "hybrid" network design in which the last mile delivery technology is different from the inner portion of the network. For example, in one of the most common cases, cable internet providers employ what they call a "hybrid fiber-coaxial" network or HFC. This concept of the network being a hybrid of the two technologies is important enough that cable devices these days often label the DOCSIS-side interface the HFC interface. In this type of network, fiber optic cable is used to connect to a "node," which then uses a DOCSIS (television cable) connection to a relatively small number of homes. This reduces the number of homes in a collision domain to allow greater bandwidth, along with other advantages such as the fiber lines being generally more reliable.

This leads us an important point of discussion: fiber to the what? There has been an ongoing trend for years of technology-centric groups wanting fiber internet service. I am unconvinced that fiber service is actually nearly as important as many people believe it to be (DOCSIS 3.1 is capable of similar or better performance compared to GPON), in reality the focus on "fiber" tends to just be a proxy for the actual demand for much higher downstream and upstream bandwidth---the delivery technology isn't really that important. The fixation on fiber has, however, provided the ISP industry an in to create uncertainty for marketing advantage by confusingly branding things as fiber. One manifestation of this is a terminology clash I call "fiber-to-the-what." These terms are increasingly used in consumer and even commercial ISP marketing and can get confusing. Here's a rough summary:

Fiber-to-the-home (FttH): fiber optic delivered to a media converter which is inside the premises of a single consumer. Generally what people mean when they say "fiber internet," and typically delivered using GPON as the technology. In most cases GPON should be considered a last-mile delivery technology and thus distinct from "fiber optics" in the sense of a telecom inside network (e.g. 10GBASE-ER), as it has many of the same disadvantages of non-fiber last-mile technologies such as DOCSIS. However, FttH virtually always means that gigabit downstream is an option, which is basically what people really want.

Fiber-to-the-premises/building (FttH/FttB): Typically applicable to multi-family housing environments, fiber optic is delivered to a central point in the structure and another technology (usually GbE) is used for delivery to individual units. Common in newer apartment buildings. The "fiber" involved may be either GPON or a "proper" full-duplex optical transit technology, for which there are numerous options.

Fiber-to-the-curb (FttC): A rare branding in the US, although cable internet using a "node+zero" architecture is basically FttC. This refers to a situation where fiber optic transport is used to connect a curbside cabinet, and then another transport technology (potentially GbE) connects a small number of homes to the cabinet.

Fiber-to-the-node (FttN): What AT&T meant when they were speciously advertising fiber internet years ago. This is the most common situation today, where a modest number of homes (up to say a couple hundred) are connected to a "node" using some other transport. The node has an optical uplink.

You will see these terms used in discussions of internet service and hopefully this explanation is helpful. As I have aimed towards, something that I would like to convey is that "fiber internet" is not nearly as important as many pro-broadband parties seem to think. Similar quality of service can often be offered by other transport technologies with a lower investment. The limiting factor is generally that cable companies are terrible, not that the delivery technology they employ is terrible.

All of that said, here is a general survey of the last-mile transport technologies currently in widespread use in the United States. Overseas the situation is often different but hard to generalize as it depends on the region---for example, fiber service seems to be far more common in Asia while very-high-speed DSL variants are more common in Europe, at least from what I have seen. I'm sure there are various odd enclaves of less common technologies throughout the world.

## DSL

While the term "DSL" is widely used by consumers and providers, it's a bit nonspecific. There are actually several variants of DSL with meaningfully different capabilities. What matters, though, is that DSL refers to a family of technologies which transport data over telephone lines using frequencies above the audible range (which frequencies depends on the variant, but they generally start at around 25kHz). Unlike general landline telephony, the DSL "node" multiplexes over a large set of telephone lines, so DSL is "always connected" without any dialing involved (this is somewhat different from ISDN). 

There are a few common elements of DSL technologies. Consumers will have a "DSL modem" which communicates over the telephone line with a "DSL access multiplexer" or DSLAM, which converts from DSL to another transport technology. This depends on the ISP, but most often the actual transport protocol used within DSL networks is ATM, and the DSLAM converts from ATM over DSL to ATM over ethernet. The modem handles ATM signaling so that the connection between the modem and the DSLAM---the actual DSL segment---is transparent and basically a long serial line. Ethernet frames are passed over that link, but because there is no proper addressing within the network PPPoE, or Point-to-Point Protocol over Ethernet (say that five times fast), is used to encapsulate the "payload" ethernet frames onto the DSL network. This is actually running over ATM, so we have a situation you could call PPPoEoA. Of course PPPoA exists but is not generally used with DSL, for reasons I am not familiar with but suspect are historic. This is all a long explanation of the fact that the MTU or maximum packet size on DSL connections is usually 1430, which is your standard Ethernet 1500 minus the PPPoE headers.

It is possible to directly run IP over DSL and there are providers that do this, but it is very uncommon in the United States. To add slightly more complexity, it is common for DSL providers to use VLAN tagging to segregate customer traffic from management traffic, and so DSL modems often need to be configured with both PPPoE parameters (including authentication) and a VLAN tag.

Yes, PPPoE has an authentication component. DSL networks do not generally use "low-level" authentication based on modem identities, but instead the DSLAM accepts any PPPoE traffic from modems but at a higher level internet access is denied unless PPPoE authentication is completed successfully. This means that a DSL subscriber is identified by a username and password. Most DSL providers have an autoconfiguration system in place that allows their rental modems to obtain these parameters automatically, but customers that own their own modems will often need to call support to get a username and password.

DSL providers are generally telephone companies and subject to local loop unbundling regulatory requirements, meaning that it is possible to purchase DSL internet service from someone other than your telephone provider, but if you do so you must still pay your telephone provider a monthly fee for the use of their outside plant. In practice this is rarely competitive.

This all describes the general DSL situation, but there are two fairly different DSL variants in use in the US:

[ SIDEBAR ]

An important note for those who have not picked up on it: for historical reasons, network speeds are given in bits per second rather than bytes. This has a tenuous connection to things like symbol rate and baud rate which can become quickly confusing, so bit rate tends to serve as a good common denominator across technologies. It can be annoying, though, since most other things are quoted in bytes, and so you will often need to divide network rates by eight when doing back of the envelope calculations.

[ END SIDEBAR ]

### ADSL

ADSL, or Asynchronous Digital Subscriber Line, is the most common DSL service. The most recent version, ADSL2+, is capable (on paper) of full-duplex operation at 25Mbps down and 3.3Mbps up. It is possible, although not especially common, to bond two lines to double those capabilities. These speeds are rarely obtained in practice. The range of ADSL is generally limited to a few miles and achievable speeds drop off quickly with range. It is very common to see that ADSL speeds offered very clearly drop as you get further from the telephone exchange, as in small towns that may be the location of the only DSLAM. However, it is possible for providers to use various technologies to place DSLAMs "in the field" in curbside cabinets, thus reducing the range to the customer. A more robust technology such as ISDN may be used for upstream transit. There are various names for various different types of devices, but the simplest is a "loop extender" which is basically just an ADSL repeater.

Typical ADSL speed offerings range from 5 to 15Mbps depending on range from the DSLAM. Upstream is uniformly poor and less than one Mbps is common even for downstream speeds on the high end. The downstream/upstream asymmetry is designed into the standard frequency allocations. ADSL has a reputation for high latencies, which has more to do with the typical network architectures of DSL providers than the transport technology, although ADSL does have some inherent overhead.

### VDSL

VDSL, Very High Speed Digital Subscriber Line, is now becoming common in urban environments in the US. VDSL, and its latest standard VDSL2, is capable of much higher bandwidths using the same telephone lines as ADSL. Up to 52Mbps downstream and 16Mbps upstream is possible on paper, and pair-bonding to double these rates is common. Use of curbside DSLAMs is also ubiquitous. As a result, common VDSL speed offerings are as high as 80Mbps downstream. The useful range of VDSL is actually shorter than ADSL, and beyond a range of one mile or so ADSL becomes a better option.

VDSL is a relatively new technology. Unfortunately, DSL providers have not generally made it clear which technology they use, although you can infer from the bandwidths advertised. CenturyLink for example is deploying VDSL in many major cities and when they do so they will begin to advertise 80Mbps service, often at a lifetime rate for extra competitive edge.

## DOCSIS

The next important technology is DOCSIS. DOCSIS and DSL probably form the top two technologies in use and I suspect DOCSIS is now the leader, although DSL has a decided edge in smaller towns. DOCSIS stands for Data over Cable Service Interface Specification, and to explain it simply it functions by using the bandwidths allocated to television channels on a cable television system to transmit data. DOCSIS is very popular because it relies on infrastructure which generally already exists (although some upgrades to outside plant are required to deploy DOCSIS, such as new distribution amplifiers), and it can offer very high speeds.

DOCSIS consumers use a DOCSIS modem which communicates with a Cable Modem Termination System or CMTS. DOCSIS natively moves IP and authentication is handled within the management component of the DOCSIS protocol based on the identity (serial number) of the modem. Like DSL, modems rented from the ISP generally autoconfigure, while people who own their own modem will need to contact their ISP and provide the modem's serial number for provisioning. Some DOCSIS providers place unrecognized modems onto a captive portal network, similar to many free WiFi access points, where the user can log into their ISP account or complete some other challenge to have their modem automatically provisioned based on the source of their traffic.

The latest standard, DOCSIS 4, is capable of 10Gbps downstream and 6Gbps upstream. In practice, the limiting factor is generally the uplink at the node. DOCSIS also functions over fairly long ranges, with tens of miles generally being practical. However, as consumer bandwidth demands increase DOCSIS providers are generally hitting the limits of the upstream connection used by nodes, and to address the problem and improve reliability they are deploying more nodes. Many major DOCSIS ISPs are moving to a "node+zero" architecture, where the "plus zero" refers to the number of distribution amplifiers. The goal is for all consumers to be directly connected by a relatively short cable run to a node which serves a relatively small number of users. The node uses multi-gigabit fiber for uplink. This forms the "hybrid fiber-coaxial network" and is practically capable of providing 1Gbps or even 2Gbps symmetric service.

Unfortunately, I am not currently aware of a DOCSIS provider which actually offers symmetric Gbps service. Technical challenges related to legacy equipment make it difficult to allocate additional channels to upstream, keeping upstream limited to as low as 20Mbps. Unfortunately the "legacy equipment" involved here is set-top boxes in customer homes, which are very difficult to widely replace even besides cost.

DOCSIS provides relatively rich management capabilities as a core part of the protocol, which is why, for example, DOCSIS providers can usually remotely command the customer modem to reboot as part of troubleshooting even if it isn't ISP-owned. These protocols also allow the ISP to push firmware to the modem, and most ISPs refuse service to modems which are not running an ISP-approved firmware version. This is not entirely selfish as the nature of DOCSIS is that a malfunctioning modem could disrupt service across many users.

Further, DOCSIS ISPs often make use of a higher level management protocol called TR-069 which is based on HTTP interactions between the modem and an ISP-operated management server. TR-069 provides the ISP with much greater ability to configure and manage the modem and enables features like changing WiFi network options through the ISP's mobile app. Appreciable security concerns have been identified related to TR-069 but have been overblown in many reports. Unlike DOCSIS's integral management capabilities (which are comparatively very limited), TR-069 must be explicitly configured on the modem, there is no magical discovery of the management server. As a result, if you own your modem, TR-069 is generally not a factor.

I would assert that, from a purely technical analysis, DOCSIS is generally the best choice in urban areas. While it does have limitations compared to GPON, it is significantly less expensive to deploy (assuming existing cable television infrastructure) and can provide symmetric gigabit. Unfortunately, a set of problems including not insignificantly the immense stinginess of cable providers means that more typical DOCSIS offerings are up to gigabit downstream and 50Mbps upstream. For DOCSIS to reach its potential it is likely that the cable industry will first need to be burnt to the ground.

## WISPs

An up-and-coming last-mile technology is the wireless ISP or WISPs. Although there are other options, WISP virtually always implies the use of point-to-point WiFi in the 5GHz band for last-mile delivery. Proprietary extensions or modifications of the WiFi standards are often used to improve performance and manageability, such as overlaid time-division multiplexing to allow closer positioning of antennas without interference.

While WISPs are proliferating due to the very low startup costs (less than $10k with some elbow grease), they face significant technical limitations. In practice WISPs are generally not able to offer better than 40Mbps although there are some exceptions. Weather is usually not a significant challenge but trees are and some areas may not be amenable to WISP service at all. Many WISPs are recent startups with few or no employees familiar with commercial network operations and so reliability and security are highly variable.

Less commonly, some WISPs use non-WiFi technologies. There is limited use of unlicensed low-power LTE for consumer internet service, and then a few proprietary technologies that see scattered use. There may be some potential in 11GHz and other point-to-point microwave bands for WISP use although devices to take advantage of these are fairly new to the market.

Overall, WISPs are exciting due to the flexibility and low startup costs, particularly in more sparsely populated areas, but are generally incapable of meaningfully competing with VDSL or DOCSIS providers in areas where these exist.

## GPON

Fiber-to-the-home generally implies the use of a Passive Optical Network or PON, most often in the Gigabit variant or GPON. PONs use time-division multiplexing to allow multiple stations (generally one "main" and multiple "consumer") to signal bidirectionally on a single fiber optic cable. They are called "passive" because each consumer is connected to a "trunk" line using a passive splitter, which is essentially a prism. A GPON consumer has an Optical Network Terminal or ONT which communicates with an Optical Line Terminal or OLT at the service node. PON networks generally use IP natively, so the ONT and OLT are essentially just media converters.

PON networks are half-duplex at a low level, but time slots are usually allocated using a demand-based algorithm and in practice performance is very good for each consumer. Combining PON with wavelength division multiplexing can improve the situation further. The range on GPON goes up to 20km with up to 64 end users on each fiber, some variants allow more of each. Symmetric gigabit service is often offered.

GPON can offer very good service and is inexpensive compared to the fiber technologies used inside of ISP networks, but there is rarely existing infrastructure that can be used and so deploying GPON is a very expensive process. Nonetheless, for the rare ISP which has the capital to compete with the cable company and isn't, well, the cable company, GPON is generally the delivery technology of choice as it offers speeds competitive with DOCSIS without any of the overhead of legacy cable equipment.

As of recently costs for GPON equipment have become very low, but the cost of the equipment is pretty insubstantial compared to the cost of trenching or pole attachment.

## Satellite

In more rural areas many people use satellite providers. In this case the consumer has a Very Small Aperture Terminal or VSAT. In modern satellite networks the VSAT is bidirectional and so both uplink and downlink move via satellite (compared to older systems in which uplink was by telephone and downlink by satellite). Satellite service typically offers up to 40mbps or so of bandwidth, but because current satellite internet technologies use geostationary satellites (which are very far away) latency is considerable, e.g. 250ms base and often quite a bit more. Of course there is promising progress in this area involving, distastefully, Elon Musk, but it is unlikely that satellite service will ever be competitive with DOCSIS or GPON in areas where they are available.


And that's the world of the internet, today! Next, let's dive into history again and talk about the cellular telephone and how it got to be the way it is. This is a very complex area where I have pretty limited knowledge of all developments since the '90s, so we will be together trying to tell our 3GPP apart from our GPRS.

>>> 2020-10-02 so net

Only my being very busy has spared you from an excessively lengthy discussion of historic long-distance telephone carriers. Let me give you an extremely brief summary:

Long-distance telephone calls were initially carried on "open-wire" carriers which were not radically dissimilar to the analog twisted pair used in the local loop (e.g. to your house). These carriers had limited capacity (one call per open wire pair) and call quality tended to deteriorate noticeable with distance. The next generation in long-distance carrier technology was analog multiplexing, in which frequency division muxing (and occasionally other methods) were used to place multiple analog telephone calls on the same wire. These were primarily transmitted via coaxial cables or microwave radio. Next up, digital carriers took over, in which audio was digitized and time division muxing was used to multiplex calls onto a single carrier, which was once again coaxial cable or microwave. Soon, though, digital carriers moved over to optical fiber, which is the primary media today.

There's a variety of different ways to pack bits across an optical fiber, including Ethernet. Some of them are described with words like "Plesiochronous." Perhaps the most beloved of the telephone industry, though, is synchronous optical networking or SONET. SONET is directly motivated by the need to carry ISDN-type data channels (e.g. "DS" channels which are carried over the "T carriers" we talked about earlier), and so there are many design similarities.

The most complicated part of SONET has to do with synchronization---in order to do time division muxing well, everyone needs to agree on exactly when each time slot starts, and in a distributed system this can become quite complex. Perhaps fortunately for you, though, I honestly don't find the synchronization component to be that interesting, and so I pay a lot more attention to the logical payload of DS0, which is fixed-sized frames which are allocated to different data channels using traffic engineering methods (that is, in advance).

Ironically, considering that SONET is all about being Synchronous, outside of telephone calls SONET is most commonly used to carry ATM, or Asynchronous Transfer Mode. ATM is a rather simple protocol which was developed as part of the ISDN standards. Being a telephone protocol, ATM is logically connection-oriented. This means that a connection is established using a a circuit establishment protocol, and ATM frames are then routed based on knowledge of the connection that they belong to. Somewhat like TCP, this creates the illusion of a fixed end-to-end connection on top of a packet-switched (i.e. non-connection-oriented) network. But, because connections are explicitly established in advance (rather than being an 'emergent property' of the protocol), ATM is able to make significantly more assurances about quality and reliability of connections.

The desire for a high degree of consistency in performance leads to some interesting design decisions. Perhaps most prominently, ATM packets (called cells) are of fixed size. Messages smaller than a cell will be padded to make them the standard length. While this is inefficient in terms of bandwidth, it simplifies switching, queuing, and other operations, and most importantly leads to very consistent and predictable performance since all cells should take identical processing time and resources. The fixed-sized cells are also particularly amenable to transport in other protocols that use fixed-size data units, such as SONET.

ATM is also quite nonspecific as to the contents of cells. Much like MPLS, this gives ATM a degree of "protocol Independence" that makes it a popular "lowest common denominator" used in networks that transport heterogeneous protocols. When I say "heterogeneous protocols," I don't mean HTTP and HTTPS. I mean packet-switched, variable-bandwidth protocols like IP and circuit-switched, fixed-bandwidth protocols like BRI telephone calls---and all with traffic engineering facilities that prevent the opportunistic protocols impairing the fixed-bandwidth ones.

Much like ISDN promised, SONET with ATM ought to be a good choice to carry telephone, internet, and perhaps other digital services (virtual private ethernet, anyone?) over a single connection. It became very popular for this purpose, and was widely used by larger businesses for their internet and telephone connectivity.

What I find most interesting about SONET though is the physical architecture. SONET was typically deployed using "add-drop multiplexers," which sit "midway" down a SONET link and operate by removing the frames from some time slots (and making them "incoming traffic") and replacing them with new frames (the "outgoing traffic"). This switcheroo provides symmetric inbound and outbound bandwidth, but oddly in different directions. Incoming traffic comes from the left, and leaves to the right, for example. For this reason, SONET is deployed in "loops" that typically run from the telco through multiple clients and back to the telco.

Further, although exact arrangements vary, loops generally had a "clockwise" fiber and a "counterclockwise" fiber, and often redundant fibers in each direction as well. Depending on the type of deployment, the two directions might be used for increased bandwidth (with redundant pairs for backup) or simply for backup, with the ability to send traffic "the other way around" if the connection is interrupted at some point in the loop. These loops typically had multiple clients on them, and it seems to have been a common practice to equip the add/drop multiplexers at each client site with a network diagram showing which clients were next in each direction---perhaps to aid troubleshooting when the connection drops. You can always call your neighbor and ask if their network closet is on fire. I once interned at a facility where one side of the SONET cable went to an intelligence agency, and we used to chuckle about the nature of their traffic running through our SONET equipment. The other side went to an astronomical observatory, and that might be enough to figure out who that employer was if you're clever.

I enjoy this particular aspect of SONET because it seems to introduce this odd concept of neighborliness into network architectures, and it's a pleasing variation from the star topology that is the norm in last-mile internet connectivity. Of course, ultimately, SONET was not able to deliver the best-case data rates that strictly packet-switched systems could (e.g. Ethernet), even if it delivered a much better worst-case. SONET is dying out in favor of "native IP" solutions like wide area ethernet (think very long ethernet cables). As we speak, networks are getting more boring.

Next, and hopefully in a shorter interval than has been typical lately, I will talk a bit about the internet delivery technologies available to consumers today, like DSL and DOCSIS. I will also share some opinions about wireless internet service, because you know I have some of those. I gave a talk at a conference of sorts about this topic so I can easily recycle material, and I always love doing that.

I also have a probably more interesting but closely related topic I wanted to talk a bit about: cellular phones, and the evolution of cellular networks. I'm working on a personal project right now that touches this area heavily and jeez is it making me wish for the old days of analog carphones.

Incidentally, while it has been occupying quite a bit of time, my landings are becoming less jarring by the day and I hope to fly an airplane solo soon, perhaps next week. Maybe I'll be able to post more often once I'm spending less time googling "how to hit ground gently."

>>> 2020-09-14 a brief history of internet connections

There is an ongoing discussion today about the accessibility and quality of consumer internet connections, and how this contributes to economic success---the "digital divide" or the "broadband gap." In terms of quality of service for price, the United States lags behind a number of other countries, which is surprising from the perspective that much of the technology behind internet delivery (and of course the internet itself) was invented in the United States. It's not particularly surprising from the perspective of basically any aspect of the US telecommunications or cable television industry, but that's a topic for a different (more leftist) medium.

I've been thinking a lot about consumer internet service lately. At my home, in one of the US's top 50 cities, I have a nominally gigabit (in practice 500-800 Mbps) service which I pay around $120 for. This is really pretty good for the US. However, I had a pretty rocky journey getting there, including a period where I used a sketchy one-person MVNO to subscribe to AT&T LTE and used antennas on the roof and a used Cradlepoint. I eventually gave up on this and begrudgingly went back to Comcast because said one-person MVNO appeared to manage all of their billing by hand and repeatedly forgot to extend my expiration date when I paid invoices, leading to random disconnects until they saw an email from me and turned it back on. Well, that's all besides the point as well, other than to say that an MVNO run out of a FedEx Office store beats the incumbent telco around here on speed and probably also customer service despite the monthly prods... and how did we get here?

I'm not going to talk about the regulatory story, or at least not yet. I want to talk a bit about the technology that got us to this point.

In the early days, telephones were all there was. Well, telegraph lines as well, sure, but later telegraph systems were essentially an application run over telephone lines as well. It is fairly common knowledge that ARPANET, for example, ran over telephone (if nothing else because there wasn't really anything else to run it over). This leads a lot of people to the mistaken impression that the earliest computer networks used acoustic modems that signaled each other with sound over a telephone line, like we may have used for home internet access in the '90s, but that's not actually the case. Early computer networks made use of leased lines.

The telephone network is, at least in most cases, a circuit switched network. This means that when you pick up your telephone and dial a number, the network creates a continuous circuit between your telephone and the telephone you called, and leaves that circuit in place until it is instructed to tear it down (by the phones being hung back up). Circuit switching was unsuitable for certain applications, though. For example, consider the case of a "squawk box" communications circuit used between a television studio and the network's national control room. Since television programming was already often being distributed to various cable and broadcast outlets using the telephone network (AT&T offered carriage of TV signals to broadcast and cable head-end sites as a standard service), it was obvious to use the telephone service, but these squawk box systems are not a dial telephone, they're more like an intercom. For this and other specialized applications, AT&T offered a "leased line", which was a permanently set up direct connection between two locations. There was no need to dial and the "call" never hung up.

From a very early stage leased lines were often used for digital applications, especially for telegraphy which was a fairly well established technology (using e.g. Baudot) by the time the telegraph networks started looking to pay AT&T for connectivity instead of, or in addition to, owning their own outside plant. Because of the sensitivity of these telegraph systems, such leased lines were often marked for special treatment in various telephone facilities, including the use of as few splices as possible and additional conditioning equipment (e.g. loading coils), all in order to maintain a higher quality connection than normal voice service. As you can imagine, the service was fairly expensive, but it was the obvious way to implement early computer network connections which were viewed as essentially an enhancement on telegrams[1].

Because leased lines required no dialing and offered a greater quality of service than voice lines, the construction of early telephone modems was actually much simplified. The available bandwidth was somewhat greater than voice lines, there was no connection setup to be worried about, and because leased lines were set up once and then well maintained, there was no need to auto-discover or probe what type of signaling the line would support, as v.54 and other later telephone modem standards involved. The ARPANET Interface Message Processors, or IMPs, were basically machines which sent and received telegrams much the same way as WU, but with a computer attached instead of a tape printer (of course this is not entirely true, the IMPs were fairly thick devices and implemented much of the protocol aspect of communications as well).

Leased lines remained the standard in computer data transmission for decades. During the 1970s, AT&T began the conversion of much of the telephone system from analog to digital, with voice calls encoded and decoded at the respective exchange offices. Full conversion of the telephone network to digital would take many years (there were still manual exchanges in use by the Bell System nearly all the way through the '70s, electromechanical switches were in use in North America until at least 2002), the introduction of a digital telephone backbone allowed for the direct provision of digital services. Early standards for digital telephony were not especially well standardized outside of the internal workings of AT&T which often provided the equipment[2], but during the early period of digital telephony long-range networking started to be an important concept in computing. DECnet and IBM SNA were two standards used primarily to allow terminals to connect to mainframes over leased lines, and were extremely common. The high cost of mainframe computers meant that businesses and organizations jumped on the opportunity to own just one but still have terminals located throughout their different offices.

The concept of computer data over the telephone system really took off, though, with the late-'80s introduction of ISDN. It is hard for me to fully describe how fascinated I am by ISDN. In 21st century hindsight, ISDN was a remarkable achievement in being both amazingly forward-looking and hopelessly obsolete from the start. So what even is ISDN? This question is kind of difficult to answer, which reflects both of those achievements!

ISDN stands for Integrated Services Digital Network, and the basic idea of ISDN was to unify the entire telephone system into a digital network which was capable of carrying either voice or data, including multiple channels of each multiplexed over lines of various capacities (ranging from twisted-pair copper lines to individual homes to high-speed fiber-optic trunk lines). ISDN supported all kinds of elaborate use-cases including enterprise telepresence (video conferencing essentially) comparable to the capabilities offered by enterprise telepresence systems today. ISDN supported logical circuit-switching and packet-switching multiplexed together, with circuit-switched connections receiving guaranteed capacity allocations. ISDN was designed to allow you to simply plug your computer into your telephone and have a digital connection, no modem required.

ISDN was hopelessly complex, expensive to implement, and only marginally competitive from a bandwidth perspective at the time of its release.

Let's take a step, for a moment, into a magical world where ISDN was deployed as expected. This magical world actually existed and continues to exist in some places, mostly in Europe where ISDN was generally more successful in the consumer environment. Oddly, though, I spent several years working at a government research laboratory (sure you can figure out which one but I won't just *give* it to you) with just such an environment, although it was very slowly being replaced, so for some time my desk phone was an AT&T-branded ISDN phone.

In consumer applications (or where I once worked, in each office), a BRI or Basic Rate Interface connection is provided by the telephone provider. A BRI delivers 128 kbps of useful capacity (plus some overhead) over a normal twisted-pair telephone line. The BRI arrives in the form of the "U" interface, which connects to the Network Termination 1 (NT1) which in practice today is a small box that you leave on the floor under your desk and kick repeatedly. The NTU converts the U signaling to S/T signaling, which is then connected by cable to the telephone instrument, which has a terminal adapter built in. Your computer is connected by serial to the terminal adapter.

Because ISDN aspires to unify telephone and data into one concept, ISDN data connections can be established by users much the same as a phone call. Either serial commands or the telephone interface can be used to make a "data call" to another telephone number. If the other number answers, you get a direct serial connection between the two machines at the data channel rate of 64kpbs. Of course, data connections can also be configured into equipment to be connected continuously, as desired.

I often refer to ISDN and other telecom-originated protocols as "very telephone," and when I say that I am referring to the fact that there is a rather different philosophy of design in the telephone industry than in the internet industry. Because the telephone industry needs to handle a great deal of fixed-bandwidth (i.e. 64 kbps) telephone calls, usage is relatively predictable. Because the telephone network historically operated on analog trunks with a fixed number of lines, the telephone industry has always been a proponent of "traffic engineering," the practice of making very intentional decisions about allocation of bandwidth and routing of traffic.

So fundamentally, telephone technology is usually focused on moving exactly reserved bandwidth allocations through an intentional route, while internet technology is more focused on best-effort delivery of packets using whatever route available. The problem, of course, is that the best-effort internet has vastly less overhead (due to unused reserved capacity) and so is generally able to offer more bandwidth at less cost (and admittedly lower reliability) than telephone technologies. This is perhaps the simplest explanation of why telephone-derived technologies such as ISDN and SONET are no longer considered cost-effective channels for internet service: you tend to end up paying for all the bandwidth you *aren't* using.

To expand a bit, the structure of that ISDN T1 connection reflects these design decisions. A T1 connection runs at an exact line rate of 1.544 Mbps. That rate is divided into exactly 24 channels of exactly 64 kbps. The math doesn't add up because there is reserved space for protocol overhead, as the 64 kbps channel rate is actual payload. On the actual T1 connection, the channels essentially take turns, with each channel in order getting a turn to send a frame. This means that each channel behaves very reliable, but of course unused channels are still occupying bandwidth. The actual signaling technology is referred to as "T-carrier," according to the Bell System convention of identifying each of their transit protocols/media (called carriers) with a letter.

What a wondrous world! Data can be moved over the telephone network in a virtually native format, with a very reliable reserved bandwidth allocation. And all of this uses semantics that telephone users are familiar with. It's delightful to imagine an alternate timeline in which this technology was a huge success and the imagined convergence of telephone and data had happened, truly realizing the power that came from the innovation of viewing telephone calls as merely a particular case of the general principle of reserved-bandwidth bit streams. 

This is not to say that ISDN was entirely unsuccessful. For businesses, ISDN became a fairly common data connection, through the form of the ISDN Primary Rate Interface or PRI. The PRI basically describes a higher-bandwidth ISDN connection which is intended for use as a trunk instead of for connection to a single client site. The typical PRI in the US is a T1 connection, which moves data at 1.544 Mbps, or carries 30 telephone calls or so (the details can vary slightly). Of course today 1.5 Mbps is quite a disappointment, but in the early '90s it was a pretty fast connection. That said, T1 connections in practice were mostly used as telephone trunks for PBX systems, and only some times to carry data. It took some time into the '90s for it to become clear that an internet connection is something that businesses needed.

In addition to being somewhat over-complicated for consumers and always rather expensive, ISDN service was basically obsolete by the time it gained significant currency. ADSL had largely overtaken ISDN for internet service by the mid-'90s, offering higher (although less reliable) speeds at a lower price. Businesses continued to prefer T1 for a while longer than expected because of its real, but more importantly perceived, advantages in reliability and stability. I'm sure there are still businesses using an ISDN PRI for their internet service today but it is now a decidedly legacy situation. In more critical applications it has been replaced by fiber, in less critical situations typically by DOCSIS.

In fact, let's talk about that fiber technology. There are multiple fiber optic technologies in use in the telecom industry, and basically all of them have some capability to carry data, but the one with which I am most familiar (and also a very common arrangement for business service) is the SONET loop. I've been going on for a long time already, so we'll talk about that next.

[1] One could argue, probably correctly, that the "packet" as a concept is directly derived from a telegram, being a discrete unit of information that contains header information such as to and from, control information used in the telegraph network, and a payload. There is a distinct resemblance between a Western Union telegram card and a modern network packet. Western Union even supported what we might call "source routing" with some telegrams giving forwarding instructions, and "quality of service" with some telegrams marked for special priority.

[2] The 1968 Carterfone decision allowed the use of third-party equipment directly on telephone lines, so there was no regulatory requirement that telephone data interfaces be provided by the telco. However, the Bell System is where the majority of technological development in digital telephony was being done, and considering how unhappy they were with Carterfone in the first place they were not quite ready to start licensing or opening standards to third-party manufacturers. That said, there was still a wide variety of interesting third-party equipment that existed, it's just that the entire computer data industry was pretty small at this point.

>>> 2020-09-02 not so instant messaging

There are various phenomena that make instant messaging a strange beast today, one that has surprisingly little resemblance to its former self. Broadly speaking, the main motivators of change seem to be that conventional instant messaging platforms (e.g. AIM) proved difficult to monetize, and the post-2000s radical success of social media (as a monetizable platform) essentially requires that any successful communication product have a significant social media aspect.

Let's take a look at a few specific examples of the instant messaging landscape today.

Google is, as usual, one of the easiest to poke fun at. Google Talk was an XMPP-based instant messenger that popped up in the sidebar of GMail in 2006. As a fairly standards-compliant XMPP implementation, Google Talk could be used with any of a number of third-party clients, but Google also released a desktop client of their own. Google Talk behaved basically how you would expect, very much like precursor products like AIM. Further evidence of the coming mass adoption of XMPP emerged when Facebook announced their own integrated sidebar instant messaging which was, once again, XMPP based, permitting the use of third party clients in addition to their own.

Just a few years later both vendors had abandoned their desktop clients and were backing off on XMPP support, with both relegating XMPP to "legacy" status and then completely dropping XMPP support.

What can we learn from this tale of woe? Perhaps nothing, but I think that it relates closely to two fundamental challenges that all federated/distributes systems face:

1) Federated systems are generally more difficult to monetize. The lack of central control makes advertising display less practical, and commercial services (that is, subscription based ones) generally have little motivation to implement federation and some motivation not to, as the federation interface provides an opportunity for a free implementation to wipe out the market.

2) Federated systems are more difficult to develop, maintain, and especially enhance. The protocols underlying federated systems generally ossify more or less instantly. Without very careful design, it's easy to get into a situation where a feature cannot be changed or implemented without breaking federation, and it's impractical to update the entire network at the same time. Even with careful design permitting back-compatibility, any added features are de-facto federation breaking because of the poor user experience created when some clients do not support those features.

As I discuss at more length in the essay "Obituary, for Ray Tomlinson and Email,"[1] these factors (and some other more minor ones) tend to inherently limit the success of any federated system. Both of them were presumably major players in the decisions of Google and Facebook to drop XMPP, as both have since implemented features and monetization strategies which are impractical with an open protocol and the resulting lack of close control over client implementations.

Also, time has shown that Google is fundamentally incapable of operating a working messaging system, but that's an entirely different topic.

A further challenge faced by these and most "legacy" instant messaging services (with the exception, oddly, of IRC), is lack of sufficient support for groups. Groups turned out to be a major application of instant messaging, particularly in certain niches such as business and gaming, but also as an adjunct to the mid-2000s forum scene. While AIM, XMPP, and other legacy IM solutions did offer support for groups, it was relatively limited. A major pain point was often a lack of access control, moderation, and organization tools, which made it difficult to manage any group that exceeded a certain (fairly small) size.

Users also increasingly desired "rich" content, which could initially be as simple as inline image display but later came to incorporate link previews as a major (now essentially required) feature of IM.

Perhaps nothing has changed the IM landscape more, though, than the idea of instant messaging as platform. WhatsApp is the main example of this, although I'm not sure whether or not it's the first. Facebook Messenger was also an early example of the phenomena, by rolling out features like money transfer before it was clear that that was a reasonable thing for an IM product to do. The basic idea of IM as platform is the same idea as everything being a social media product: IM products have people, and you can make money by delivering advertising and paid services to people. So, as the operator of an IM product, you want to shoehorn as much functionality into your IM product as possible in order gain more opportunities for monetization.

I describe this in purely capitalistic terms, but consumers seem to like it as well. Consider "ChatOps," a concept which was greatly bandied about but I have never actually seen successfully employed (but of course I have not worked for GitHub where the concept originates). ChatOps is essentially the dweebiest possible version of IM as platform. Picture Jenkins shoved into your IM solution. Apparently this is the future. While you and I might think that the compulsion to operate one's DevOps toolchain from Slack indicates a severe defect in the UI and interaction design of that DevOps toolchain, the IM industry happily supported it because they were in a position to make money off of it.

These observations lead more or less directly to the messaging landscape of today, in which IM products generally fall into one of four types:

1) Legacy - IM products that are "simple IM" because they've been that way since 2005, or because technical limitations make it difficult to exceed the core IM features. Think Google Hangouts and Signal, respectively.

2) Integrated - IM products that are a secondary feature to a different social networking product. Facebook has two of these for example, Facebook Messenger and the Instagram IM feature. These almost always have ambitions to enter the third category.

3) Platform - IM products that have been expanded into a platform for apps and third-party interactions. WhatsApp is perhaps the crowning example of the genre, but Messenger is trying to get there.

4) Community-based - IM products which are group-oriented and based around a metaphor of individual communities. Think Discord and Slack (Discord for Business TM).

Of these, platform and community-based solutions are generally viewed as the cutting edge. Platform products are extremely popular among the general world of internet users, while community-based solutions are extremely popular in certain specific industries, such as gaming for Discord and workplace communications for Slack.

I view community-based IM solutions as being fundamentally user-hostile, but this is largely a matter of opinion. I just think it's ridiculous that I have *nine* Slack accounts in my password manager and the level of friction involved in joining (or even logging into) a new workspace is not really reduced at all. Plus the mobile app makes it a real headache to be logged into more than one workplace at a time. But that's complaining about a specific product, and I try to keep my complaining more general, believe it or not.

What is the problem, in my eyes, with this IM landscape? Well, the first and second types are hardly worth discussing, as every example of the first type is on its way out (ironically, Hangouts, the one that is officially on the way out, also seems to be the one that's immortal), and the second type are rarely worth using in their own right. The third and fourth, the instant messengers of our generation, tend to suffer from one or more of the following problems:

1) Excessively heavy - Facebook Messenger, which is relatively feature-limited on the surface, is such a mess that Facebook maintains a "lite" version of the Android app for people with older phones and/or a desire for their battery to last more than two hours.

2) Self-limiting usage scope - applications like Slack which are basically limited to certain applications by their UI design (because of a high degree of friction in switching communities). Discord tends to avoid this problem but also has a downright baffling user culture related to Discord "servers," so I'm not sure that that's more than a fluke.

3) Limited client options - available only using an official app on specific platforms, no desktop client, desktop client is barely functional compared to mobile app, etc.

So where do we go from here?

Well, one problem that we might hope to address is the fact that I have, at this moment, 11 independent messaging apps on my phone. I'm not confident that there is any solution to this under capitalism though, as addressing it would basically require developing an open standard which could be used for communication across products, and just about everyone has an explicit motive not to allow this. Another problem is the high degree of complexity in most IM products. Once again, there is a fairly direct profit motive in increasing the complexity of an IM product, so there may not be any way to solve this one.

It seems a little ridiculous to just say "there is no ethical messaging under capitalism" and leave it at that, but that's pretty much the situation we find ourselves in right now. The solution to a lot of these problems seems to be a well-designed, well-implemented federated protocol, and there are products to build that right now (e.g. Matrix), but they seem to fall to all of the basic problems that federated protocols have, such as fragmentation, design issues, feature stagnancy, etc.

I'm a little tired of just complaining about instant messaging but there is an interesting direction to go here. In a future post, I will talk a bit more about federated systems, expanding on specifically the privacy and security challenges posed by federated systems. This is a much more interesting topic as it is actively moving right now, relates to some academically difficult topics in security and privacy, and leads directly to a huge quantity of internet drama.

[1] https://jbcrawford.us/writing/obituary