>>> 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

>>> 2020-08-13 telephone numbers

A tangent:

One aspect of many messaging systems is addressing. You need to have some way to indicate who you want the message to go to, some sort of unique identifier. In the case of email, it is a username and a hostname, user@host. In the case of many instant messaging systems, it is an alphanumeric username. Some kind of formalized addressing system is not a new idea, and both mail and telegraphy used more or less formalized addressing schemes. In the case of telegrams these were often very compact alphanumeric codes to save time in transmitting. One common formal addressing scheme we deal with today, though, is particularly restrictive: telephone numbers.

I will avoid straying too much into the details of telephone switching technology, but telephone numbers alone are interesting to think about. To start, why are telephone numbers, well, numeric? It's hard to know for sure why numbers were selected to formalize switchboard operations, but it must have simply been the obvious way. Labeling switchboards by name would have taken up a lot of space and likely not been practical, labeling them by number was natural and allowed operators to find lines very quickly, since locating a number in a list is something we're well practiced in.

Phone numbers became more constrained, though, with the introduction of automatic switching. To avoid a long discussion of the operation of early mechanical telephone switches, I will lay out a few rules about phone numbers which come from the design of these switches:

a) Phone numbers must be parsed from left to right (from first digit to last). It is not generally possible to "backtrack" to previous digits in the decision making process. For example, all telephone numbers starting with 9 must be processed in the same way.

b) Phone numbers must have a more or less fixed length, or must comply to a relatively limited number of lengths.

c) It must be possible to differentiate phone numbers requiring different processing based on digits in fixed positions from the start, generally the first digits. This is basically a summation of the first two.

Neither of these rules are quite absolute and real exceptions exist to both, but by far the most exceptions exist for rule B. Let's take a look at the structure of a phone number and see how these apply, though. In the United States we live under a system called the North American Numbering Plan or NANP, which was extended from the Bell system to standardize telephone numbering the US, Canada, various Central American nations, and formerly, Mexico[1]---basically the list of countries which had been served by the Bell system[2]. NANP telephone numbers are often described using the notation +1 (NPA) NXX-XXXX. This syntax is common but a bit confusing. +1 is the country code which is conventionally prefixed with a + when written to avoid confusion, 1 is the country code for all NANP countries. NPA, or Numbering Plan Area, is the more formal term for what we typically call an area code. NXX, now, is quite different. It is a sort of mask, the N indicates the digits 2-9, and the X digits 0-9. This is the three digit prefix on all phone numbers that people will occasionally refer to as an exchange number or exchange code, as it had formerly indicated an individual telephone exchange. Note that the first digit must be 2-9, it cannot be 0 or 1. Why is this?

Because the digits 0 and 1 indicate a special dialing code or an out-of-area call, respectively. This reflects the first rule that digits must be processed from left to right, each digit indicating future processing steps. Typically you can dial seven digits on your phone, which will be interpreted as NXX-XXXX within the same NPA as your own telephone. If you instead dial ten digits, (NPA) NXX-XXXX, the telephone switch must interpret the first three digits that you dial differently. It cannot backtrack to do this. For this reason, classically, 10-digit telephone numbers had to be prefixed with the digit 1, which signaled to the telephone switch that it should interpret the following three digits as an NPA, then NXX-XXXX.

0 is used for various purposes, but perhaps the most common today is international calling. Telephone switches must handle international calls completely differently from domestic. To indicate to a telephone switch that such special processing is necessary, you first dial 011. The reason for this exact code comes down to history, but 0 had historically been used to call the operator and so 0 still generally prefixes calls which require special handling.

Another case of 0 and 1 having special meanings at the beginning of telephone calls is the "dial-around" prefix 1010, which allowed long-distance calls (normally prefixed with 1) to be placed using an alternate provider. The exact history of dial-around calling is somewhat complicated and it has been obsoleted by telephone plans with unlimited long distance, but it is another case of 1 having a special meaning.

Of course, you can infer from this that 010 cannot be an NPA. Otherwise, dialing 1010 would be ambiguous between the dial-around prefix and placing a normal long distance call to NPA 010. Quite a few constraints appear in telephone numbers because of this requirement to avoid any ambiguity in parsing subsequent digits. Consider, as another example, the NANP proposal for extending the length of NANP telephone numbers should it become required. If we were to run out of telephone numbers, we could extend 10 digit dialing to 12 digits, by suffixing a 0 to the NPA and prefixing a 0 to the NXX. Thus the telephone number, say, (234) 567-8901 would become (2340) 0567-8901. This would be done because the NXX part already cannot begin with zero, so a zero in that position unambiguously indicates to the switch that the number being dialed is a "new-style" number. In the future other digits could be used in that position, but only once use of 10-digit numbers is completely eliminated. Incidentally, this change is not expected to occur for quite some time as the rate of new phone number issuance is actually pretty low.

Another very simple example of the need to determine processing based on the first digit available is the common use of a "dial-out" prefix on PBXs, where you have to dial for example "9" to reach an outside line. Internal extensions are typically 3 or 4 (or less often 5) digits, so clearly the PBX could determine whether a telephone number is inside our outside based on the length. However, early telephone switches were simply not capable of this kind of retrospection on the dialed number, they needed to determine the processing path immediately. Therefore, much like the prefix 1 for out-of-area dialing, the prefix 9 was used for outside dialing (and no extensions could begin with 9).

This is all largely just an interesting aside, but there is something which motivated me to write about it: UK phone numbers. The UK telephone system, as operated by the General Post Office, used the same mechanical switching technology as the Bell system and was so subject to the same constraints. However, the GPO did not allocate a system of telephone numbers in advance which was sufficient to meet the needs of the kingdom. As a result, additional digits were added to various processing paths over time. This leads to a vexing result: UK telephone numbers are of varying lengths. However, it is possible to predict the length of the telephone number based on the first several digits. 020 is a regional prefix indicating London. 01865 is the regional prefix indicating Oxford. These are not the same length! However, there is no regional prefix 018, and so after parsing (or in the term of the art, consuming) the digits 018 the switch knows that the next digit will also be part of the regional prefix. Incidentally, the leading 0 in these is really a special digit that is somewhat similar to the leading 1 used in the US for out-of-area dialing---it signals the switch to process the call as being to another region, but in the UK it is treated as a digit of the area code rather than as a dialing prefix.

If this sounds more complicated, it is, and the UK telephone numbering scheme often feels like a mess, but it is really only by luck that the NANP scheme ended up being highly consistent over an extended period of time---and of course it has its own problems as well, such as not clearly mapping to countries.

Today, most of these constraints are only historic. Cellular phones, which connect to a generally much newer switching infrastructure, usually allow all kinds of formerly invalid dialing, such as out-of-area dialing without a 1 prefix. There have also been a few curious constraints coming out of specific situations. For example, when overlaying area codes (adding a second area code to an existing area to increase capacity), some carriers decide to disable 7-digit dialing and force everyone to dial area code, hopefully reducing area code confusion. All of this comes down to the fact that call processing is today implemented in software, where a flexible scheme often called a "dial plan" is used to configure equipment to understand a variety of dialing methods. That said, landline phones are often connected to much older switches (dating back to e.g. the '70s), and so tend to be much stricter about correct dialing format. I once worked in an environment with a legacy 5ESS switch (I suspect originally installed and maintained under service contract with AT&T, but via a telecoms contractor at that point), which outright refused dialing in any format but ten-digit-one-prefixed for external calls and five digits for internal calls. Employees periodically mentioned the phones being "touchy," but no one ever seemed to think that much about why---they were probably habitually dialing only seven digits on first try, which is normally acceptable in this area.

But does anyone even, like, use phone numbers these days anyway? I'm pretty lost to remember any of them.

[1] Mexico had been a NANP country but decided to switch to using its own country code, in part to step "out of the shadow" of the United States. This change occurred relatively recently and so Mexican phone numbers are usually, but not always, compliant with NANP, in that they do not overlap with other NANP area codes.

[2] Such cross-national telephone numbering schemes are not very common. It had been a very common issue with NANP that people would rack up excessive phone bills calling Panama, not realizing that it was an international call, since a Panama is just a set of area codes in NANP. This problem was largely eliminated by making changes to switches that required users to dial their international calling prefix when calling foreign countries, even if they are NANP countries. This represents an exception to the general NANP hierarchy concept in which a number can be dialed from within a region using only the digits within the scope of that region.