The technical plenary at IETF meetings is organized by the Internet Architecture Board (IAB) and is considered an IAB working session. Sometimes a topic is presented because the IAB wants to get a message across to the community, sometimes we think a topic will be informative or entertaining for the IETF community, and sometimes the IAB itself wants to be informed about a topic or an issue, and we believe we would benefit from a discussion with the community. The topic of the technical plenary at IETF 75 falls into the last category.
What we tried to accomplish was a more in-depth understanding of how policy and technical requirements and realities interact and how IETF technology can be designed for, or impacted by, the tussle between the two. It was not the IAB’s intention to arrive at or promote a specific position in the network neutrality debate but, rather, to more clearly understand what impact the issue may have on Internet technology.
Barbara van Schewick and Mark Handley introduced the topic at the session. Barbara focused on the background of the debate, including the various definitions, perspectives, motives, and arguments that most commonly come up in the debate. She approached the topic mainly from a technoeconomic perspective. Mark tried to tease out the implications of those issues for the IETF, particularly with regard to designing protocols. Using the “Tussle in Cyberspace”?1 paper as a starting point, Mark talked about how the debate affects multiple IETF-related technologies, including congestion control and deep packet inspection. He argued that value-neutral design is not possible.
The slide material and the notes from the session can be found in the proceedings section of the IETF Web site.
While the IAB has not developed a position with regard to the debate, I would like to share, on a personal note, how being exposed to the perspectives brought by the speakers and the plenary discussion gave me food for thought. For example, a parallel was drawn with a discussion that took place in 2000 when the IETF was asked to take a position on the inclusion-in the IETF standards-track documents-of functionality designed to facilitate wiretapping. (As an aside, that parallel was drawn by the audience, and so in that sense, this plenary served its purpose as a working session.) I went back to RFC 2804-which documented the discussion-and I tried to assess whether the question of “the morality of an act “˜on the wire,’”? as raised in section 4 of that document, applies in the context of congestion control, since questions around congestion control often link with morality issues, including decent behaviour and fair use.
To me, the topic of the technical plenary at IETF 75 reinforced the idea that in many cases, IETF engineers have an opportunity to steer in a certain direction the technology they develop. I believe that when we, as engineers, design protocols, we have the responsibility to apply a systemic approach whereby we do not stifle the ability for innovation at the edges. The ability to bring new applications to the Internet without needing the core to adapt is what made the Internet what it is today.
When I talked about this with Marcelo Bagnulo, he went one step further, in essence saying that in the process of creating designs, some IETF engineers and working groups may steer the work (often not even consciously, because there is no IETF-wide guidance) in directions different than others do. During the plenary we were presented with an example of design work within the IETF, wherein a network neutrality-related choice had been made. In Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service (draft-ietf-v6ops-cpe-simple-security-07), the recommended behaviour for incoming Internet Protocol Security (IPsec) traffic is to forward by default, while the recommended default behaviour for non-IPsec traffic is to apply endpoint-independent filtering. This fosters the usage of IPsec protection, which in turn may have significant implications regarding the capabilities of the network to discriminate traffic through packet inspection methods.
That last example illustrates what the IAB tried to accomplish in this plenary-that is, raising consciousness about the various neutrality issues that can be impacted by the IETF as well as the day-to-day work of individual engineers within the IETF.
Reference
1. D. Clark, J. Wroclawski, K. Sollins, R. Braden. “Tussle in Cyberspace: Defining Tomorrow’s Internet”?; Proceedings of the ACM SigComm 2002 Conference, Pittsburgh, August 2002; Computer Communications Review, vol. 32, no. 4, October 2002.