Does America Need a National Broadband Research Agenda?

The National Telecommunications and Information Administration (NTIA), a part of the Commerce Department, has asked for comment on a recommendation to coordinate federal research funding on a broad range of topics related to broadband networks.

The combined program is known as the National Broadband Research Agenda (NBRA). The range of NBRA topics is suggested by the report of a “visioning workshop” held at Penn State in June, the Broadband 2021 Workshop.

NTIA boils down the somewhat rambling workshop report into four main topic areas:

  1. Broadband technology;
  2. Broadband deployment, adoption, and utilization by individual, business, and institutional users;
  3. Assessment of economic and social impacts; and
  4. Opportunities for federal leadership in data collection, research, and overall coordination.

The Example of Multihoming

The topics are extremely broad, but the workshop report is much more specific. In the “technology” area it discusses at some length the notion of “multihoming,” which it defines in a very vague and circuitous way. The best way to explain it is to quote verbatim since I can’t do the discussion justice in my own words. As a bonus, this quote provides some of the flavor of the workshop report.

THEME: Edge Empowerment

The term “edge” has multiple meanings, but in this context we refer to devices operated by end users that typically connect to network service providers, such as smartphones, vehicular routers and home routers.

Workshop participants discussed the possibility of usable edge empowerment, whereby edge devices are given greater control over various functions rather than networks.

After relationships have been established with multiple Internet access providers, edge devices could dynamically manage connections with each, perhaps seamlessly migrating from one cellular carrier to an independent Wi-Fi hotspot to a vehicular network and then to a competing cellular carrier.

These same edge devices could also decide to multihome, that is, to connect opportunistically to multiple broadband providers simultaneously. These approaches may benefit users in a number of ways. Dependability could be increased, because devices can remain connected as long as just one of the networks is available.

Data rates can be improved by using multiple services simultaneously. Seamless migration and multihoming could also have important economic implications, as it will cause providers of broadband services to compete in new ways.

A related question is whether users will connect all their devices to a broadband provider through a single router, and the Internet access provider will manage this as a single connection, or whether we will move towards per-device connections.

ISPs could adopt virtual residential gateways that tailor services on a per device basis, perhaps improving service through customization, although the visibility that ISPs would gain also raises important privacy issues. At the same time, user devices with edge empowerment could migrate individual flows from provider to provider to meet their needs.

RQ1: What technical approaches would be most effective for migration and multihoming?

RQ2: What are the costs, benefits and risks of empowering end user devices to migrate and multihome?

RQ3: How would migration and multihoming affect competition, investment, and innovation?

RQ4: What are the impacts of multihoming and usability for underserved communities?

RQ5: How do current pricing schema affect the development and use of edge and multihoming technologies? What pricing schemes might incentivize more efficient or effective network development?

The Nature of Multihoming

The first thing that jumps out of this discussion is the fact that the Internet (including its constituent protocols such as TCP, IP, DHCP, BGP, and DNS) does not support multihoming. A multihomed system requires an address for each network-attached system as well as additional addresses for each point of attachment to the network. The Internet assigns IP addresses to points of attachment such as Ethernet, Wi-Fi, and LTE interfaces, but it doesn’t assign the additional address that would allow network edges to divide traffic generated by a given transaction across multiple network paths.

If, for example, I want to load a web page on a PC that has both a Wi-Fi and an LTE interface, the web server would need to be aware of the fact that there are two paths it can take to my PC. It would also want to know the relative capacities of the two paths so it could balance the loads appropriately.

Armed with the information that Path A and Path B allow it reach Personal Computer One, and with the information that Path A is three times faster than Path B, the server would send 75% of the web page across Path A and the remainder across Path B.

This would only make sense, of course, if the network paths were the limiting factors in the load time of the web page. If each of the paths is capable of handling more data than the web server can transmit, this sort of multihoming would be pointless. It can also potentially impair network stability.

The History of Multihoming

We have some historical experience with multihomed and non-multihomed systems. ARPANET did not support multihoming because, like the Internet, it did not distinguish systems attached to the network from the network’s points of attachment to systems. ARPANET computers were connected to Interface Message Processors (IMP) that had one or more ARPANET connections as well as some number of local “ports” for connections to local systems. Addressing was network business, so it has handled in terms of IMP addresses and port addresses relative to the IMP.

The first research network to follow ARPANET was CYCLADES, designed by Louis Pouzin and colleagues at the Institut de Recherche en lnformatique et en Automatique (IRIA, later INRIA) in France. CYCLADES was specifically designed to support multihoming and mobility and to split traffic between pairs of nodes according to available paths. As Pouzin explained in a 1973 paper:

CYCLADES uses a packet-switching sub-network, which is a transparent message carrier, completely independent of host-host conventions. While in many ways similar to ARPANET, it presents some distinctive differences in address and message handling, intended to facilitate interconnection with other networks. In particular, addresses can have variable formats, and messages are not delivered in sequence, so that they can flow out of the network through several gates toward an outside target.

The Internet took a number of mechanisms from CYCLADES, such as the datagram, congestion control, and end-to-end organization. But it did not take multihoming; rather, it followed the ARPANET model of point-of-attachment addressing rather than system addressing. This was a mistake that has partially been rectified by Multipath TCP (MPTCP) and a few other experimental approaches.

Clarifying the Topic

So the research questions around multihoming must begin with an examination of the many details not noticed by the Penn State workshop, such as:

  1. What technical mechanisms will need to be added to the Internet to support multihoming?
  2. How are these mechanisms to be added without disrupting the Internet’s operation?
  3. What impact will multihoming have on privacy and security? Can negative impacts be mitigated?
  4. What existing mechanisms (cf. Mobile IPv4 and Mobile IPv6) provide multihoming and what are their shortcomings?
  5. How may users control multihoming options in their own interests?

This is an important topic for mobility (if not for performance in common cases) and therefore it should be addressed whether we have a National Broadband Research Agenda or not.

To Be Continued…

This post is getting long, so I’ll end this portion now and post the conclusion next time.