Internet Research: Comments on Formulating the Problem
Total Page:16
File Type:pdf, Size:1020Kb
Internet Research: Comments on Formulating the Problem Gathered by Sally Floyd, with contributions from Deborah Estrin, Greg Minshall, Vern Paxson, Lixia Zhang, and others. January 21, 1998 1 Introduction Development and deployment in the infrastructure is of necessity incremental. This note contains a discussion about formulating the research Explicit examined assumptions are better than implicit un- problem for Internet research. examined ones. The goal of this note is to further the discussion of implicit Changes in the Internet can be unanticipated and uncon- and explicit assumptions in network research. In particular, trolled. this note tries to articulate one such set of assumptions for In- The Internet architecture and scale make requirements for ternet research. Each of these assumptions is shared by some global consistency problematic. subset of the network research community, though perhaps Some research problems have their own natural time none of these assumptions are shared universally. The goal scales. of this paper is not to argue the validity of the assumptions, but to articulate them, to invite discussion of con¯icting or shared sets of assumptions, and to consider the implications 3 Discussion of the assumptions of these assumptions in formulating problems in Internet re- search. This process would aim for both a greater convergence Robustness is more important than ef®ciency. of underlying assumptions, and a more explicit and examined Robustness has been one of the great strengths of the Inter- discussion of those assumptions. net, integral to its design from the very beginning [Clark88]. In some sense, this note is in the tradition of Shenker et al.©s One of our overriding assumptions is that it is critical not to paper on ºPricing in Computer Networks: Reshaping the Re- subordinate robustness to the goal of more closely approxi- search Agendaº [Shenker96], which is a discussion about for- mating optimal ef®ciency. [This is discussed in more detail in mulating the research problem for the speci®c area of network the section on TCP.] pricing. This note does not address questions about how to de- The Internet is characterized by heterogeneity on many sign good protocols or write good papers; many of these ques- levels. tions are addressed elsewhere [ADVICE, Lampson84]. This note simply addresses the question of how to formulate the The Internet is characterized by heterogeneity on many research problem. levels: router scheduling algorithms and queue management The ®rst part of the paper brie¯y describes some underlying mechanisms, routing protocols, levels of multiplexing, proto- assumptions. The second part discusses implications of these col versions and implementations, etc. There is heterogene- assumptions in formulating research problems in various areas ity of underlying link layers (e.g., point-to-point, multiaccess of Internet research. links, wireless, ATM, FDDI, etc.). Because the Internet is composed of autonomous organizations and internet service providers, each with their own separate policy concerns, there is a heterogeneity of administrative domains and pricing struc- 2 Outlining the underlying assump- tures. There is a heterogeneity in the traf®c mix and in the tions levels of congestion at different times and places. As is dis- cussed later in the paper, this heterogeneity has to be taken A summary of the assumptions: into account in different ways with different areas of research. Robustness is more important than ef®ciency. Complex systems are not best designed from scratch and The Internet is characterized by heterogeneity on many on paper. levels. Our observation is that large complex systems are not best Complex systems are not best designed from scratch and designed on paper as a complete system and then imple- on paper. mented, but are best designed incrementally, with new insights 1 and development growing out of practical experience with ex- this period of change is not a temporary phenomena, but will isting functionally. Our assumption is that this is true for sub- continue to characterize the future Internet. systems such as the Mbone, reliable multicast protocols, or Some research problems have their own natural time integrated services as well as for larger systems such as the scales. global Internet. Some fundamental research problems are remote from con- Development and deployment in the infrastructure is of cerns of actual implementations, but many other research necessity incremental. problems have natural time scales related to the problem un- Unlike the development and deployment of applications, der consideration. Theses time scales might be the time scales which can sometimes spread like wild®re, the development on which decisions will be made either in the marketplace or and deployment of the infrastructure is of necessity incremen- in the IETF, the time scales after which conditions will have tal. This is due to both the scale of the infrastructure and to the changed enough to require reformulating the problem, etc. autonomy of individual components. This restriction to incre- Again, this is discussed further in the section on TCP. mental deployment is problematic for proposed mechanisms The Internet architecture and scale make requirements for (e.g., some scheduling algorithms, routing protocols, and QoS global consistency problematic. mechanisms) that will only be of use when they are ubiqui- A far-¯ung and complex system that requires consistency tously deployed throughout the Internet. or synchronization among all the components is problematic. Although there have been ©¯ag days© in the Internet in the This is particularly true given the scale and heterogeneity of past1, it seems unlikely that this can happen again. The 1983 administrative control in the current Internet. ¯ag day in particular was possible because at the time there was some centralized control of the ARPAnet by a single agency (i.e., DARPA). 4 Some implications Explicit examined assumptions are better than implicit un- These assumptions have several implications about formulat- examined ones. ing research problems. One implication is that starting from We all make implicit assumptions in our research, and such scratch and designing a new self-contained system is not al- implicit assumptions are often wrong. For example, because ways the most effective approach. In many cases it is more my intuition is partly shaped by my experiences with my sim- productive to take a piece of a larger problem, and to try to un- ulator, which until recently had a rather simple view of the derstand it and its relationship to the larger problem. These world, I tend to implicitly assume that TCP connections fol- might be exactly the problems that need attention. And in low ®xed symmetric paths on point-to-point links, with data many cases progress can be made in understanding a problem ¯owing only from the Ásender© to the Áreceiver©, and not vice- even if a complete answer is likely to be elusive and to require versa. The Áreal world© is of course much more complicated, the combined effort of the larger research community. with dynamic and asymmetric routing, multiaccess wireless One way to design for incremental evolution is to start with links, and two-way data traf®c within a single TCP connec- IP and the current Internet. IP lends itself to the addition tion. Implicit assumptions about things such as the nature of of rich new functionality and to the process of evolving to traf®c, the level of congestion, and the requirements of appli- meet new challenges. New transport protocols and applica- cations are in general highly problematic, and are best made tions are added, routers implement new queueing and schedul- as explicitly as possible. ing mechanisms, and new underlying technologies such as Changes in the Internet can be unanticipated and uncon- ATM or wireless are used. Other incremental changes either trolled. planned or already in progress include the incremental deploy- The history of the Internet has been one of unanticipated ment of IPv6, IP multicast, and integrated services. While change. This includes changes in applications (e.g., the web, it often looks attractive to design a new network architecture realtime traf®c) and in the infrastructure (e.g., past changes in from scratch to accomplish a speci®c purpose (e.g., OSI, X.25, routing, current changes to incorporate multicast, integrated ATM, active networks), our inclinations and experience are services, and IPv6). This can be particularly frustrating when with deploying new functionality in the IP network. the Internet changes, while you are in the middle of a research project, in ways that threaten to invalidate your work. As an example, work on integrated services can be dif®cult when on- 5 TCP going changes in the traf®c mix (e.g., the emergence of the web, realtime applications with congestion control and adap- In the next two sections we consider how these assumptions tive playback times, etc.) and pricing structures make it dif- about the nature of the Internet guide our own formulation of ®cult to ®nd ®rm ground on which to stand. We believe that speci®c research problems. This section examines some of the ways that our assumptions have shaped our framing of re- 1There was a Á¯ag day© in the ARPAnet for the transition of the ARPANET search questions on TCP. host protocol from NCP to TCP/IP in January 1, 1983 [Leiner97]. Implicit assumptions: 2 Early research on TCP dynamics (including our own) and more fruitful approach, in my judgement, would be to start focused on behavior with a small number of competing, instead with IP, the IP architecture, and the real world of the unlimited-demand TCP connections in one-way networks Internet. (Or, to rephrase, the only axiom is to start with IP and (e.g., the data traf®c going in one direction, and the acks go- the real world, characterized as it is by heterogeneity, change, ing in the other), in a simple topology with static routing over and the restrictions of incremental deployment.) point-to-point links.