idnits 2.17.1 draft-arkko-iab-internet-consolidation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 2004 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1958' is defined on line 341, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational B. Trammell 5 Expires: April 26, 2019 ETH Zurich 6 M. Nottingham 8 C. Huitema 9 Private Octopus Inc. 10 M. Thomson 11 Mozilla 12 J. Tantsura 13 Nuage Networks 14 October 23, 2018 16 Considerations on Internet Consolidation and the Internet Architecture 17 draft-arkko-iab-internet-consolidation-00 19 Abstract 21 Many of us have held a vision of the Internet as the ultimate 22 distributed platform that allows communication, the provision of 23 services, and competition from any corner of the world. But as the 24 Internet has matured, it seems to also feed the creation of large, 25 centralised entities in many areas. This phenomenon could be looked 26 at from many different angles, but this memo considers the topic from 27 the perspective of how available technology and Internet architecture 28 drives different market directions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 26, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Consolidation . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Economics . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Data- and Capital-intensive Services . . . . . . . . . . 4 68 2.3. Permissionless Innovation . . . . . . . . . . . . . . . . 5 69 2.4. Fundamentals of Communication . . . . . . . . . . . . . . 5 70 2.5. Technology Factors . . . . . . . . . . . . . . . . . . . 5 71 3. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Informative References . . . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Many of us have held a vision of the Internet as the ultimate 80 distributed platform that allows communication, the provision of 81 services, and competition from any corner of the world. But as the 82 Internet has matured, it seems to also feed the creation of large, 83 centralised entities in many areas. 85 Is Internet traffic consolidating, i.e., moving towards a larger 86 fraction of traffic involving a small set of large content providers 87 or social networks? It certainly appears so, though more 88 quantitative research on this topic would be welcome. 90 This phenomenon could be looked at from many different angles, but 91 this memo considers the topic from the perspective of how available 92 technology and Internet architecture drives different market 93 directions. How are technology choices and fundamentals of 94 communication affecting some of these trends? 95 Our engineering remit is to focus on technology, but of course we 96 also want to understand the implications and externalities of the 97 technical arrangements we design. Technology affects economics and 98 vice versa. The Internet technology community continues to make 99 decisions that have ramifications on Internet systems, just as we are 100 subject to forces that affect them. 102 As technologists, one question we have is whether there are changes 103 in technology that would help reduce technically-driven large-player 104 advantages. 106 This memo reviews areas where consolidation may be occurring in the 107 Internet, and discusses the potential reasons for this. Section 2 108 discusses consolidation and the reasons behind the creation of larger 109 entities, and Section 3 looks at some actions that might alleviate 110 the situation. 112 Note: If you are interested on this or other architecture-related 113 topics, please subscribe to the IAB architecture-discuss mailing list 114 as one forum for discussion. 116 2. Consolidation 118 Consolidation is driven by economic factors relating to scale and 119 ability to reach a large market over the Internet. In general, an 120 efficient market such as the Internet tends to enable winners to take 121 large market shares. 123 The most visible aspects of this involve well-recognised Internet 124 services, but it is important to recognise that the Internet is a 125 complex ecosystem. There are many underlying services whose 126 diversity, or lack thereof, are as important as that of, say, 127 consumer-visible social networks. For instance, the diversity of 128 cloud services, operating systems, browser engines is as important as 129 that as of application stores or the browsers themselves. 131 Of course, the Internet allows plenty of choice both in these and 132 other areas. Too many or too few choices create different kinds of 133 problems. 135 It would be useful to break these general factors and observations 136 down a bit further. In particular, it is useful to distinguish 137 market or economic factors from technical factors. 139 2.1. Economics 141 Scaling benefits are natural for many types of businesses. And many 142 Internet-based businesses can potentially serve a very large customer 143 base, as the cost of replicating and delivering their service to new 144 customers or areas is small. 146 However, typically the network effect has an even more pronounced 147 impact. Each additional user adds to the value of the network for 148 all users in a network. In some applications, such as the open web, 149 this value grows for everyone, as the web is a globally connected, 150 interoperable service for anyone with a browser can use. 152 There is an important distinction between different applications of 153 the network effect, however. Consider email as another example; 154 anyone with an account at any email server can use it globally. 155 However, here we have seen much more consolidation into few large 156 email providers, both due to innovative, high-quality services but 157 also because running email services by small entities is becoming 158 difficult; among other things due to spam prevention practices that 159 tend to recognise well only the largest entities. 161 In some other applications, such as social media, the services have a 162 more closed nature. The value of being a customer of one social 163 media service depends highly on how many other customers that 164 particular service has. Hence, the larger the service, the more 165 valuable it is. And the bigger the value difference to the 166 customers, the less practical choice they have in selecting a 167 service. 169 In some cases, these developments also allow asymmetric relationships 170 to form, with the customers having less ability to affect the service 171 than they would perhaps wish. 173 2.2. Data- and Capital-intensive Services 175 The scaling advantages are only getting larger with the advent of AI- 176 and machine learning -based technologies. 178 The more users a service has, the more data is available for training 179 machine learning models, and the better the service becomes, bringing 180 again more users. This feedback loop and the general capital- 181 intensive nature of the technology (data and processing at scale) 182 makes it likely that the largest companies are ahead in the use of 183 these technologies. 185 2.3. Permissionless Innovation 187 The email vs. social media example also highlights the interesting 188 roles of interoperability and the "permissionless innovation" 189 principle -- the idea that a network can be simple but still powerful 190 enough that essentially any application could be built on top of it 191 without needing any special support from anyone else. Permissionless 192 innovation has brought us all the innovative applications that we 193 enjoy today, on top of a highly interoperable underlying network, 194 along with advances in video coding and other techniques used by 195 applications. 197 Paradoxically, if the underlying network is sufficiently powerful, 198 the applications on top can evolve without similar pressures for 199 interoperability, leading to the closed but highly valuable services 200 discussed above. We call this the Permissionless Completeness 201 Problem. 203 2.4. Fundamentals of Communication 205 There are also fundamental issues. For instance, speed of light; 206 low-latency services can fundamentally only be provided through 207 globally distributed data centers. These are often provided built by 208 large organisations, although collaborative and data center or cloud 209 computing service approaches also exist. 211 A similar issue has arisen in recent years around large-scale denial- 212 of-service attacks, and how various entities can deal with them. 213 While the largest attacks affect all players (see, for instance, the 214 Dyn attacks in October 2016), it is also true that large cloud- and 215 content delivery providers can better deal with such attacks due to 216 their scale. This is one reason that attracts many network services 217 to such providers. 219 2.5. Technology Factors 221 One of the key questions is whether we are seeing developments that 222 are driven by economic factors or whether fundamental reasons or lack 223 available technology drives particular models. For instance, 224 centralised solutions might desirable due to business incentives, or 225 they might be necessary because there is no distributed, 226 collaborative solution. 228 For instance, some technical issues have historically not been easy 229 to solve, such as e-mail spam, which has lead to reliance on non- 230 technical solutions. Today, it is becoming increasingly difficult to 231 run your own mail services, essentially forcing many organisations 232 and individuals to employ larger providers. The issues relate 233 directly to size of entities; no one can afford to disconnect from 234 the largest providers. But as a small entity, there is little 235 leverage to convince peer entities or various supporting white/ 236 blacklist entities to deal with you properly. 238 Many Internet services are based on gathering data about users, and 239 using that data for, for instance, targeted advertisements. More 240 data from more users makes it possible to run a service more 241 accurately or with better results; here again scale brings 242 advantages. 244 Another trend is that more and more content is becoming available 245 locally, from a content delivery or provider function directly on 246 your own ISP's network. We predict that eventually most content will 247 be delivered this way, reducing the role that global IP connections 248 across the Internet play. By some metrics this has already happened; 249 what practical - positive or negative - impacts might this have on 250 the Internet technology? 252 There are also security tradeoffs. Large entities are generally 253 better equipped to move to more recent and more secure technology. 254 For instance, the Domain Name System (DNS) shows signs of ageing but 255 due to the legacy of deployed systems, has changed very slowly. 256 Newer technology developed at the IETF enables DNS queries to be 257 performed confidentially, but its deployment is happening mostly in 258 browsers that use global DNS resolver services, such as Cloudflare's 259 1.1.1.1 or Google's 8.8.8.8. This results in faster evolution and 260 better security for end users. 262 However, if one steps back and considers the overall security effects 263 of these developments, the resulting effects can be different. While 264 the security of the actual protocol exchanges improves with the 265 introduction of this new technology, at the same time this implies a 266 move from using a worldwide distributed set of DNS resolvers into, 267 again, more centralised global resolvers. While these resolvers are 268 very well maintained (and a great service), they are potentially 269 high-value targets for pervasive monitoring and Denial-of-Service 270 (DoS) attacks. In 2016, for example, DoS attacks were launched 271 against Dyn, one of the largest DNS providers, leading to some 272 outages. 274 3. Action 276 Are there assumptions about the Internet architecture that no longer 277 hold in a world where larger, more centralised entities provide big 278 parts of the Internet service? If the world changes, the Internet 279 and its technology/architecture may have to match those changes. 281 It appears that level the playing field for new entrants or small 282 players brings potential benefits. Are there technical solutions 283 that are missing today? 285 Of course, it may well be that technology improvements are hard to 286 come by. Nevertheless, recognising the risks of consolidation in 287 both current and proposed future technologies is the first step in 288 proactively avoiding those risks where possible. 290 Assuming that one does not wish for regulation, technologies that 291 support distributed architectures, open source implementations of 292 currently centralised network functions, or help increase user's 293 control can be beneficial. Federation, for example, would help 294 enable distributed services in situations where smaller entities 295 would like to collaborate. 297 Similarly, in an asymmetric power balance between users and services, 298 tools that enable the user to control what information is provided to 299 a particular service can be very helpful. Some such tools exist, for 300 instance, in the privacy and tracking-prevention modes of popular 301 browsers but why are these modes not the default, and could we 302 develop them further? 304 It is also surprising that in the age of software-defined everything, 305 we can program almost anything else except the globally provided, 306 packaged services. Opening up interfaces would allow the building of 307 additional, innovative services, and better match with users' needs. 309 Silver bullets are rare, of course. Internet service markets 310 sometimes fragment rather than cooperate through federation. And the 311 asymmetric power balances are easiest changed with data that is in 312 your control, but it is much harder to change when someone else holds 313 it. Nevertheless, the exploration of solutions to ensure the 314 Internet is kept open for new innovations and in the control of users 315 is very important. 317 What IETF topics that should be pursued to address some of the issues 318 around consolidation? 320 What measurements relating to the developments centralization or 321 consolidation should be pursued? 323 What research -- such as distributed Internet architectures -- should 324 be driven forward? 326 4. Contributors 328 Much of the text in this memo is from a blog article written by Jari 329 Arkko, Mark Nottingham, Christian Huitema, Martin Thomson, and Brian 330 Trammell for the Internet Architecture Board (IAB), and from a blog 331 article written by Jari Arkko and Brian Trammell APNIC and RIPE. 333 5. Acknowledgements 335 The authors would like to thank IAB members, Geoff Huston, Gonzalo 336 Camarillo, Mirjam Kuehne, Robert Mitchell, Olaf Kolkman, and many 337 others for interesting discussions in this problem space. 339 6. Informative References 341 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 342 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 343 . 345 Authors' Addresses 347 Jari Arkko 348 Ericsson 349 Kauniainen 02700 350 Finland 352 Email: jari.arkko@piuha.net 354 Brian Trammell 355 ETH Zurich 357 Email: ietf@trammell.ch 359 Mark Nottingham 361 Email: mnot@mnot.net 363 Christian Huitema 364 Private Octopus Inc. 366 Email: huitema@huitema.net 367 Martin Thomson 368 Mozilla 370 Email: martin.thomson@gmail.com 372 Jeff Tantsura 373 Nuage Networks 375 Email: jefftant.ietf@gmail.com