Values in Design of Future Internet Architecture

A central theme in much of my research and advocacy is ensuring attention to ethical values becomes an integral part of the conception, design, and development of information systems. Various frameworks have been developed to help pursue this goal (ie, value-sensitive design, values at play, critical technical practice), which can collectively be termed Values-In-Design (VID). Broadly, VID seeks to broaden the criteria for judging the quality of technological systems to include the advancement of moral and human values, and to proactively influence the design of technologies to account for such values during the conception and design process. VID has been a motivating factor in my research on vehicle safety communication technologies, Web search engine privacy practices, and book digitization projects, just to name a few examples, and my commitment to achieving VID has also lead to explorations of some of its challenges (here and here).

For the next few days I will be participating in a project aiming to apply the VID perspective to future Internet architecture (FIA) design eforts: the Values-In-Design Council.

The National Science Foundation has recently funded multiple projects to envision and  pursue new ways to build a “more trustworthy and robust Internet.” As described by the NSF:

The four basic research and system design projects funded under FIA explore different dimensions of the network architecture design space and emphasize different visions of future networks. NSF anticipates that the teams will explore new directions and a diverse range of research thrusts within their research agenda but also work together to enhance and possibly integrate architectural thinking, concepts and components, paving the way to a comprehensive trustworthy network architecture of the future.

The four FIA projects are described in more detail here.

Along with these technical projects, the NSF has also funded the creation of the Values-in-Design Council, a multi-disciplinary team of experts in the social analysis of digital information technologies, led by Helen Nissenbaum, who are tasked to work alongside the recipients of the FIA technical grants. As described by Nissenbaum:

Council members will serve as analysts and consultants to the FIA projects, helping to identify junctures in the design process in which values-critical technical decisions arise; locating design parameters and variations that differentially call into play relevant values; for and with respective projects, developing rich conceptual understandings of relevant values; for and with project investigators, operationalizing values to enable transition from values conceptions into design features; with FIA investigators, examining the interplay of values embodied in design with respective values embodied in law and policy; and where possible, verifying values in design through prototyping, user testing and other empirical analyses.

The full list of VID Council members is here.

At this week’s meeting, hosted by Colorado State University’s Computer Science Department, each of the four project teams will provide an update of their work, and then discussion will focus on this set of questions:

Who are the service providers in your architecture, and what is the resulting provider ecosystem? (Some of the FIA architecture seem to presume a provider ecosystem similar to today: a connected set of packet forwarders. Some presume other services related to carriage, such as storage providers. )

• What is the incentive of each of these actors to enter into their line of business? Where would your architecture require payments among actors to sustain viability?

Options for control: which actors can influence the behavior of a transfer?

• Does your architecture provide user control over aspects of service selection: routes, service qualities, or providers of support service (e.g. like DNS in today’s Internet)?
• To what extent does your architecture support or resist the goals of those who wish to control access to classes of information (e.g. governments, rights-holders). How does this position influence the balance of power in your network, and its viability? Which actors have the ability (or perhaps the easy ability) to block communication among willing end-points?
• IP addresses accidentally turned out to be scarce resources, for no good reason. What features of your architecture might turn out to be “scarce resources” or resources over which some potentially powerful actor could exercise control?
• Do you have hierarchies with single points of control at the root? Is there information you share with partners that has to be signed by a trusted third party?
• Are there policies that you have explicitly embedded in your design?

What is the range of services that the system provides to the higher layers?

• Compared to today’s Internet, would you expect the same sort of commercial entities at the higher layers?
• For example, (especially in the context of those architectures that emphasize information retrieval), would you imagine that there would be CDNs operating on top of your architecture?
• Does your architecture provide an API that defines the service interface of your system?

Interfaces among providers

• What types of information is expected to be exchanged between providers?  This goes beyond packet forwarding to include:
  • Routing information
  • Naming information (e.g. DNS zone transfers)
  • An interconnection agreement between providers in today’s Internet may have Service Level Requirements, or specify aspects of routing policies (cold potato, hot potato).  What would you expect to find in inter-provider agreements in your architecture?
  • To what extent do services provided to higher levels (see above) require negotiation or cooperation among the various actors that make up the overall network?
  • What mechanisms does your architecture provide for negotiation among service providers?
  • What range of functions are supported by the protocols and mechanisms that hook them together?
  • Operators are sometimes worried about all getting together to solve operational issues. It is hard to do and looks like anti-trust. What are the “top five” aspects of your architecture that require operational coordination?

Market forces and regulation

• To what extent does your proposal facilitate or limit the use of competition as a discipline on the market?
• If regulation were proposed to require some sort of non-discriminatory access or “network neutrality”, what might that mean in your design? Where might forms of discriminatory service emerge?

Evolvability

• How does your architecture allow innovation and the migration to new mechanisms?
• Which sorts of evolution seem to require global coordination, like the migration to IPv6 today?

Trust, isolation and availability

• What sorts of trust assumptions does your design make about the various actors that make up the ecosystem?
• Does your architecture provide means for instrumentation or data-gathering? What sorts of data? Internal structure of the network, usage, routes, outages, etc?
• To what extent does your architecture include tools to detect that actors are not functioning properly? Which actors have access to these tools?
• How do your options for control allow different actors to respond to actors that are not trustworthy or mis-functioning?
• Availability often implies “extra” or “diverse” resources. Does your architecture depend on resources that are otherwise under-utilized to achieve high availability. Is economics a barrier to a high-availability network? Both within a region and across regions, does your design allow the operator to trade off explicitly between cost and availability/resilience?

Implicit in these questions are various ethical concerns, including: autonomy, access, freedom from bias, control, and trust. I’m excited about the conversations that will unfold over the next couple of days, and will provide public reflections here as appropriate.