RFC 7305

Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT)

📅 published July 2014, from ietf

Report from the IAB Workshop on Internet Technology Adoption and Transition (ITAT) 🎀

okay bestie, this is RFC 7305 💖 It was written by the Internet Architecture Board (IAB), with E. Lear, Ed. as editor. It came out in July 2014, it's an Informational doc 🦋, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there ✨

Abstract ✨

so the abstract is basically the tea ☕ This doc gives an overview of a workshop the Internet Architecture Board (IAB) held on Internet Technology Adoption and Transition (ITAT). It was hosted by the University of Cambridge on December 4th and 5th of 2013 in Cambridge, UK. The goal was to help Internet protocols get adopted by looking at a bunch of economic models, with extra focus at the waist of the hourglass (e.g., the middle of the protocol stack) 🍓 This report summarizes the contributions and discussions. Since the topics were all over the place, there's no single set of recommendations for IETF participants to chase right now. Instead, in the classic sense of early research, the workshop just noted areas that deserve more exploring 🔍

heads up: this is a report on what happened at the workshop. The views and positions in here belong to the workshop participants and do not necessarily reflect IAB views and positions 🙈

Status of This Memo 📚

this one is not an Internet Standards Track spec, it's just published for informational purposes 💅

this doc is a product of the Internet Architecture Board (IAB) and holds info the IAB decided was valuable enough to keep on the permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741 🫶

for info on the current status of this doc, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc7305 🌸

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please review those documents carefully, because they spell out your rights and restrictions with respect to this document 👑

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Organization of This Report . . . . . . . . . . . . . . .   5
2.  Motivations and Review of Existing Work . . . . . . . . . . .   5
3.  Economics of Protocol Adoption  . . . . . . . . . . . . . . .   7
  3.1.  When can bundling help adoption of network
        technologies or services? . . . . . . . . . . . . . . . .   7
  3.2.  Internet Protocol Adoption: Learning from Bitcoin . . . .   7
  3.3.  Long term strategy for a successful deployment of
        DNSSEC - on all levels  . . . . . . . . . . . . . . . . .   8
  3.4.  Framework for analyzing feasibility of Internet
        protocols . . . . . . . . . . . . . . . . . . . . . . . .   9
  3.5.  Best Effort Service as a Deployment Success Factor  . . .   9
4.  Innovative / Out-There Models . . . . . . . . . . . . . . . .  10
  4.1.  On the Complexity of Designed Systems (and its effect
        on protocol deployment) . . . . . . . . . . . . . . . . .  10
  4.2.  Managing Diversity to Manage Technological
        Transition  . . . . . . . . . . . . . . . . . . . . . . .  10
  4.3.  On Economic Models of Network Technology Adoption,
        Design, and Viability . . . . . . . . . . . . . . . . . .  11
5.  Making Standards Better . . . . . . . . . . . . . . . . . . .  11
  5.1.  Standards: a love/hate relationship with patents  . . . .  11
  5.2.  Bridge Networking Research and Internet
        Standardization: Case Study on Mobile Traffic
        Offloading and IPv6 Transition Technologies . . . . . . .  11
  5.3.  An Internet Architecture for the Challenged . . . . . . .  12
6.  Other Challenges and Approaches . . . . . . . . . . . . . . .  12
  6.1.  Resilience of the commons: routing security . . . . . . .  12
  6.2.  Getting to the Next Version of TLS  . . . . . . . . . . .  13
7.  Outcomes  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.1.  Work for the IAB and the IETF . . . . . . . . . . . . . .  13
  7.2.  Potential for the Internet Research Task Force  . . . . .  14
  7.3.  Opportunities for Others  . . . . . . . . . . . . . . . .  14
8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
10. Attendees . . . . . . . . . . . . . . . . . . . . . . . . . .  15
11. Informative References  . . . . . . . . . . . . . . . . . . .  15

1. Introduction ✨

the Internet is a complex ecosystem that touches every part of society 🌍 At its heart is a protocol stack shaped like an hourglass, with IP right in the center. Recent research offers possible explanations for why that design succeeded, and for the big challenges that show up when you try to evolve or change its middle section. That's partially visible in the struggles IPv6 has run into. The workshop had plenty of other key examples to think about too, including the next generation of HTTP and real time web-browser communications (WebRTC) 💻 The eventual success of many, if not all, of these protocols will depend heavily on understanding not only which features and design principles add lasting value, but also how deployment strategies can succeed in unlocking that value and fostering adoption. The latter matters a lot, because most if not all Internet protocols have strong externalities that create serious barriers to adoption, especially when a well-established incumbent is around. In other words, factors outside the control of the end points (such as middleboxes) can limit deployment, sometimes by design 🚧

the Internet Architecture Board (IAB) holds occasional workshops to think about long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture 🔭 This long-term planning work is complementary to the ongoing engineering efforts done by working groups of the Internet Engineering Task Force (IETF), under the leadership of the Internet Engineering Steering Group (IESG) and area directorates.

taking [RFC5218] into account on what makes a protocol successful, this workshop set out to explore how the complex interactions between a protocol's design and its deployment affect its success 🧠 One of the workshop's goals was to encourage discussion, so we could understand what makes protocol designs successful, not only at meeting their initial design goals but, more importantly, in their ability to evolve as those goals and the available technology change. Another equally important goal was to develop protocol deployment strategies that ensure new features can rapidly gain enough of a foothold to ultimately realize broad adoption. Those strategies have to be informed by both operational considerations and economic factors 💅

the participants were operators, researchers from computer science and economics, and engineers 🤓 The contributions were wide ranging, so this report makes few recommendations for the IETF to consider.

1.1. Organization of This Report 🗂️

this report records the participants' discussions. At the end, workshop participants reviewed potential follow-up items. These get highlighted at each point during the report, and a summary is given at the end 📝

Section 2 reviews the motivations and existing work, and Section 3 discusses the economics of protocol adoption. Section 4 covers innovative models for protocol adoption. Section 5 delves into an examination of recent standards issues and some success stories. Section 6 examines different views of success factors. Finally, Section 7 examines potential next steps 🏁

2. Motivations and Review of Existing Work 🦋

the workshop kicked off with an intro asking the big question: is the neck of the Internet hourglass closed for business? 😬 There are lots of cases where progress has been slow, and the three biggest that come to mind are IPv6 [RFC2480], the Stream Control Transmission Protocol (SCTP) [RFC4960], and DNS Security (DNSSEC) [RFC4034]. DNSSEC is especially interesting, because other services rely on it for delivery, like DNS-Based Authentication of Named Entities (DANE) [RFC6698]. It could also be used for application discovery services through DNS, specifically where security properties are part of that discovery 🔐 So slowdown at the neck of the glass can have an impact closer to the lip 💋

even if you think of the classic neck of the hourglass as the IP and transport layers, someone suggested the hourglass might extend as high as the application layer 🤔

                      ______________________
                      \                    /
                       \   Applications   /
                        \                /
                         \              /
                          \            /
                           \__________/
                            | HTTP(s)|
                            |________|
                           /          \
                          /  TCP/IP    \
                         /______________\
                        /     MPLS/      \
                       /     Framing      \
                      /____________________\
                     /      Physical        \
                    /________________________\

                     HTTP(s) as the new neck?

this idea got rebutted with the argument that protocols do keep evolving, and that protocols like SMTP and IMAP in the applications space have kept evolving, just as the transport layer has 🙄

the workshop then moved on to a review of RFC 5218, which discusses protocol success factors. This work was presented in the IETF 70 plenary and was the basis for this ongoing work 🎀 Two clear outcomes came out of the discussion. The first was that the Internet Architecture Board should review and consider that document when evaluating Birds of a Feather (BoF) session proposals at the IETF, so that any working group proposal is carefully crafted to address a specific design space and provide positive net value. The second was to keep tracking the value-specific works in terms of success, wild success, or failure. On that last point, failure is still hard to judge, especially at the neck of the hourglass 😭

3. Economics of Protocol Adoption 💸

several papers were presented that looked at the economic aspects of protocol adoption 📄

3.1. When can bundling help adoption of network technologies or services? ✨

okay so economics of bundling is a super well-studied field 🤓 but apparently nobody's really applied it to protocols yet, which is kind of wild. it matters to the IETF because it's baked into two big ideas: layering and "mandatory to implement" 🧱 two current examples are DANE atop DNSSEC and WebRTC atop SCTP 💅 the workshop looked at a model [Weber13] that explores how bundling two technologies together can make adoption go up or down for one or both of them 📈📉 whether that happens depends on a bunch of stuff, like costs, benefits, and externalities for each tech.

quick reminder of what an externality is 💭 it's an effect or decision by one group that has a positive or negative impact on others who didn't get a choice or whose interests weren't considered. 🫶

bundling can be a total game changer when the individual capabilities just don't have enough critical mass on their own to push adoption forward 🚀 specifically, bundling helps when one technology doesn't offer any positive value until critical mass of deployment exists, and a second technology has low adoption cost and immediate value 🌸 that second one drives early adoption until there's a big enough user base for the first technology to finally hit critical mass and become valuable.

one question that came up was what happens when one technology depends on the other 🤔 that's directly tied to the "mandatory to implement" discussions in the IETF, and it's a matter for follow-on work 🎀 in the meantime, IETF participants can give researchers anecdotal experience to help improve models in this area. 💜

3.2. Internet Protocol Adoption: Learning from Bitcoin 🪙

the workshop looked at protocol success factors through the lens of Bitcoin [Boehme13] 👀 and honestly, bitcoin had SO many barriers to get past 😭 like adverse press, legal uncertainties, glitches and breaches, previous failed attempts, and speculative attacks. but it's still standing, and it's thanks to a few key factors:

  • First, there's a built-in reward system for early adopters. Participants are monetarily rewarded at an exponentially declining rate. 💰
  • There exist exchanges or conversion mechanisms that directly convert Bitcoin to other currencies. 🔄
  • Finally, there's some store of value in the currency itself, e.g., people find intrinsic value in it. 💎

the first two of these factors might be transferable to other approaches ✨ one key protocol success factor is direct benefit to the participant, and another is the ability to interface with other systems for mutual benefit. like, for Bitcoin, there has to be a way to exchange the coins for other currencies. the Internet email system had simpler adaption mechanisms to allow interchange with non-Internet email systems, and that really helped it succeed 📧 another more simply stated approach is "IP over everything" 🌈

the big takeaway from this presentation is that if a protocol imposes externalities or costs on other systems, you should find a way to establish incentives for those other players to implement it 🫶 and as it happens, there's a limited example that's directly relevant to the IETF 👑

3.3. Long term strategy for a successful deployment of DNSSEC - on all levels 🌍

the workshop reviewed the approach Sweden's .SE registry took to improve DNSSEC deployment [Lowinder13] 🇸🇪 .SE has roughly 1.5 million domains, and IIS (<https://www.iis.se>) manages the ccTLD (Country Code Top Level Domain). they decided to encourage DNSSEC deployment within .SE, and they started by understanding what the full ecosystem looked like 🔍 who their stakeholders were, and the financial, legal, and technical aspects of deployment. as they began their rollout, they charged extra for DNSSEC, and as they put it, this didn't work very well 😬

they went on to fund development of OpenDNSSEC to remove technical barriers to deployment at end sites, noting that tooling was lacking in this area 🛠️ even with that development, more tooling is necessary, since they pointed out a need for APIs between the signing zone and the registrar.

to further encourage deployment, the government of Sweden provided financial incentives to communities to see that their domains were signed 💸 .SE also provided an incentive to registrars to see that their domains were signed. in summary, .SE looked at all the players and provided incentives for each one to participate 🎀

the workshop discussed whether this model could be applied to other domains. .SE was in a position to effectively subsidize DNS deployment because of their ability to set prices 🤑 this may be appropriate for certain other top-level domains, but it was pointed out that the margins of other domains don't allow a cost reduction to be passed on at this point in time 😔

3.4. Framework for analyzing feasibility of Internet protocols 🔬

one of the goals of the workshop was to find ways to determine when work in the IETF was likely to lead to adoption 🎯 the workshop considered an interactive approach that combines value net analysis, deployment environment analysis, and technical architecture analysis, which leads to feasibility and solution analysis [Leva13]. this work offered an alternative to RFC 5218 that had many points in common 💕

the case study they examined was Multipath TCP (MPTCP) 🧩 and a bunch of deployment challenges came up. first and foremost, increasing bandwidth within the network seems to decrease the attractiveness of MPTCP 🙈 second, the benefit/cost tradeoff by vendors wasn't considered attractive, and third, not all parties may agree on the benefits.

the solutions analysis suggested several approaches to improve deployment, including using open-source software, lobbying various implementers, deploying proxies, and having parties that own both ends of a connection complete implementations 🌸

3.5. Best Effort Service as a Deployment Success Factor 🍦

when given the choice between vanilla and chocolate, why not choose both? 🍫🍦 the workshop considered an approach that became a recurring theme throughout the workshop: rather than examining when it was necessary to choose between technologies, implement multiple mechanisms to achieve adoption [Welzl13] that's giving main character energy 👑

the workshop discussed the case of Skype, which uses the best available transport mechanism to improve communication between clients, rather than tying its fate to any specific transport 📞 the argument goes that this kind of approach provides a means to introduce new transports, such as SCTP. this would be an adaptation of "Happy Eyeballs" [RFC6555] 🦋

4. Innovative / Out-There Models 🛸

there were several approaches presented that examined how we look at protocol adoption 🧠

4.1. On the Complexity of Designed Systems (and its effect on protocol deployment) 🧬

the workshop reviewed a comparison between the hourglass model and what systems biologists might call the bow tie model [Meyer13] 🎀 the crux of this comparison is that both rely on certain building blocks to accomplish a certain end. in the case of our hourglass model, IP sits notably in the center, whereas in systems biology, adenosine triphosphate (ATP) is the means by which all organisms convert nutrients to usable energy, so it sits centrally within the biological system ⚡

the workshop also examined the notion of "robust yet fragile" 💅 which looks at the balance between the cost of implementing robust systems and their value. like, highly efficient systems can prove fragile in the face of failure, or they may prove hard to evolve 🫠

the key question asked during this presentation was how we could apply what has been learned in systems biology, or what the findings reduce to for engineers 🤔 the answer was that more work is needed. the discussion highlighted the complexity of the Internet when it comes to predicting network behavior, so one promising area to examine may be network management 🌐

4.2. Managing Diversity to Manage Technological Transition 🦋

the workshop considered the difference between planned and unplanned technology transitions [Kohno13] 🇯🇵 they examined several transitions at the link, IP, and application layers in Japan. one key claim in the study is that there's a phase difference in the diversity trend between each layer 📊 the statistics presented show that HTTP is indeed the predominant substrate for other applications 🌸 another point made was that "natural selection" is a strong means to determine technology 🧬

along these lines, two papers were submitted that examined the formation of and changes to the hourglass in the context of evolutionary economics 📚 unfortunately, the presenter was unable to attend due to illness 🤒 the work was discussed at the workshop anyway, and there were different points of view as to the approach.

4.3. On Economic Models of Network Technology Adoption, Design, and Viability 💸

the workshop considered how network protocol capabilities enable certain services that are beneficial to consumers and service providers 🛍️ this model looks at smart data pricing (SDP), in which some behavior is desired and rewarded through a pricing model [Sen13]. the example given used time-dependent pricing (TDP), and it showed how a service provider was able to load shift traffic to off-peak periods ⏰ Explicit Congestion Notification (ECN) and RADIUS were used by the project alongside a simple GUI 💻 this sort of work may prove useful to service providers as caching models evolve over time. the question in the room was how protocol developers will consider these sorts of requirements 🤨

5. Making Standards Better ✨

there were several papers that focused on how standards are produced 📝

5.1. Standards: a love/hate relationship with patents ⚖️

one of the biggest barriers to deployment is the unseen patent held by the non-practicing entity (NPE) [Lear13] 😱 while this problem is relatively well understood by the industry, the discussion looked at patents as a means to improve interoperability 🫶 those who hold patents can license them in such a way that a single approach to standardization is the result. (e.g., they get to decide the venue for their work 👑)

5.2. Bridge Networking Research and Internet Standardization: Case Study on Mobile Traffic Offloading and IPv6 Transition Technologies 🌉✨

okay so this one is about the gap between the research community and the standards organizations 🥺. Two cases got examined: mobile offloading and IPv6 transition technologies [Ding13].

For mobile offloading, the mechanism needed you to understand both 3GPP (Third Generation Partnership Project) and IETF standards 😭. Resistance showed up in both orgs. In 3GPP, the issue was that they already had an offloading model in play 💅. In the IETF, the issue was a lack of understanding of the interdisciplinary space 🙈. The researchers admitted that with the IETF they may have taken the wrong tack by jumping straight into the solution without fully explaining the problem they were trying to solve 💀.

For IPv6 transition technologies, the researchers hit a crowded field with not much appetite for new transition techs 🌸.

The workshop also asked whether the standards arena is even the best venue, or the best measure of success, for researchers 🤔. The IRTF is meant to bridge academic research and the IETF 🦋. As we'll get into below, several avenues for continued dialog are being contemplated 🫶.

5.3. An Internet Architecture for the Challenged 🧩

The workshop got into a very provocative debate 🌶️ about whether the existing Internet architecture serves the broadest set of needs. Three specific aspects were looked at: geographic, technical, and socioeconomic. Researchers presented an alternative hourglass or protocol architecture called Lowest Common Denominator Networking (LCDNet). It re-examines some of the base assumptions of the existing architecture, including its "always on" nature [Sathiaseelan13] 🌀.

The workshop questioned a lot of the researchers' baseline assumptions. Part of this may have been because discussion time on the topic was constrained, and a fuller explanation was warranted ⏰.

6. Other Challenges and Approaches 🎀

The workshop had a bunch of other discussions about different approaches to technology adoption 💜. Worth highlighting: a number of papers on routing security were submitted, and two of them couldn't be presented 😭.

6.1. Resilience of the commons: routing security 🛡️

The workshop talked through a presentation on the tragedy of the commons in global inter-domain routing [Robachevsky13] 🌍. The "Internet Commons" is a collection of networks we depend on but don't control 🕸️. In the BGP context, the main threat to the commons is routing pollution, meaning unwanted or unnecessary routing entries 🗑️.

The Internet Society has been working with service providers to improve resiliency. They're doing this by building a common understanding of both the problem and solution space, and by developing a shared view on risk and benefits 🤝. The idea is that some folks would engage in reciprocal cooperation, hoping others would do the same, in order to break the tragedy 🔁.

What was notable in the discussion is that there's no magic bullet for the resiliency issue 🪄. It's really about clearly identifying the key players and convincing them that their incentives are aligned. It also involves developing approaches to measure resiliency 📊.

6.2. Getting to the Next Version of TLS 🔐

Originally, the workshop planned to look at whether the IETF could mandate stronger security 🧐. That evolved into a discussion about getting to the next version of Transport Layer Security (TLS) and what challenges lie ahead 🚧. It was pointed out that there are still many old versions of TLS in existence today, because of many old implementations 👴. In particular, a substantial amount of traffic is still encrypted using Triple DES 💀.

One concern about the next generation is that perfect could become the enemy of good 😤. Another point was that a testing platform might help interoperability 🧪. Finally, there was some discussion about how new versions of TLS get promoted 📣.

7. Outcomes 🏆

This wide-ranging workshop discussed a lot of the things that go to the success or failure of IETF work 🌈. There's no single silver bullet for making a protocol successful, but the workshop did discuss a number of outcomes and potential next steps ⭐.

7.1. Work for the IAB and the IETF 🏛️

The IAB's role in working group formation is to give guidance to the IESG on which Birds of a Feather sessions should be held, review proposed working group charters, and shepherd some work so it can reach a suitable stage for standardization 🧭. At each of these stages, the IAB has a chance to apply the lessons of RFC 5218, plus other work like the notion of bundling choices, when members give advice 🎁.

Beyond working group creation, the IAB has an opportunity to track and present protocol success stories, either through wikis or through discussion at plenary sessions 📚. For example, at the time of writing there's a lot of interest in Bitcoin, its success, and what parallels and lessons can be drawn 🪙. Specifically, it would be useful to track examples of first-mover advantages 🥇.

Finally, one area the IETF may wish to consider, relating specifically to DNSSEC, was raised by our speakers: standardizing the provisioning interface of DNSSEC (DS keys) between parent and child zone 🔑. Contributions in this area would be welcome 💌.

7.2. Potential for the Internet Research Task Force 🔬

There are at least two possible activities the IRTF might want to consider 👀. The first would be a research group that looks at protocol alternatives and recommendations that could be useful in areas where environments are constrained, due to bandwidth or other resources 📶. Such a group has actually already been proposed 🙌.

The second possibility is a more general group focused on economic considerations relating to Internet protocol design 💸. Several areas presented to the working group deserve further investigation and could use collaboration between researchers, engineers, and operators 🤓. Two examples are work on bundling and systems biology 🧬.

7.3. Opportunities for Others 🌟

Incentive models often involve lots of different players 🎭. As we considered work in the workshop, partners like ICANN and the Regional Internet Registries (RIRs) can keep playing a role in encouraging protocol deployment through their policies 📜. Their members can also join in any IRTF activity related to this work 🫂.

RIRs have a specific role to play in encouraging security of the routing system 🛣️, and ICANN has a specific role to play in securing the domain name service 🔒.

The suggestion was made that IETF working groups could leverage graduate students at universities around the world to help review documents (Internet-Drafts, RFCs, etc.) 🎓. This would teach students about real-world processes, engage the research community in IETF processes more thoroughly, and provide a scale-out resource for handling the IETF review workload 📖. Several attendees who have such students were ready to try this out 🙋‍♀️.

8. Security Considerations 🚨

This document does not discuss a protocol 🙃. Security for the workshop itself was excellent 🔐✨💖

9. Acknowledgments 💕

The IAB would like to thank the program committee, who were Roch Guerin, Constantine Dovrolis, Hannes Tschofenig, Joel Halpern, Eliot Lear, and Richard Clayton 🙌. Bernard Aboba and Dave Thaler also get a shout-out 📣. Their earlier work gave a super strong basis for this workshop 💪.

A very special debt of gratitude is owed to our hosts, Ross Anderson and Richard Clayton, for arranging such an excellent venue for our discussions 🏰🫶.

10. Attendees 📋

The following people attended the ITAT workshop 🧚:

Aaron Yi Ding, Adrian Farrel, Andrei Robachevsky, Andrew Sullivan, Arjuna Sathiaseelan, Bjoern Zeeb, Dave Meyer, Dave Thaler, Dongting Yu, Eliot Lear, Elwyn Davies, Erik Nordmark, Hannes Tschofenig, Joel Halpern, Jon Crowcroft, Lars Eggert, Martin Stiemerling, Michael Welzl, Michiel Leenaars, Miya Kohno, Rainer Boehme, Richard Clayton, Roch Guerin, Ross Anderson, Russ Housley, Sam Smith, Sean Turner, Soumya Sen, Spencer Dawkins, Steven Weber, Tapio Levae, Toby Moncaster, Tony Finch 💜

11. Informative References ✨

okay bestie, this is the bibliography, aka the list of all the papers the authors pulled from 🧚 every one of these came out of the same IAB 2013 Internet Technology Adoption and Transition workshop, and the RFC cites them as informative 📚

Author's Address ✨

Here's where you can find the editor, Eliot Lear, if you have questions. Slide into those emails, bestie 💌

Eliot Lear (editor)
Richtistrasse 7
Wallisellen, ZH  CH-8304
Switzerland

Phone: +41 44 878 9200
EMail: lear@cisco.com
📦 where this page comes from