Looking to the Future
Explore the intricate structures of computer network architectures with a focus on designing the future of the internet. Dive into Chapter 15 of David Clark's insightful work, "Designing an Internet," published by MIT Press in 2018. Gain valuable insights into the evolving landscape of network technologies and their impact on our digital world.
Uploaded on Mar 09, 2025 | 2 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Looking to the Future 1 CLARK, David. Designing an Internet. MIT Press. 2018. Chapter 15 Arquiteturas de Redes de Computadores (2020.1)
Warning 2 This chapter is highly speculative! I am going to offer my own views about future requirements And then I am going to offer my own thoughts as to what a suitable architecture might be. Possible research agenda for someone who wants to explore some new ideas. Conclusion: I can already see a second edition of this book in the future, perhaps with some very different opinions . Arquiteturas de Redes de Computadores (2020.1)
Drivers of Change 3 What causes network requirements to change over time? New developments in network and computer technology New approaches to application design Changing requirements in the larger context in which the Internet sits (chapter 14). Arquiteturas de Redes de Computadores (2020.1)
Drivers of Change: Technology 4 The network should evolve with end-node devices. E.g., PC and LANs coevolved. Cloud computing: massive data centers are driving the development of new networks suited for interconnection within a data center. IoT devices: have requirements for network management that are not addressed by the Internet of today. Clusters of devices will be connected to the global internet by some sort of a gateway element. A new proposal for an internet that does a better job at network management may be a better basis for the IoT future. Arquiteturas de Redes de Computadores (2020.1)
Drivers of Change: Application Design 5 Initially the ecosystem was very simple: TCP and, later, DNS. Recently: Web, CDN; streaming video and social media. My own bet for the next killer app is immersive, multiperson, interactive virtual reality, or it might be swarms of autonomous vehicles. The main questions for network designers are: How applications will be designed in the future and What demands they will place on the capabilities of the network. Arquiteturas de Redes de Computadores (2020.1)
Drivers of Change: Ecosystem 6 Either a future internet (and the ecosystem within which it sits) must offer a single delivery model that has sufficient generality to deal with bulk data transfer (e.g., large video files) as well as single packet exchanges or that future network will need to offer several delivery services suited to different classes of applications. The next measures of utility will be: (application and network) resilience, security, availability (multihoming), and consistency of service delivery (low and predictable latency). As the application development ecosystem does more, the network can do less as part of an overall solution to application support. Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 7 NDN goes against conventional wisdom and argues that routers that maintain per-packet state as part of forwarding are practical, which in turn suggests that designers should think about the most useful ways to exploit that state. NDN also argues that a network need not have routable addresses that map to end nodes. Packet delivery can be realized using only high-level names and state in routers. In the language of chapter 6, NDN has radically different expressive power. Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 8 Several proposals illustrate that there can be different classes of packets, with different kinds of addresses forwarded using different delivery services. TRIAD, DONA, and XIA illustrate that not all routers need to participate in all the delivery services. A subset of routers can implement one of the schemes (the more costly scheme in these proposals). These architectures exploit the more complex scheme during a setup phase, when the issues of performance are very different. XIA specifically argues that a single packet can carry multiple types of addresses so as to invoke more than one kind of delivery service. Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 9 MF argues that it is practical for a router to query a name resolution server as part of forwarding a packet. This structure shows up in other contexts: routers in SDNs also query a server to obtain forwarding information. What is distinctive about the GNS is that the names are of global scope. Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 10 Metanet and FII (among others) make the case for a clear specification of network services. The FII proposal talks about an application program interface, or API, but the details of the interface are not what matters. What matters is the specification of the service what the delivery service does. In the Internet, the single best-effort service is so weakly specified and highly variable that there is no reason to describe it explicitly. However, if an internet offers more complex services, the user (or the application builder) will need to know what they do in more detail. The specification of these services needs to be globally consistent (so applications can invoke the same service from different locations). Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 11 Nebula demonstrates that robust source routes are possible (perhaps at a considerable cost in complexity and overhead). These routes are robust in the sense that if the routers are trustworthy, the packets will only go where the sender intended them to go. In contrast, NewArch teaches that a network architecture need not include any sort of global identifier. If there is a valid locator, management of higher-level identifiers or names can be moved outside the architecture to higher layers. Mobility (in general) requires decoupling of locators from identity but, solving mobility, does not require that the network understand how identity is managed. Arquiteturas de Redes de Computadores (2020.1)
Lessons from Research on Alternative Network Design 12 Role-Based Architecture (RBA), part of the NewArch project, teaches that network protocols do not have to be layered. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 13 Envision the outcome of success: Designers of a new architecture should not just focus on the task of forwarding data. Reshaping the larger ecosystem in beneficial ways is transformative perhaps increasing the incentives for the different actors, creating new actors, or making application design easier, for example. Designers must think broadly about new proposals and envision the overall consequences of their proposal once it is successful and mature. They should describe the ecosystem, not just their own system. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 14 As the ecosystem does more, the network has less to do An internet architecture should not solve more of the problem than necessary. However, from the point of view of an innovator, it may seem alarming to develop a partial solution and hope that the ecosystem will emerge to complete it. Such a design puts success in the hands of others. The temptation is to design a system that is complete in itself. Such a solution may be easier to start but harder to grow. To increase the success of a new idea, it may be necessary to prototype both the idea and key parts of the ecosystem within which it is expected to live. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 15 The future is not just the Internet In the initial design era, our high-level objective was a single, globally interconnected network for everyone. Today, there are other global networks that are based on the same Internet technology but not directly interconnected with what we think of as the public Internet. These other networks have become part of the application development ecosystem, along with cloud computing, CDNs, and the like. For example, cloud providers use these networks to reach their enterprise customers, thereby shielding that traffic from various attacks and fluctuations in performance. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 16 The future is not just the Internet (cont.) In this richer ecosystem with multiple networks, what is the role of that part that we call the global Internet? One role is individual access the means by which people connect. Another role is peer-to-peer interaction applications that do not depend on the cloud or centralized services. The implications of these multiple networks on network architecture are not yet clear to me. Since these networks exist in isolation from each other, an architecture need not specify how they interact. Perhaps some problems related to security, resilience, or system overload can be solved just by isolation rather than by a complex mechanism Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 17 Customary business relationships are as ossifying as network protocols If a technical innovation requires coordination among multiple parties, the designers of the innovation must design a commercial framework (such as money routing) as well as technology. The holders of intellectual property rights have a single-minded focus on money routing. The firms in that industry are aggressive competitors when it comes to the production of content, but they cooperate in the design and enforcement of money routing. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 18 Customary business relationships are as ossifying as network protocols (cont.) The network industry should take a lesson from the content industry. If ISPs want to offer advanced services such as QoS, anycast, or multicast, the industry needs to organize to manage payment flows. It needs a general framework for the collective selling of services. A collective organization (let me call it a Service Fee Management Collective, or SFMC) would also make it easier for ISPs to sell higher-level services such as content caching and delivery. But just like a technical architecture, a payment scheme will have to evolve as it matures, and good governance (and legal advice) will be necessary for success. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 19 Consider the trade-off between network performance and architectural complexity The designers of several of the architectures I have discussed here have worked hard to remove a round-trip delay from the service they provide, specifically in the setup phase. In TRIAD, the setup packet flows through a series of routers that are specialized to handle the DNS-style lookup packet until it reaches the destination, which replies with a packet to complete a TCP connection; one round trip, more or less. Several other architectures have eliminated a round trip at the cost of adding complexity to the architecture. MF uses the GNS to recompute the binding from GUID to network in order to redirect a packet as it is being forwarded. Arquiteturas de Redes de Computadores (2020.1)
General insights about architectural design 20 Consider the trade-off between network performance and architectural complexity (cont.) My view is that saving one round trip in the case of a setup packet or other special circumstance (for example, the movement of a mobile device) is not justified if the result forces a complex mechanism into the network architecture that could otherwise be separated and performed in the larger ecosystem. In a hypothetical future dominated by massive numbers of small transfers among IoT-class devices, the overall performance may depend on the latency before the (small) transfer can start, which implies greater attention to removing excess round-trip interactions at the beginning of the transfer. This goal will have implications for naming, security (is a challenge-response authentication protocol necessary?), resilience, and other areas. Arquiteturas de Redes de Computadores (2020.1)
Thinking about Design 21 In this section, I am going to draw on lessons and insights from the various proposals I have discussed and weave them into yet another proposal for a network architecture. Arquiteturas de Redes de Computadores (2020.1)
Thinking about Design: Packet Delivery Services 22 Any proposal for a new network architecture has to start with a discussion of packet delivery services and their relationship to requirements. My current view is that an internet that offers a richer set of services could better support a wider range of applications and generate more revenues for ISPs, thus providing an increased incentive to invest. Perhaps a future internet should be deny by default : a receiver should consent to receive a packet as a precondition for receiving it. Arquiteturas de Redes de Computadores (2020.1)
A digression on the word service 23 A service is something you sell; it is how you make money. Technology is something you buy; it is how you spend money. In a layered system, services as well as technology are layered. There is technology at every level, and every level provides a service to the layer above it, so the word service is reused at every level. So in this section I am going to talk about a packet delivery service such as anycast being used to support a higher-level service such as cached data delivery. There could be many sorts of packet delivery services used to support many sorts of higher-level services. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Information-centric Networking 24 The premise of ICN is that an internet should use the names of data as a basis for packet delivery. Currently, I am not convinced that there is strong justification for making names for data part of an internet architecture. Putting names for data into the network layer requires the specification of a single naming scheme and, more importantly, a single scheme for binding those names to locations. I worry that a single scheme will prove too constraining to cover all the different patterns of data transfer. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Information-centric Networking 25 The issue of scale is a fundamental challenge to forwarding based on names. Names must be structured or organized in ways that give some guidance regarding the location of the data. I like the idea of using a location hint as part of a packet delivery service, but a hint is not a name. One justification for making names for data part of an internet architecture is data caching. However, I am not convinced of the benefit of this idea in practice. Content delivery is now being done in an effective way by CDNs. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Information-centric Networking 26 Another possible reason to make names for data objects part of an internet architecture is so the network can verify the validity of the named object. My preference is that identity credentials be visible only to the end points, not visible in the network. I do not think that it is necessary that the actual identifiers used to name services or nodes be self-certifying. That function can be implemented using some other information transmitted between the end points. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Information-centric Networking 27 A final concern I have with using data names in the network is revelation and balance of power. Putting the names of data into the packet header gives the ISP much power to engage in discriminatory behavior based on exactly what data is being transferred. It also gives much power to third parties (state actors, or ISPs acting as agents of the state) to exercise censorship and blocking. In my view (and design is not value-neutral so values may differ here), revealing the identity of data shifts too much power to the ISP and to third parties with adverse interests. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Service-Oriented Networking 28 Delivery to a service makes sense when the service is replicated in more than one location and the network takes responsibility for selecting a version of the service that is close or preferable by whatever measure the network specifies. An obvious example of a replicated higher-level service is a CDN or other form of data repository. I equated this delivery service to anycast, but saying anycast is not a sufficient specification of what the network-level service should do. The specification must consider issues of scale, performance, function, and cost. Anycast can be used as a building block for a data retrieval service similar to that provided by an ICN. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Service-Oriented Networking 29 Why put anycast into the network as opposed to using something like the DNS to map a higher-level service name to a nearby location as we do today? Here are some advantages: First, to pick a copy of a service that is closest to a requester, it is necessary to know where the requester is. Second, services such as CDNs are not simple. Third, anycast mitigates some malicious behavior, specifically a DDoS attack. If the service machines only share an anycast address, there is no way for an attacker to single out a specific target. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Service-Oriented Networking 30 I think the biggest barrier to the use of anycast is tussle. Using CDNs to illustrate my concern, today the operators of CDNs have control over how the CDN name (the DNS name) is mapped to an Internet address, because that binding is implemented in the part of the DNS that the CDN operator controls. Replacing this approach with the use of anycast shifts that control to the ISPs. The operators of CDNs will have to be convinced that with anycast they have not lost some crucial aspect of control to an actor that may not have interests fully aligned with theirs. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Per-Packet State 31 I am going to describe a variant of NDN that differs in two important ways: it delivers packets to services rather than delivering data, and it implements a range of explicit delivery services, rather than using the retrieval model of NDN, which uses a single delivery service. I illustrate the power of per-packet state by showing how to implement a variant of anycast that I call stickycast. One of the potential problems with anycast is that different packets sent to the same anycast address may go to different places. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Per-Packet State 32 Anycast could be extended so that while the initial anycast packet might go to one or another copy of the service, subsequent packets of the interchange would go to the same place. I believe that the mechanisms of NDN are excellent for solving this problem. An initial packet would be anycast to a service by using a delivery mechanism similar to the way NDN delivers an interest packet. The data name would be carried inside the interest packet, but the routers would not use that information for forwarding. The data name could be encrypted using the public key of the CDN. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Per-Packet State 33 To support continuity of the packet exchange, use the per-packet state supported by NDN in a different way. As NDN currently operates, routers have to record the interface through which an interest packet arrives in order to route the data packet back. There is a different kind of record that a router could make, which is to set up state based on the returning data packet, so the routers have a bidirectional record of the path of the exchange. Subsequent packets in the flow, marked by a temporary identifier, would follow the bidirectional records, creating the new sort of service I call stickycast. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Per-Packet State 34 This proposal is overly simple in that it does not address the complexity added by a mobile host. Per-packet state would deliver the data from the server back to a fixed point where the client is attached. If the client moves, the per-packet state has to be established at its new attachment point. The server will have to reestablish the state, which implies that the server must have some higher-level name for the client, perhaps similar to the scheme in MF. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Per-Packet State 35 ISPs will have to offer an anycast service for a cost that is lower than what it would cost the CDN provider to implement the same function internally, unless the anycast service does something that is very difficult for the CDN to do. Augmenting the anycast service with an interface through which the CDN can learn about network topology and current conditions might make the anycast service more valuable to the CDN. I would consider adding that complexity to the scheme. Multiple ISPs will have to cooperate to implement anycast delivery, so some money-routing scheme will be required. My hypothetical Service Fee Management Collective (SFMC) would be a way to sort out the money routing in this sort of multiprovider delivery service. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Multiple Address Spaces 36 The proposal in the previous subsection is too simplistic. Since many CDNs do not store all of their content in every server location, they may need to pass the request to a location where the content is stored This means that the servers have to talk among themselves. The challenge here is how the servers in the CDN can talk to each other if all they have is a shared anycast address. It would seem that, at least to talk among themselves, they need individual addresses. This would mean, first, that the architecture would have to support location-level addresses, and second, that those addresses might be a means to launch an attack against the CDN, thus losing the security benefits of the anycast group. Arquiteturas de Redes de Computadores (2020.1)
The Utility of Multiple Address Spaces 37 This problem can be solved in a way that again illustrates how the architecture can do less rather than more. In order to allow the members of a CDN to talk to each other, connect them using addresses from a separate address space. This could be either a virtual private network (again organized in the context of my SFMC) or one of the separate global networks that are now available in the current ecosystem. Arquiteturas de Redes de Computadores (2020.1)
End-Point Addresses and Balance of Power 38 I think end-point identifiers are not harmful, provided they are used in specific ways, and implementing them is an easy task for the network layer. Adding end-point addresses into the stickycast scheme mentioned earlier yields some very useful communication patterns. Arquiteturas de Redes de Computadores (2020.1)
End-Point Addresses and Balance of Power 39 Consider this elaboration of my service invocation scheme: A requester sends a data request to a CDN by using anycast. The packet is sent using an NDN-style delivery where there is no source address in the packet header. Instead, the sender encrypts its source address and includes it in the information in the interest packet, along with the name of the desired data. Next, the various nodes in the CDN communicate internally to select the node from which the data will be served. That final node decrypts the address from which the request came and sends an initial message back to that location, which sets up per-flow state in the routers to indicate where the packet came from. Arquiteturas de Redes de Computadores (2020.1)
End-Point Addresses and Balance of Power 40 Consider this elaboration of my service invocation scheme (cont.): That per-flow state means that the message back to the original requester does not need to include the address of the server node. Once that connection has been established (with bidirectional state on the routers along the paths), encrypted data can be exchanged over the connection. Arquiteturas de Redes de Computadores (2020.1)
End-Point Addresses and Balance of Power 41 From the perspective of an adverse third party such as a content censor, almost nothing is revealed by this sequence. The initial packet does not contain the address of the requester in a visible form and is directed to an anycast address. The censor can see the anycast address, so he can learn what higher-level service is being contacted, but that is all. A short time later, a connection to an end point will be made, identified by its address, but there is no indication of what service is initiating this request. There is no direct link between the original request and this subsequent connection. In terms of hiding information, this sequence reveals far less than any scheme based on data names. Arquiteturas de Redes de Computadores (2020.1)
Selecting the Delivery Service 42 If an internet offers multiple delivery services, which actor gets to pick the service? Several of the proposals I have described give that decision to the network, either explicitly or implicitly. For example, in the case of a multihomed host, the RINA scheme said that the end-point address was associated with the end point as a whole, not the interface on the end point, and the network would pick the best path to use. As another example, NDN nominally has only one delivery service, the exchange of an interest and data packet, but lurking inside NDN are a number of delivery services. It is the network, rather than the end point, that picks among them. Arquiteturas de Redes de Computadores (2020.1)
Selecting the Delivery Service 43 I think that the end point rather than the network should have control over which delivery service it invokes in the network. Allocating responsibility to the end node shifts power to the end point while allowing for more explicit marketing of service options by the network provider. In the data retrieval scenario I sketched, both the provider of the data and the requester of the data have some control over what service is to be used. Arquiteturas de Redes de Computadores (2020.1)
Selecting the Delivery Service 44 The provider of the data would create a high-level name for the data, including some identifier and one or more services from which it can be requested. Those services might be anycast, or, if the data is available at just one location, would involve unicast to that location. The requester would normally request the data by sending a packet to one of the services indicated by the provider but is free to try requesting the data from some other service if there is reason to think that service might be able to provide it. Arquiteturas de Redes de Computadores (2020.1)
The desert island scenario 45 Two people on a desert island have computers (or smartphones or whatever). There is no connection to the outside world. One person has a copy of the New York Times on his device, and the other wants to read it. NDN solves this by sending an interest packet that contains the name of the desired data; the other device can respond with the desired data if it chooses. It is equally possible to solve this problem by using services rather than data names. Arquiteturas de Redes de Computadores (2020.1)
The desert island scenario 46 Solution using services: Define a new high-level data retrieval service called local data sharing, and give it an anycast address. Define a version of the anycast service called local anycast, probably implemented by broadcast scoped in some way. Any device that is prepared to offer data would implement the local data sharing service and listen for packets sent to its anycast address. A request packet would be sent to this anycast address by using the local anycast delivery service. The name of the desired data would be in the request packet. The machine with the data could respond, just as before. Arquiteturas de Redes de Computadores (2020.1)
The desert island scenario 47 Commercial ISPs might choose not to offer the local anycast service or might block the local data-sharing anycast address to hinder content piracy. People not on a desert island might request the same data (using the same name) from a different delivery service by using a different variant of the anycast service. Going back to chapter 8 (Naming and Addressing), the anycast address of the data delivery service is serving as a hint as to how to find the data, but the sender is free to use another strategy, hint, or service. Arquiteturas de Redes de Computadores (2020.1)
The filming of the protest rally scenario 48 In this scenario, an activist at a protest rally wants to video what happens without being detected. Can a network delivery service help to hide this activity? Assume that there are security services monitoring network activity (in particular, wireless network transmission) as well as scanning the crowd for unacceptable behavior. An activist might pre-position a discrete camera that transmits what it is capturing to nearby receivers. The activist is nowhere near the camera, so if it is seized and confiscated, all that is lost is the camera. But the receivers, which might be smartphones in the pockets of other activists, want to avoid detection. Arquiteturas de Redes de Computadores (2020.1)
The filming of the protest rally scenario 49 A highly specialized delivery service can help with this challenge (from the perspective of the activist, not the security forces design is not value-neutral). One possible design is one-way transmission, with no acknowledgments sent back from the receivers. Several receivers may silently capture what they can, and then later (in a safer location), with luck, the data can be reassembled to form a complete record. Arquiteturas de Redes de Computadores (2020.1)
The filming of the protest rally scenario 50 In this mode of delivery, there is an opportunity to exploit a cross- layer optimization. Some wireless systems send messages as part of their control architecture, for example, to announce their presence. Crafty software on the video camera could listen to these messages, which have nothing to do with the reception of the video, to detect when there are potential receivers within range and what the signal quality is likely to be. The delivery service can adjust its behavior accordingly, buffering content until a receiver gets close or until content has been sent enough times that with high probability at least one copy has been received successfully. Arquiteturas de Redes de Computadores (2020.1)
