diff options
Diffstat (limited to 'generated/textbook.md')
| -rw-r--r-- | generated/textbook.md | 31112 |
1 files changed, 31112 insertions, 0 deletions
diff --git a/generated/textbook.md b/generated/textbook.md new file mode 100644 index 0000000..cfb43cd --- /dev/null +++ b/generated/textbook.md @@ -0,0 +1,31112 @@ + Computer Networking A Top-Down Approach Seventh Edition James F. Kurose +University of Massachusetts, Amherst Keith W. Ross NYU and NYU Shanghai + +Boston Columbus Indianapolis New York San Francisco Hoboken Amsterdam +Cape Town Dubai London Madrid Milan Munich Paris Montréal Toronto Delhi +Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Vice +President, Editorial Director, ECS: Marcia Horton Acquisitions Editor: +Matt Goldstein Editorial Assistant: Kristy Alaura Vice President of +Marketing: Christy Lesko Director of Field Marketing: Tim Galligan +Product Marketing Manager: Bram Van Kempen Field Marketing Manager: +Demetrius Hall Marketing Assistant: Jon Bryant Director of Product +Management: Erin Gregg Team Lead, Program and Project Management: Scott +Disanno Program Manager: Joanne Manning and Carole Snyder Project +Manager: Katrina Ostler, Ostler Editorial, Inc. Senior Specialist, +Program Planning and Support: Maura Zaldivar-Garcia + + Cover Designer: Joyce Wells Manager, Rights and Permissions: Ben Ferrini +Project Manager, Rights and Permissions: Jenny Hoffman, Aptara +Corporation Inventory Manager: Ann Lam Cover Image: Marc Gutierrez/Getty +Images Media Project Manager: Steve Wright Composition: Cenveo +Publishing Services Printer/Binder: Edwards Brothers Malloy Cover and +Insert Printer: Phoenix Color/ Hagerstown Credits and acknowledgments +borrowed from other sources and reproduced, with permission, in this +textbook appear on appropriate page within text. Copyright © 2017, 2013, +2010 Pearson Education, Inc. All rights reserved. Manufactured in the +United States of America. This publication is protected by Copyright, +and permission should be obtained from the publisher prior to any +prohibited reproduction, storage in a retrieval system, or transmission +in any form or by any means, electronic, mechanical, photocopying, +recording, or likewise. For information regarding permissions, request +forms and the appropriate contacts within the Pearson Education Global +Rights & Permissions Department, please visit +www.pearsoned.com/permissions/. Many of the designations by +manufacturers and seller to distinguish their products are claimed as +trademarks. Where those designations appear in this book, and the +publisher was aware of a trademark claim, the designations have been +printed in initial caps or all caps. Library of Congress +Cataloging-in-Publication Data Names: Kurose, James F. \| Ross, Keith +W., 1956Title: Computer networking: a top-down approach / James F. +Kurose, University of Massachusetts, Amherst, Keith W. Ross, NYU and NYU +Shanghai. Description: Seventh edition. \| Hoboken, New Jersey: Pearson, +\[2017\] \| Includes bibliographical references and index. Identifiers: +LCCN 2016004976 \| ISBN 9780133594140 \| ISBN 0133594149 Subjects: LCSH: +Internet. \| Computer networks. Classification: LCC TK5105.875.I57 K88 +2017 \| DDC 004.6-dc23 + + LC record available at http://lccn.loc.gov/2016004976 + +ISBN-10: + +0-13-359414-9 + +ISBN-13: 978-0-13-359414-0 + +About the Authors Jim Kurose Jim Kurose is a Distinguished University +Professor of Computer Science at the University of Massachusetts, +Amherst. He is currently on leave from the University of Massachusetts, +serving as an Assistant Director at the US National Science Foundation, +where he leads the Directorate of Computer and Information Science and +Engineering. Dr. Kurose has received a number of recognitions for his +educational activities including Outstanding Teacher Awards from the +National Technological University (eight times), the University of +Massachusetts, and the Northeast Association of Graduate Schools. He +received the IEEE Taylor Booth Education Medal and was recognized for +his leadership of Massachusetts' Commonwealth Information Technology +Initiative. He has won several conference best paper awards and received +the IEEE Infocom Achievement Award and the ACM Sigcomm Test of Time +Award. + +Dr. Kurose is a former Editor-in-Chief of IEEE Transactions on +Communications and of IEEE/ACM Transactions on Networking. He has served +as Technical Program co-Chair for IEEE Infocom, ACM SIGCOMM, ACM +Internet Measurement Conference, and ACM SIGMETRICS. He is a Fellow of +the IEEE and the ACM. His research interests include network protocols +and architecture, network measurement, multimedia communication, and +modeling and performance evaluation. He holds a PhD in Computer Science +from Columbia University. + +Keith Ross + + Keith Ross is the Dean of Engineering and Computer Science at NYU +Shanghai and the Leonard J. Shustek Chair Professor in the Computer +Science and Engineering Department at NYU. Previously he was at +University of Pennsylvania (13 years), Eurecom Institute (5 years) and +Polytechnic University (10 years). He received a B.S.E.E from Tufts +University, a M.S.E.E. from Columbia University, and a Ph.D. in Computer +and Control Engineering from The University of Michigan. Keith Ross is +also the co-founder and original CEO of Wimba, which develops online +multimedia applications for e-learning and was acquired by Blackboard in +2010. + +Professor Ross's research interests are in privacy, social networks, +peer-to-peer networking, Internet measurement, content distribution +networks, and stochastic modeling. He is an ACM Fellow, an IEEE Fellow, +recipient of the Infocom 2009 Best Paper Award, and recipient of 2011 +and 2008 Best Paper Awards for Multimedia Communications (awarded by +IEEE Communications Society). He has served on numerous journal +editorial boards and conference program committees, including IEEE/ACM +Transactions on Networking, ACM SIGCOMM, ACM CoNext, and ACM Internet +Measurement Conference. He also has served as an advisor to the Federal +Trade Commission on P2P file sharing. + +To Julie and our three precious ones---Chris, Charlie, and Nina JFK + +A big THANKS to my professors, colleagues, and students all over the +world. KWR + +Preface Welcome to the seventh edition of Computer Networking: A +Top-Down Approach. Since the publication of the first edition 16 years +ago, our book has been adopted for use at many hundreds of colleges and +universities, translated into 14 languages, and used by over one hundred +thousand students and practitioners worldwide. We've heard from many of +these readers and have been overwhelmed by the positive response. + + What's New in the Seventh Edition? We think one important reason for +this success has been that our book continues to offer a fresh and +timely approach to computer networking instruction. We've made changes +in this seventh edition, but we've also kept unchanged what we believe +(and the instructors and students who have used our book have confirmed) +to be the most important aspects of this book: its top-down approach, +its focus on the Internet and a modern treatment of computer networking, +its attention to both principles and practice, and its accessible style +and approach toward learning about computer networking. Nevertheless, +the seventh edition has been revised and updated substantially. +Long-time readers of our book will notice that for the first time since +this text was published, we've changed the organization of the chapters +themselves. The network layer, which had been previously covered in a +single chapter, is now covered in Chapter 4 (which focuses on the +so-called "data plane" component of the network layer) and Chapter 5 +(which focuses on the network layer's "control plane"). This expanded +coverage of the network layer reflects the swift rise in importance of +software-defined networking (SDN), arguably the most important and +exciting advance in networking in decades. Although a relatively recent +innovation, SDN has been rapidly adopted in practice---so much so that +it's already hard to imagine an introduction to modern computer +networking that doesn't cover SDN. The topic of network management, +previously covered in Chapter 9, has now been folded into the new +Chapter 5. As always, we've also updated many other sections of the text +to reflect recent changes in the dynamic field of networking since the +sixth edition. As always, material that has been retired from the +printed text can always be found on this book's Companion Website. The +most important updates are the following: Chapter 1 has been updated to +reflect the ever-growing reach and use of the Internet. Chapter 2, which +covers the application layer, has been significantly updated. We've +removed the material on the FTP protocol and distributed hash tables to +make room for a new section on application-level video streaming and +content distribution networks, together with Netflix and YouTube case +studies. The socket programming sections have been updated from Python 2 +to Python 3. Chapter 3, which covers the transport layer, has been +modestly updated. The material on asynchronous transport mode (ATM) +networks has been replaced by more modern material on the Internet's +explicit congestion notification (ECN), which teaches the same +principles. Chapter 4 covers the "data plane" component of the network +layer---the per-router forwarding function that determine how a packet +arriving on one of a router's input links is forwarded to one of that +router's output links. We updated the material on traditional Internet +forwarding found in all previous editions, and added material on packet +scheduling. We've also added a new section on generalized forwarding, as +practiced in SDN. There are also numerous updates throughout the +chapter. Material on multicast and broadcast communication has been +removed to make way for the new material. In Chapter 5, we cover the +control plane functions of the network layer---the network-wide logic +that controls how a datagram is routed along an end-to-end path of +routers from the source host to the destination host. As in previous +editions, we cover routing algorithms, as well as routing protocols +(with an updated treatment of BGP) used in today's Internet. We've added +a significant new section on the SDN control plane, where routing and +other functions are implemented in so-called SDN controllers. Chapter 6, +which now covers the link layer, has an updated treatment of Ethernet, +and of data center networking. Chapter 7, which covers wireless and +mobile networking, contains updated material on 802.11 (so-called "WiFi) +networks and cellular networks, including 4G and LTE. Chapter 8, which +covers network security and was extensively updated in the sixth +edition, has only + + modest updates in this seventh edition. Chapter 9, on multimedia +networking, is now slightly "thinner" than in the sixth edition, as +material on video streaming and content distribution networks has been +moved to Chapter 2, and material on packet scheduling has been +incorporated into Chapter 4. Significant new material involving +end-of-chapter problems has been added. As with all previous editions, +homework problems have been revised, added, and removed. As always, our +aim in creating this new edition of our book is to continue to provide a +focused and modern treatment of computer networking, emphasizing both +principles and practice. Audience This textbook is for a first course on +computer networking. It can be used in both computer science and +electrical engineering departments. In terms of programming languages, +the book assumes only that the student has experience with C, C++, Java, +or Python (and even then only in a few places). Although this book is +more precise and analytical than many other introductory computer +networking texts, it rarely uses any mathematical concepts that are not +taught in high school. We have made a deliberate effort to avoid using +any advanced calculus, probability, or stochastic process concepts +(although we've included some homework problems for students with this +advanced background). The book is therefore appropriate for +undergraduate courses and for first-year graduate courses. It should +also be useful to practitioners in the telecommunications industry. What +Is Unique About This Textbook? The subject of computer networking is +enormously complex, involving many concepts, protocols, and technologies +that are woven together in an intricate manner. To cope with this scope +and complexity, many computer networking texts are often organized +around the "layers" of a network architecture. With a layered +organization, students can see through the complexity of computer +networking---they learn about the distinct concepts and protocols in one +part of the architecture while seeing the big picture of how all parts +fit together. From a pedagogical perspective, our personal experience +has been that such a layered approach indeed works well. Nevertheless, +we have found that the traditional approach of teaching---bottom up; +that is, from the physical layer towards the application layer---is not +the best approach for a modern course on computer networking. A Top-Down +Approach Our book broke new ground 16 years ago by treating networking +in a top-down manner---that is, by beginning at the application layer +and working its way down toward the physical layer. The feedback we +received from teachers and students alike have confirmed that this +top-down approach has many advantages and does indeed work well +pedagogically. First, it places emphasis on the application layer (a +"high growth area" in networking). Indeed, many of the recent +revolutions in computer networking---including the Web, peer-to-peer +file sharing, and media streaming---have taken place at the application +layer. An early emphasis on application-layer issues differs from the +approaches taken in most other texts, which have only a small amount of +material on network applications, their requirements, application-layer +paradigms (e.g., client-server and peer-to-peer), and application +programming interfaces. Second, our experience as instructors (and that +of many instructors who have used this text) has been that teaching +networking applications near the beginning of the course is a powerful +motivational tool. Students are thrilled to learn about how networking + + applications work---applications such as e-mail and the Web, which most +students use on a daily basis. Once a student understands the +applications, the student can then understand the network services +needed to support these applications. The student can then, in turn, +examine the various ways in which such services might be provided and +implemented in the lower layers. Covering applications early thus +provides motivation for the remainder of the text. Third, a top-down +approach enables instructors to introduce network application +development at an early stage. Students not only see how popular +applications and protocols work, but also learn how easy it is to create +their own network applications and application-level protocols. With the +top-down approach, students get early exposure to the notions of socket +programming, service models, and protocols---important concepts that +resurface in all subsequent layers. By providing socket programming +examples in Python, we highlight the central ideas without confusing +students with complex code. Undergraduates in electrical engineering and +computer science should not have difficulty following the Python code. +An Internet Focus Although we dropped the phrase "Featuring the +Internet" from the title of this book with the fourth edition, this +doesn't mean that we dropped our focus on the Internet. Indeed, nothing +could be further from the case! Instead, since the Internet has become +so pervasive, we felt that any networking textbook must have a +significant focus on the Internet, and thus this phrase was somewhat +unnecessary. We continue to use the Internet's architecture and +protocols as primary vehicles for studying fundamental computer +networking concepts. Of course, we also include concepts and protocols +from other network architectures. But the spotlight is clearly on the +Internet, a fact reflected in our organizing the book around the +Internet's five-layer architecture: the application, transport, network, +link, and physical layers. Another benefit of spotlighting the Internet +is that most computer science and electrical engineering students are +eager to learn about the Internet and its protocols. They know that the +Internet has been a revolutionary and disruptive technology and can see +that it is profoundly changing our world. Given the enormous relevance +of the Internet, students are naturally curious about what is "under the +hood." Thus, it is easy for an instructor to get students excited about +basic principles when using the Internet as the guiding focus. Teaching +Networking Principles Two of the unique features of the book---its +top-down approach and its focus on the Internet---have appeared in the +titles of our book. If we could have squeezed a third phrase into the +subtitle, it would have contained the word principles. The field of +networking is now mature enough that a number of fundamentally important +issues can be identified. For example, in the transport layer, the +fundamental issues include reliable communication over an unreliable +network layer, connection establishment/ teardown and handshaking, +congestion and flow control, and multiplexing. Three fundamentally +important network-layer issues are determining "good" paths between two +routers, interconnecting a large number of heterogeneous networks, and +managing the complexity of a modern network. In the link layer, a +fundamental problem is sharing a multiple access channel. In network +security, techniques for providing confidentiality, authentication, and +message integrity are all based on cryptographic fundamentals. This text +identifies fundamental networking issues and studies approaches towards +addressing these issues. The student learning these principles will gain +knowledge with a long "shelf life"---long after today's network +standards and protocols have become obsolete, the principles they embody +will remain important and relevant. We believe that the combination of +using the Internet to get the student's foot in the door and then +emphasizing fundamental issues and solution approaches will allow the +student to + + quickly understand just about any networking technology. The Website +Each new copy of this textbook includes twelve months of access to a +Companion Website for all book readers at +http://www.pearsonhighered.com/cs-resources/, which includes: +Interactive learning material. The book's Companion Website contains +VideoNotes---video presentations of important topics throughout the book +done by the authors, as well as walkthroughs of solutions to problems +similar to those at the end of the chapter. We've seeded the Web site +with VideoNotes and online problems for Chapters 1 through 5 and will +continue to actively add and update this material over time. As in +earlier editions, the Web site contains the interactive Java applets +that animate many key networking concepts. The site also has interactive +quizzes that permit students to check their basic understanding of the +subject matter. Professors can integrate these interactive features into +their lectures or use them as mini labs. Additional technical material. +As we have added new material in each edition of our book, we've had to +remove coverage of some existing topics to keep the book at manageable +length. For example, to make room for the new material in this edition, +we've removed material on FTP, distributed hash tables, and +multicasting, Material that appeared in earlier editions of the text is +still of interest, and thus can be found on the book's Web site. +Programming assignments. The Web site also provides a number of detailed +programming assignments, which include building a multithreaded Web +server, building an e-mail client with a GUI interface, programming the +sender and receiver sides of a reliable data transport protocol, +programming a distributed routing algorithm, and more. Wireshark labs. +One's understanding of network protocols can be greatly deepened by +seeing them in action. The Web site provides numerous Wireshark +assignments that enable students to actually observe the sequence of +messages exchanged between two protocol entities. The Web site includes +separate Wireshark labs on HTTP, DNS, TCP, UDP, IP, ICMP, Ethernet, ARP, +WiFi, SSL, and on tracing all protocols involved in satisfying a request +to fetch a Web page. We'll continue to add new labs over time. In +addition to the Companion Website, the authors maintain a public Web +site, http://gaia.cs.umass.edu/kurose_ross/interactive, containing +interactive exercises that create (and present solutions for) problems +similar to selected end-of-chapter problems. Since students can generate +(and view solutions for) an unlimited number of similar problem +instances, they can work until the material is truly mastered. +Pedagogical Features We have each been teaching computer networking for +more than 30 years. Together, we bring more than 60 years of teaching +experience to this text, during which time we have taught many thousands +of students. We have also been active researchers in computer networking +during this time. (In fact, Jim and Keith first met each other as +master's students in a computer networking course taught by Mischa +Schwartz in 1979 at Columbia University.) We think all this gives us a +good perspective on where networking has been and where it is likely to +go in the future. Nevertheless, we have resisted temptations to bias the +material in this book towards our own pet research projects. We figure +you can visit our personal Web sites if you are interested in our +research. Thus, this book is about modern computer networking---it is +about contemporary protocols and technologies as well as the underlying +principles behind these protocols and technologies. We also believe + + that learning (and teaching!) about networking can be fun. A sense of +humor, use of analogies, and real-world examples in this book will +hopefully make this material more fun. Supplements for Instructors We +provide a complete supplements package to aid instructors in teaching +this course. This material can be accessed from Pearson's Instructor +Resource Center (http://www.pearsonhighered.com/irc). Visit the +Instructor Resource Center for information about accessing these +instructor's supplements. PowerPoint® slides. We provide PowerPoint +slides for all nine chapters. The slides have been completely updated +with this seventh edition. The slides cover each chapter in detail. They +use graphics and animations (rather than relying only on monotonous text +bullets) to make the slides interesting and visually appealing. We +provide the original PowerPoint slides so you can customize them to best +suit your own teaching needs. Some of these slides have been contributed +by other instructors who have taught from our book. Homework solutions. +We provide a solutions manual for the homework problems in the text, +programming assignments, and Wireshark labs. As noted earlier, we've +introduced many new homework problems in the first six chapters of the +book. Chapter Dependencies The first chapter of this text presents a +self-contained overview of computer networking. Introducing many key +concepts and terminology, this chapter sets the stage for the rest of +the book. All of the other chapters directly depend on this first +chapter. After completing Chapter 1, we recommend instructors cover +Chapters 2 through 6 in sequence, following our top-down philosophy. +Each of these five chapters leverages material from the preceding +chapters. After completing the first six chapters, the instructor has +quite a bit of flexibility. There are no interdependencies among the +last three chapters, so they can be taught in any order. However, each +of the last three chapters depends on the material in the first six +chapters. Many instructors first teach the first six chapters and then +teach one of the last three chapters for "dessert." One Final Note: We'd +Love to Hear from You We encourage students and instructors to e-mail us +with any comments they might have about our book. It's been wonderful +for us to hear from so many instructors and students from around the +world about our first five editions. We've incorporated many of these +suggestions into later editions of the book. We also encourage +instructors to send us new homework problems (and solutions) that would +complement the current homework problems. We'll post these on the +instructor-only portion of the Web site. We also encourage instructors +and students to create new Java applets that illustrate the concepts and +protocols in this book. If you have an applet that you think would be +appropriate for this text, please submit it to us. If the applet +(including notation and terminology) is appropriate, we'll be happy to +include it on the text's Web site, with an appropriate reference to the +applet's authors. So, as the saying goes, "Keep those cards and letters +coming!" Seriously, please do continue to send us interesting URLs, +point out typos, disagree with any of our claims, and tell us what works +and what doesn't work. Tell us what you think should or shouldn't be +included in the next edition. Send your e-mail to kurose@cs.umass.edu +and keithwross@nyu.edu. + + Acknowledgments Since we began writing this book in 1996, many people +have given us invaluable help and have been influential in shaping our +thoughts on how to best organize and teach a networking course. We want +to say A BIG THANKS to everyone who has helped us from the earliest +first drafts of this book, up to this seventh edition. We are also very +thankful to the many hundreds of readers from around the +world---students, faculty, practitioners---who have sent us thoughts and +comments on earlier editions of the book and suggestions for future +editions of the book. Special thanks go out to: Al Aho (Columbia +University) Hisham Al-Mubaid (University of Houston-Clear Lake) Pratima +Akkunoor (Arizona State University) Paul Amer (University of Delaware) +Shamiul Azom (Arizona State University) Lichun Bao (University of +California at Irvine) Paul Barford (University of Wisconsin) Bobby +Bhattacharjee (University of Maryland) Steven Bellovin (Columbia +University) Pravin Bhagwat (Wibhu) Supratik Bhattacharyya (previously at +Sprint) Ernst Biersack (Eurécom Institute) Shahid Bokhari (University of +Engineering & Technology, Lahore) Jean Bolot (Technicolor Research) +Daniel Brushteyn (former University of Pennsylvania student) Ken Calvert +(University of Kentucky) Evandro Cantu (Federal University of Santa +Catarina) Jeff Case (SNMP Research International) Jeff Chaltas (Sprint) +Vinton Cerf (Google) Byung Kyu Choi (Michigan Technological University) +Bram Cohen (BitTorrent, Inc.) Constantine Coutras (Pace University) John +Daigle (University of Mississippi) Edmundo A. de Souza e Silva (Federal +University of Rio de Janeiro) + + Philippe Decuetos (Eurécom Institute) Christophe Diot (Technicolor +Research) Prithula Dhunghel (Akamai) Deborah Estrin (University of +California, Los Angeles) Michalis Faloutsos (University of California at +Riverside) Wu-chi Feng (Oregon Graduate Institute) Sally Floyd (ICIR, +University of California at Berkeley) Paul Francis (Max Planck +Institute) David Fullager (Netflix) Lixin Gao (University of +Massachusetts) JJ Garcia-Luna-Aceves (University of California at Santa +Cruz) Mario Gerla (University of California at Los Angeles) David +Goodman (NYU-Poly) Yang Guo (Alcatel/Lucent Bell Labs) Tim Griffin +(Cambridge University) Max Hailperin (Gustavus Adolphus College) Bruce +Harvey (Florida A&M University, Florida State University) Carl Hauser +(Washington State University) Rachelle Heller (George Washington +University) Phillipp Hoschka (INRIA/W3C) Wen Hsin (Park University) +Albert Huang (former University of Pennsylvania student) Cheng Huang +(Microsoft Research) Esther A. Hughes (Virginia Commonwealth University) +Van Jacobson (Xerox PARC) Pinak Jain (former NYU-Poly student) Jobin +James (University of California at Riverside) Sugih Jamin (University of +Michigan) Shivkumar Kalyanaraman (IBM Research, India) Jussi Kangasharju +(University of Helsinki) Sneha Kasera (University of Utah) + + Parviz Kermani (formerly of IBM Research) Hyojin Kim (former University +of Pennsylvania student) Leonard Kleinrock (University of California at +Los Angeles) David Kotz (Dartmouth College) Beshan Kulapala (Arizona +State University) Rakesh Kumar (Bloomberg) Miguel A. Labrador +(University of South Florida) Simon Lam (University of Texas) Steve Lai +(Ohio State University) Tom LaPorta (Penn State University) Tim-Berners +Lee (World Wide Web Consortium) Arnaud Legout (INRIA) Lee Leitner +(Drexel University) Brian Levine (University of Massachusetts) Chunchun +Li (former NYU-Poly student) Yong Liu (NYU-Poly) William Liang (former +University of Pennsylvania student) Willis Marti (Texas A&M University) +Nick McKeown (Stanford University) Josh McKinzie (Park University) Deep +Medhi (University of Missouri, Kansas City) Bob Metcalfe (International +Data Group) Sue Moon (KAIST) Jenni Moyer (Comcast) Erich Nahum (IBM +Research) Christos Papadopoulos (Colorado Sate University) Craig +Partridge (BBN Technologies) Radia Perlman (Intel) Jitendra Padhye +(Microsoft Research) Vern Paxson (University of California at Berkeley) +Kevin Phillips (Sprint) + + George Polyzos (Athens University of Economics and Business) Sriram +Rajagopalan (Arizona State University) Ramachandran Ramjee (Microsoft +Research) Ken Reek (Rochester Institute of Technology) Martin Reisslein +(Arizona State University) Jennifer Rexford (Princeton University) Leon +Reznik (Rochester Institute of Technology) Pablo Rodrigez (Telefonica) +Sumit Roy (University of Washington) Dan Rubenstein (Columbia +University) Avi Rubin (Johns Hopkins University) Douglas Salane (John +Jay College) Despina Saparilla (Cisco Systems) John Schanz (Comcast) +Henning Schulzrinne (Columbia University) Mischa Schwartz (Columbia +University) Ardash Sethi (University of Delaware) Harish Sethu (Drexel +University) K. Sam Shanmugan (University of Kansas) Prashant Shenoy +(University of Massachusetts) Clay Shields (Georgetown University) Subin +Shrestra (University of Pennsylvania) Bojie Shu (former NYU-Poly +student) Mihail L. Sichitiu (NC State University) Peter Steenkiste +(Carnegie Mellon University) Tatsuya Suda (University of California at +Irvine) Kin Sun Tam (State University of New York at Albany) Don Towsley +(University of Massachusetts) David Turner (California State University, +San Bernardino) Nitin Vaidya (University of Illinois) Michele Weigle +(Clemson University) + + David Wetherall (University of Washington) Ira Winston (University of +Pennsylvania) Di Wu (Sun Yat-sen University) Shirley Wynn (NYU-Poly) Raj +Yavatkar (Intel) Yechiam Yemini (Columbia University) Dian Yu (NYU +Shanghai) Ming Yu (State University of New York at Binghamton) Ellen +Zegura (Georgia Institute of Technology) Honggang Zhang (Suffolk +University) Hui Zhang (Carnegie Mellon University) Lixia Zhang +(University of California at Los Angeles) Meng Zhang (former NYU-Poly +student) Shuchun Zhang (former University of Pennsylvania student) +Xiaodong Zhang (Ohio State University) ZhiLi Zhang (University of +Minnesota) Phil Zimmermann (independent consultant) Mike Zink +(University of Massachusetts) Cliff C. Zou (University of Central +Florida) We also want to thank the entire Pearson team---in particular, +Matt Goldstein and Joanne Manning---who have done an absolutely +outstanding job on this seventh edition (and who have put up with two +very finicky authors who seem congenitally unable to meet deadlines!). +Thanks also to our artists, Janet Theurer and Patrice Rossi Calkin, for +their work on the beautiful figures in this and earlier editions of our +book, and to Katie Ostler and her team at Cenveo for their wonderful +production work on this edition. Finally, a most special thanks go to +our previous two editors at Addison-Wesley---Michael Hirsch and Susan +Hartman. This book would not be what it is (and may well not have been +at all) without their graceful management, constant encouragement, +nearly infinite patience, good humor, and perseverance. + + Table of Contents Chapter 1 Computer Networks and the Internet 1 1.1 +What Is the Internet? 2 1.1.1 A Nuts-and-Bolts Description 2 1.1.2 A +Services Description 5 1.1.3 What Is a Protocol? 7 1.2 The Network Edge +9 1.2.1 Access Networks 12 1.2.2 Physical Media 18 1.3 The Network Core +21 1.3.1 Packet Switching 23 1.3.2 Circuit Switching 27 1.3.3 A Network +of Networks 31 1.4 Delay, Loss, and Throughput in Packet-Switched +Networks 35 1.4.1 Overview of Delay in Packet-Switched Networks 35 1.4.2 +Queuing Delay and Packet Loss 39 1.4.3 End-to-End Delay 41 1.4.4 +Throughput in Computer Networks 43 1.5 Protocol Layers and Their Service +Models 47 1.5.1 Layered Architecture 47 1.5.2 Encapsulation 53 1.6 +Networks Under Attack 55 1.7 History of Computer Networking and the +Internet 59 1.7.1 The Development of Packet Switching: 1961--1972 59 +1.7.2 Proprietary Networks and Internetworking: 1972--1980 60 1.7.3 A +Proliferation of Networks: 1980--1990 62 1.7.4 The Internet Explosion: +The 1990s 63 1.7.5 The New Millennium 64 1.8 Summary 65 + + Homework Problems and Questions 67 Wireshark Lab 77 Interview: Leonard +Kleinrock 79 Chapter 2 Application Layer 83 2.1 Principles of Network +Applications 84 2.1.1 Network Application Architectures 86 2.1.2 +Processes Communicating 88 2.1.3 Transport Services Available to +Applications 90 2.1.4 Transport Services Provided by the Internet 93 +2.1.5 Application-Layer Protocols 96 2.1.6 Network Applications Covered +in This Book 97 2.2 The Web and HTTP 98 2.2.1 Overview of HTTP 98 2.2.2 +Non-Persistent and Persistent Connections 100 2.2.3 HTTP Message Format +103 2.2.4 User-Server Interaction: Cookies 108 2.2.5 Web Caching 110 2.3 +Electronic Mail in the Internet 116 2.3.1 SMTP 118 2.3.2 Comparison with +HTTP 121 2.3.3 Mail Message Formats 121 2.3.4 Mail Access Protocols 122 +2.4 DNS---The Internet's Directory Service 126 2.4.1 Services Provided +by DNS 127 2.4.2 Overview of How DNS Works 129 2.4.3 DNS Records and +Messages 135 2.5 Peer-to-Peer Applications 140 2.5.1 P2P File +Distribution 140 2.6 Video Streaming and Content Distribution Networks +147 2.6.1 Internet Video 148 2.6.2 HTTP Streaming and DASH 148 + + 2.6.3 Content Distribution Networks 149 2.6.4 Case Studies: Netflix, +YouTube, and Kankan 153 2.7 Socket Programming: Creating Network +Applications 157 2.7.1 Socket Programming with UDP 159 2.7.2 Socket +Programming with TCP 164 2.8 Summary 170 Homework Problems and Questions +171 Socket Programming Assignments 180 Wireshark Labs: HTTP, DNS 182 +Interview: Marc Andreessen 184 Chapter 3 Transport Layer 187 3.1 +Introduction and Transport-Layer Services 188 3.1.1 Relationship Between +Transport and Network Layers 188 3.1.2 Overview of the Transport Layer +in the Internet 191 3.2 Multiplexing and Demultiplexing 193 3.3 +Connectionless Transport: UDP 200 3.3.1 UDP Segment Structure 204 3.3.2 +UDP Checksum 204 3.4 Principles of Reliable Data Transfer 206 3.4.1 +Building a Reliable Data Transfer Protocol 208 3.4.2 Pipelined Reliable +Data Transfer Protocols 217 3.4.3 Go-Back-N (GBN) 221 3.4.4 Selective +Repeat (SR) 226 3.5 Connection-Oriented Transport: TCP 233 3.5.1 The TCP +Connection 233 3.5.2 TCP Segment Structure 236 3.5.3 Round-Trip Time +Estimation and Timeout 241 3.5.4 Reliable Data Transfer 244 3.5.5 Flow +Control 252 3.5.6 TCP Connection Management 255 3.6 Principles of +Congestion Control 261 + + 3.6.1 The Causes and the Costs of Congestion 261 3.6.2 Approaches to +Congestion Control 268 3.7 TCP Congestion Control 269 3.7.1 Fairness 279 +3.7.2 Explicit Congestion Notification (ECN): Network-assisted +Congestion Control 282 3.8 Summary 284 Homework Problems and Questions +286 Programming Assignments 301 Wireshark Labs: Exploring TCP, UDP 302 +Interview: Van Jacobson 303 Chapter 4 The Network Layer: Data Plane 305 +4.1 Overview of Network Layer 306 4.1.1 Forwarding and Routing: The +Network Data and Control Planes 306 4.1.2 Network Service Models 311 4.2 +What's Inside a Router? 313 4.2.1 Input Port Processing and +Destination-Based Forwarding 316 4.2.2 Switching 319 4.2.3 Output Port +Processing 321 4.2.4 Where Does Queuing Occur? 321 4.2.5 Packet +Scheduling 325 4.3 The Internet Protocol (IP): IPv4, Addressing, IPv6, +and More 329 4.3.1 IPv4 Datagram Format 330 4.3.2 IPv4 Datagram +Fragmentation 332 4.3.3 IPv4 Addressing 334 4.3.4 Network Address +Translation (NAT) 345 4.3.5 IPv6 348 4.4 Generalized Forwarding and SDN +354 4.4.1 Match 356 4.4.2 Action 358 4.4.3 OpenFlow Examples of +Match-plus-action in Action 358 4.5 Summary 361 + + Homework Problems and Questions 361 Wireshark Lab 370 Interview: Vinton +G. Cerf 371 Chapter 5 The Network Layer: Control Plane 373 5.1 +Introduction 374 5.2 Routing Algorithms 376 5.2.1 The Link-State (LS) +Routing Algorithm 379 5.2.2 The Distance-Vector (DV) Routing Algorithm +384 5.3 Intra-AS Routing in the Internet: OSPF 391 5.4 Routing Among the +ISPs: BGP 395 5.4.1 The Role of BGP 395 5.4.2 Advertising BGP Route +Information 396 5.4.3 Determining the Best Routes 398 5.4.4 IP-Anycast +402 5.4.5 Routing Policy 403 5.4.6 Putting the Pieces Together: +Obtaining Internet Presence 406 5.5 The SDN Control Plane 407 5.5.1 The +SDN Control Plane: SDN Controller and SDN Control Applications 410 5.5.2 +OpenFlow Protocol 412 5.5.3 Data and Control Plane Interaction: An +Example 414 5.5.4 SDN: Past and Future 415 5.6 ICMP: The Internet +Control Message Protocol 419 5.7 Network Management and SNMP 421 5.7.1 +The Network Management Framework 422 5.7.2 The Simple Network Management +Protocol (SNMP) 424 5.8 Summary 426 Homework Problems and Questions 427 +Socket Programming Assignment 433 Programming Assignment 434 Wireshark +Lab 435 Interview: Jennifer Rexford 436 + + Chapter 6 The Link Layer and LANs 439 6.1 Introduction to the Link Layer +440 6.1.1 The Services Provided by the Link Layer 442 6.1.2 Where Is the +Link Layer Implemented? 443 6.2 Error-Detection and -Correction +Techniques 444 6.2.1 Parity Checks 446 6.2.2 Checksumming Methods 448 +6.2.3 Cyclic Redundancy Check (CRC) 449 6.3 Multiple Access Links and +Protocols 451 6.3.1 Channel Partitioning Protocols 453 6.3.2 Random +Access Protocols 455 6.3.3 Taking-Turns Protocols 464 6.3.4 DOCSIS: The +Link-Layer Protocol for Cable Internet Access 465 6.4 Switched Local +Area Networks 467 6.4.1 Link-Layer Addressing and ARP 468 6.4.2 Ethernet +474 6.4.3 Link-Layer Switches 481 6.4.4 Virtual Local Area Networks +(VLANs) 487 6.5 Link Virtualization: A Network as a Link Layer 491 6.5.1 +Multiprotocol Label Switching (MPLS) 492 6.6 Data Center Networking 495 +6.7 Retrospective: A Day in the Life of a Web Page Request 500 6.7.1 +Getting Started: DHCP, UDP, IP, and Ethernet 500 6.7.2 Still Getting +Started: DNS and ARP 502 6.7.3 Still Getting Started: Intra-Domain +Routing to the DNS Server 503 6.7.4 Web Client-Server Interaction: TCP +and HTTP 504 6.8 Summary 506 Homework Problems and Questions 507 +Wireshark Lab 515 Interview: Simon S. Lam 516 + + Chapter 7 Wireless and Mobile Networks 519 7.1 Introduction 520 7.2 +Wireless Links and Network Characteristics 525 7.2.1 CDMA 528 7.3 WiFi: +802.11 Wireless LANs 532 7.3.1 The 802.11 Architecture 533 7.3.2 The +802.11 MAC Protocol 537 7.3.3 The IEEE 802.11 Frame 542 7.3.4 Mobility +in the Same IP Subnet 546 7.3.5 Advanced Features in 802.11 547 7.3.6 +Personal Area Networks: Bluetooth and Zigbee 548 7.4 Cellular Internet +Access 551 7.4.1 An Overview of Cellular Network Architecture 551 7.4.2 +3G Cellular Data Networks: Extending the Internet to Cellular +Subscribers 554 7.4.3 On to 4G: LTE 557 7.5 Mobility Management: +Principles 560 7.5.1 Addressing 562 7.5.2 Routing to a Mobile Node 564 +7.6 Mobile IP 570 7.7 Managing Mobility in Cellular Networks 574 7.7.1 +Routing Calls to a Mobile User 576 7.7.2 Handoffs in GSM 577 7.8 +Wireless and Mobility: Impact on Higher-Layer Protocols 580 7.9 Summary +582 Homework Problems and Questions 583 Wireshark Lab 588 Interview: +Deborah Estrin 589 Chapter 8 Security in Computer Networks 593 8.1 What +Is Network Security? 594 8.2 Principles of Cryptography 596 8.2.1 +Symmetric Key Cryptography 598 8.2.2 Public Key Encryption 604 + + 8.3 Message Integrity and Digital Signatures 610 8.3.1 Cryptographic +Hash Functions 611 8.3.2 Message Authentication Code 613 8.3.3 Digital +Signatures 614 8.4 End-Point Authentication 621 8.4.1 Authentication +Protocol ap1.0 622 8.4.2 Authentication Protocol ap2.0 622 8.4.3 +Authentication Protocol ap3.0 623 8.4.4 Authentication Protocol ap3.1 +623 8.4.5 Authentication Protocol ap4.0 624 8.5 Securing E-Mail 626 +8.5.1 Secure E-Mail 627 8.5.2 PGP 630 8.6 Securing TCP Connections: SSL +631 8.6.1 The Big Picture 632 8.6.2 A More Complete Picture 635 8.7 +Network-Layer Security: IPsec and Virtual Private Networks 637 8.7.1 +IPsec and Virtual Private Networks (VPNs) 638 8.7.2 The AH and ESP +Protocols 640 8.7.3 Security Associations 640 8.7.4 The IPsec Datagram +641 8.7.5 IKE: Key Management in IPsec 645 8.8 Securing Wireless LANs +646 8.8.1 Wired Equivalent Privacy (WEP) 646 8.8.2 IEEE 802.11i 648 8.9 +Operational Security: Firewalls and Intrusion Detection Systems 651 +8.9.1 Firewalls 651 8.9.2 Intrusion Detection Systems 659 8.10 Summary +662 Homework Problems and Questions 664 Wireshark Lab 672 + + IPsec Lab 672 Interview: Steven M. Bellovin 673 Chapter 9 Multimedia +Networking 675 9.1 Multimedia Networking Applications 676 9.1.1 +Properties of Video 676 9.1.2 Properties of Audio 677 9.1.3 Types of +Multimedia Network Applications 679 9.2 Streaming Stored Video 681 9.2.1 +UDP Streaming 683 9.2.2 HTTP Streaming 684 9.3 Voice-over-IP 688 9.3.1 +Limitations of the Best-Effort IP Service 688 9.3.2 Removing Jitter at +the Receiver for Audio 691 9.3.3 Recovering from Packet Loss 694 9.3.4 +Case Study: VoIP with Skype 697 9.4 Protocols for Real-Time +Conversational Applications 700 9.4.1 RTP 700 9.4.2 SIP 703 9.5 Network +Support for Multimedia 709 9.5.1 Dimensioning Best-Effort Networks 711 +9.5.2 Providing Multiple Classes of Service 712 9.5.3 Diffserv 719 9.5.4 +Per-Connection Quality-of-Service (QoS) Guarantees: Resource Reservation +and Call Admission 723 9.6 Summary 726 Homework Problems and Questions +727 Programming Assignment 735 Interview: Henning Schulzrinne 736 +References 741 Index 783 + + Chapter 1 Computer Networks and the Internet + +Today's Internet is arguably the largest engineered system ever created +by mankind, with hundreds of millions of connected computers, +communication links, and switches; with billions of users who connect +via laptops, tablets, and smartphones; and with an array of new +Internet-connected "things" including game consoles, surveillance +systems, watches, eye glasses, thermostats, body scales, and cars. Given +that the Internet is so large and has so many diverse components and +uses, is there any hope of understanding how it works? Are there guiding +principles and structure that can provide a foundation for understanding +such an amazingly large and complex system? And if so, is it possible +that it actually could be both interesting and fun to learn about +computer networks? Fortunately, the answer to all of these questions is +a resounding YES! Indeed, it's our aim in this book to provide you with +a modern introduction to the dynamic field of computer networking, +giving you the principles and practical insights you'll need to +understand not only today's networks, but tomorrow's as well. This first +chapter presents a broad overview of computer networking and the +Internet. Our goal here is to paint a broad picture and set the context +for the rest of this book, to see the forest through the trees. We'll +cover a lot of ground in this introductory chapter and discuss a lot of +the pieces of a computer network, without losing sight of the big +picture. We'll structure our overview of computer networks in this +chapter as follows. After introducing some basic terminology and +concepts, we'll first examine the basic hardware and software components +that make up a network. We'll begin at the network's edge and look at +the end systems and network applications running in the network. We'll +then explore the core of a computer network, examining the links and the +switches that transport data, as well as the access networks and +physical media that connect end systems to the network core. We'll learn +that the Internet is a network of networks, and we'll learn how these +networks connect with each other. After having completed this overview +of the edge and core of a computer network, we'll take the broader and +more abstract view in the second half of this chapter. We'll examine +delay, loss, and throughput of data in a computer network and provide +simple quantitative models for end-to-end throughput and delay: models +that take into account transmission, propagation, and queuing delays. +We'll then introduce some of the key architectural principles in +computer networking, namely, protocol layering and service models. We'll +also learn that computer networks are vulnerable to many different types +of attacks; we'll survey + + some of these attacks and consider how computer networks can be made +more secure. Finally, we'll close this chapter with a brief history of +computer networking. + + 1.1 What Is the Internet? In this book, we'll use the public Internet, a +specific computer network, as our principal vehicle for discussing +computer networks and their protocols. But what is the Internet? There +are a couple of ways to answer this question. First, we can describe the +nuts and bolts of the Internet, that is, the basic hardware and software +components that make up the Internet. Second, we can describe the +Internet in terms of a networking infrastructure that provides services +to distributed applications. Let's begin with the nuts-and-bolts +description, using Figure 1.1 to illustrate our discussion. + +1.1.1 A Nuts-and-Bolts Description The Internet is a computer network +that interconnects billions of computing devices throughout the world. +Not too long ago, these computing devices were primarily traditional +desktop PCs, Linux workstations, and so-called servers that store and +transmit information such as Web pages and e-mail messages. +Increasingly, however, nontraditional Internet "things" such as laptops, +smartphones, tablets, TVs, gaming consoles, thermostats, home security +systems, home appliances, watches, eye glasses, cars, traffic control +systems and more are being connected to the Internet. Indeed, the term +computer network is beginning to sound a bit dated, given the many +nontraditional devices that are being hooked up to the Internet. In +Internet jargon, all of these devices are called hosts or end systems. +By some estimates, in 2015 there were about 5 billion devices connected +to the Internet, and the number will reach 25 billion by 2020 \[Gartner +2014\]. It is estimated that in 2015 there were over 3.2 billion +Internet users worldwide, approximately 40% of the world population +\[ITU 2015\]. + + Figure 1.1 Some pieces of the Internet + +End systems are connected together by a network of communication links +and packet switches. We'll see in Section 1.2 that there are many types +of communication links, which are made up of + + different types of physical media, including coaxial cable, copper wire, +optical fiber, and radio spectrum. Different links can transmit data at +different rates, with the transmission rate of a link measured in +bits/second. When one end system has data to send to another end system, +the sending end system segments the data and adds header bytes to each +segment. The resulting packages of information, known as packets in the +jargon of computer networks, are then sent through the network to the +destination end system, where they are reassembled into the original +data. A packet switch takes a packet arriving on one of its incoming +communication links and forwards that packet on one of its outgoing +communication links. Packet switches come in many shapes and flavors, +but the two most prominent types in today's Internet are routers and +link-layer switches. Both types of switches forward packets toward their +ultimate destinations. Link-layer switches are typically used in access +networks, while routers are typically used in the network core. The +sequence of communication links and packet switches traversed by a +packet from the sending end system to the receiving end system is known +as a route or path through the network. Cisco predicts annual global IP +traffic will pass the zettabyte (1021 bytes) threshold by the end of +2016, and will reach 2 zettabytes per year by 2019 \[Cisco VNI 2015\]. +Packet-switched networks (which transport packets) are in many ways +similar to transportation networks of highways, roads, and intersections +(which transport vehicles). Consider, for example, a factory that needs +to move a large amount of cargo to some destination warehouse located +thousands of kilometers away. At the factory, the cargo is segmented and +loaded into a fleet of trucks. Each of the trucks then independently +travels through the network of highways, roads, and intersections to the +destination warehouse. At the destination warehouse, the cargo is +unloaded and grouped with the rest of the cargo arriving from the same +shipment. Thus, in many ways, packets are analogous to trucks, +communication links are analogous to highways and roads, packet switches +are analogous to intersections, and end systems are analogous to +buildings. Just as a truck takes a path through the transportation +network, a packet takes a path through a computer network. End systems +access the Internet through Internet Service Providers (ISPs), including +residential ISPs such as local cable or telephone companies; corporate +ISPs; university ISPs; ISPs that provide WiFi access in airports, +hotels, coffee shops, and other public places; and cellular data ISPs, +providing mobile access to our smartphones and other devices. Each ISP +is in itself a network of packet switches and communication links. ISPs +provide a variety of types of network access to the end systems, +including residential broadband access such as cable modem or DSL, +high-speed local area network access, and mobile wireless access. ISPs +also provide Internet access to content providers, connecting Web sites +and video servers directly to the Internet. The Internet is all about +connecting end systems to each other, so the ISPs that provide access to +end systems must also be interconnected. These lower-tier ISPs are +interconnected through national and international upper-tier ISPs such +as Level 3 Communications, AT&T, Sprint, and NTT. An upper-tier ISP +consists of high-speed routers interconnected with high-speed +fiber-optic links. Each ISP network, whether upper-tier or lower-tier, +is + + managed independently, runs the IP protocol (see below), and conforms to +certain naming and address conventions. We'll examine ISPs and their +interconnection more closely in Section 1.3. End systems, packet +switches, and other pieces of the Internet run protocols that control +the sending and receiving of information within the Internet. The +Transmission Control Protocol (TCP) and the Internet Protocol (IP) are +two of the most important protocols in the Internet. The IP protocol +specifies the format of the packets that are sent and received among +routers and end systems. The Internet's principal protocols are +collectively known as TCP/IP. We'll begin looking into protocols in this +introductory chapter. But that's just a start---much of this book is +concerned with computer network protocols! Given the importance of +protocols to the Internet, it's important that everyone agree on what +each and every protocol does, so that people can create systems and +products that interoperate. This is where standards come into play. +Internet standards are developed by the Internet Engineering Task Force +(IETF) \[IETF 2016\]. The IETF standards documents are called requests +for comments (RFCs). RFCs started out as general requests for comments +(hence the name) to resolve network and protocol design problems that +faced the precursor to the Internet \[Allman 2011\]. RFCs tend to be +quite technical and detailed. They define protocols such as TCP, IP, +HTTP (for the Web), and SMTP (for e-mail). There are currently more than +7,000 RFCs. Other bodies also specify standards for network components, +most notably for network links. The IEEE 802 LAN/MAN Standards Committee +\[IEEE 802 2016\], for example, specifies the Ethernet and wireless WiFi +standards. + +1.1.2 A Services Description Our discussion above has identified many of +the pieces that make up the Internet. But we can also describe the +Internet from an entirely different angle---namely, as an infrastructure +that provides services to applications. In addition to traditional +applications such as e-mail and Web surfing, Internet applications +include mobile smartphone and tablet applications, including Internet +messaging, mapping with real-time road-traffic information, music +streaming from the cloud, movie and television streaming, online social +networks, video conferencing, multi-person games, and location-based +recommendation systems. The applications are said to be distributed +applications, since they involve multiple end systems that exchange data +with each other. Importantly, Internet applications run on end +systems--- they do not run in the packet switches in the network core. +Although packet switches facilitate the exchange of data among end +systems, they are not concerned with the application that is the source +or sink of data. Let's explore a little more what we mean by an +infrastructure that provides services to applications. To this end, +suppose you have an exciting new idea for a distributed Internet +application, one that may greatly benefit humanity or one that may +simply make you rich and famous. How might you go about + + transforming this idea into an actual Internet application? Because +applications run on end systems, you are going to need to write programs +that run on the end systems. You might, for example, write your programs +in Java, C, or Python. Now, because you are developing a distributed +Internet application, the programs running on the different end systems +will need to send data to each other. And here we get to a central +issue---one that leads to the alternative way of describing the Internet +as a platform for applications. How does one program running on one end +system instruct the Internet to deliver data to another program running +on another end system? End systems attached to the Internet provide a +socket interface that specifies how a program running on one end system +asks the Internet infrastructure to deliver data to a specific +destination program running on another end system. This Internet socket +interface is a set of rules that the sending program must follow so that +the Internet can deliver the data to the destination program. We'll +discuss the Internet socket interface in detail in Chapter 2. For now, +let's draw upon a simple analogy, one that we will frequently use in +this book. Suppose Alice wants to send a letter to Bob using the postal +service. Alice, of course, can't just write the letter (the data) and +drop the letter out her window. Instead, the postal service requires +that Alice put the letter in an envelope; write Bob's full name, +address, and zip code in the center of the envelope; seal the envelope; +put a stamp in the upper-right-hand corner of the envelope; and finally, +drop the envelope into an official postal service mailbox. Thus, the +postal service has its own "postal service interface," or set of rules, +that Alice must follow to have the postal service deliver her letter to +Bob. In a similar manner, the Internet has a socket interface that the +program sending data must follow to have the Internet deliver the data +to the program that will receive the data. The postal service, of +course, provides more than one service to its customers. It provides +express delivery, reception confirmation, ordinary use, and many more +services. In a similar manner, the Internet provides multiple services +to its applications. When you develop an Internet application, you too +must choose one of the Internet's services for your application. We'll +describe the Internet's services in Chapter 2. We have just given two +descriptions of the Internet; one in terms of its hardware and software +components, the other in terms of an infrastructure for providing +services to distributed applications. But perhaps you are still confused +as to what the Internet is. What are packet switching and TCP/IP? What +are routers? What kinds of communication links are present in the +Internet? What is a distributed application? How can a thermostat or +body scale be attached to the Internet? If you feel a bit overwhelmed by +all of this now, don't worry---the purpose of this book is to introduce +you to both the nuts and bolts of the Internet and the principles that +govern how and why it works. We'll explain these important terms and +questions in the following sections and chapters. + +1.1.3 What Is a Protocol? + + Now that we've got a bit of a feel for what the Internet is, let's +consider another important buzzword in computer networking: protocol. +What is a protocol? What does a protocol do? A Human Analogy It is +probably easiest to understand the notion of a computer network protocol +by first considering some human analogies, since we humans execute +protocols all of the time. Consider what you do when you want to ask +someone for the time of day. A typical exchange is shown in Figure 1.2. +Human protocol (or good manners, at least) dictates that one first offer +a greeting (the first "Hi" in Figure 1.2) to initiate communication with +someone else. The typical response to a "Hi" is a returned "Hi" message. +Implicitly, one then takes a cordial "Hi" response as an indication that +one can proceed and ask for the time of day. A different response to the +initial "Hi" (such as "Don't bother me!" or "I don't speak English," or +some unprintable reply) might + +Figure 1.2 A human protocol and a computer network protocol + +indicate an unwillingness or inability to communicate. In this case, the +human protocol would be not to ask for the time of day. Sometimes one +gets no response at all to a question, in which case one typically gives +up asking that person for the time. Note that in our human protocol, +there are specific messages + + we send, and specific actions we take in response to the received reply +messages or other events (such as no reply within some given amount of +time). Clearly, transmitted and received messages, and actions taken +when these messages are sent or received or other events occur, play a +central role in a human protocol. If people run different protocols (for +example, if one person has manners but the other does not, or if one +understands the concept of time and the other does not) the protocols do +not interoperate and no useful work can be accomplished. The same is +true in networking---it takes two (or more) communicating entities +running the same protocol in order to accomplish a task. Let's consider +a second human analogy. Suppose you're in a college class (a computer +networking class, for example!). The teacher is droning on about +protocols and you're confused. The teacher stops to ask, "Are there any +questions?" (a message that is transmitted to, and received by, all +students who are not sleeping). You raise your hand (transmitting an +implicit message to the teacher). Your teacher acknowledges you with a +smile, saying "Yes . . ." (a transmitted message encouraging you to ask +your question---teachers love to be asked questions), and you then ask +your question (that is, transmit your message to your teacher). Your +teacher hears your question (receives your question message) and answers +(transmits a reply to you). Once again, we see that the transmission and +receipt of messages, and a set of conventional actions taken when these +messages are sent and received, are at the heart of this +question-and-answer protocol. Network Protocols A network protocol is +similar to a human protocol, except that the entities exchanging +messages and taking actions are hardware or software components of some +device (for example, computer, smartphone, tablet, router, or other +network-capable device). All activity in the Internet that involves two +or more communicating remote entities is governed by a protocol. For +example, hardware-implemented protocols in two physically connected +computers control the flow of bits on the "wire" between the two network +interface cards; congestion-control protocols in end systems control the +rate at which packets are transmitted between sender and receiver; +protocols in routers determine a packet's path from source to +destination. Protocols are running everywhere in the Internet, and +consequently much of this book is about computer network protocols. As +an example of a computer network protocol with which you are probably +familiar, consider what happens when you make a request to a Web server, +that is, when you type the URL of a Web page into your Web browser. The +scenario is illustrated in the right half of Figure 1.2. First, your +computer will send a connection request message to the Web server and +wait for a reply. The Web server will eventually receive your connection +request message and return a connection reply message. Knowing that it +is now OK to request the Web document, your computer then sends the name +of the Web page it wants to fetch from that Web server in a GET message. +Finally, the Web server returns the Web page (file) to your computer. + + Given the human and networking examples above, the exchange of messages +and the actions taken when these messages are sent and received are the +key defining elements of a protocol: A protocol defines the format and +the order of messages exchanged between two or more communicating +entities, as well as the actions taken on the transmission and/or +receipt of a message or other event. The Internet, and computer networks +in general, make extensive use of protocols. Different protocols are +used to accomplish different communication tasks. As you read through +this book, you will learn that some protocols are simple and +straightforward, while others are complex and intellectually deep. +Mastering the field of computer networking is equivalent to +understanding the what, why, and how of networking protocols. + + 1.2 The Network Edge In the previous section we presented a high-level +overview of the Internet and networking protocols. We are now going to +delve a bit more deeply into the components of a computer network (and +the Internet, in particular). We begin in this section at the edge of a +network and look at the components with which we are most +familiar---namely, the computers, smartphones and other devices that we +use on a daily basis. In the next section we'll move from the network +edge to the network core and examine switching and routing in computer +networks. Recall from the previous section that in computer networking +jargon, the computers and other devices connected to the Internet are +often referred to as end systems. They are referred to as end systems +because they sit at the edge of the Internet, as shown in Figure 1.3. +The Internet's end systems include desktop computers (e.g., desktop PCs, +Macs, and Linux boxes), servers (e.g., Web and e-mail servers), and +mobile devices (e.g., laptops, smartphones, and tablets). Furthermore, +an increasing number of non-traditional "things" are being attached to +the Internet as end systems (see the Case History feature). End systems +are also referred to as hosts because they host (that is, run) +application programs such as a Web browser program, a Web server +program, an e-mail client program, or an e-mail server program. +Throughout this book we will use the + + Figure 1.3 End-system interaction + +CASE HISTORY THE INTERNET OF THINGS Can you imagine a world in which +just about everything is wirelessly connected to the Internet? A world +in which most people, cars, bicycles, eye glasses, watches, toys, +hospital equipment, home sensors, classrooms, video surveillance +systems, atmospheric sensors, store-shelf + + products, and pets are connected? This world of the Internet of Things +(IoT) may actually be just around the corner. By some estimates, as of +2015 there are already 5 billion things connected to the Internet, and +the number could reach 25 billion by 2020 \[Gartner 2014\]. These things +include our smartphones, which already follow us around in our homes, +offices, and cars, reporting our geolocations and usage data to our ISPs +and Internet applications. But in addition to our smartphones, a +wide-variety of non-traditional "things" are already available as +products. For example, there are Internet-connected wearables, including +watches (from Apple and many others) and eye glasses. Internet-connected +glasses can, for example, upload everything we see to the cloud, +allowing us to share our visual experiences with people around the world +in realtime. There are Internet-connected things already available for +the smart home, including Internet-connected thermostats that can be +controlled remotely from our smartphones, and Internet-connected body +scales, enabling us to graphically review the progress of our diets from +our smartphones. There are Internet-connected toys, including dolls that +recognize and interpret a child's speech and respond appropriately. The +IoT offers potentially revolutionary benefits to users. But at the same +time there are also huge security and privacy risks. For example, +attackers, via the Internet, might be able to hack into IoT devices or +into the servers collecting data from IoT devices. For example, an +attacker could hijack an Internet-connected doll and talk directly with +a child; or an attacker could hack into a database that stores personal +health and activity information collected from wearable devices. These +security and privacy concerns could undermine the consumer confidence +necessary for the technologies to meet their full potential and may +result in less widespread adoption \[FTC 2015\]. + +terms hosts and end systems interchangeably; that is, host = end system. +Hosts are sometimes further divided into two categories: clients and +servers. Informally, clients tend to be desktop and mobile PCs, +smartphones, and so on, whereas servers tend to be more powerful +machines that store and distribute Web pages, stream video, relay +e-mail, and so on. Today, most of the servers from which we receive +search results, e-mail, Web pages, and videos reside in large data +centers. For example, Google has 50-100 data centers, including about 15 +large centers, each with more than 100,000 servers. + +1.2.1 Access Networks Having considered the applications and end systems +at the "edge of the network," let's next consider the access +network---the network that physically connects an end system to the +first router (also known as the "edge router") on a path from the end +system to any other distant end system. Figure 1.4 shows several types +of access + + Figure 1.4 Access networks + +networks with thick, shaded lines and the settings (home, enterprise, +and wide-area mobile wireless) in which they are used. Home Access: DSL, +Cable, FTTH, Dial-Up, and Satellite + + In developed countries as of 2014, more than 78 percent of the +households have Internet access, with Korea, Netherlands, Finland, and +Sweden leading the way with more than 80 percent of households having +Internet access, almost all via a high-speed broadband connection \[ITU +2015\]. Given this widespread use of home access networks let's begin +our overview of access networks by considering how homes connect to the +Internet. Today, the two most prevalent types of broadband residential +access are digital subscriber line (DSL) and cable. A residence +typically obtains DSL Internet access from the same local telephone +company (telco) that provides its wired local phone access. Thus, when +DSL is used, a customer's telco is also its ISP. As shown in Figure 1.5, +each customer's DSL modem uses the existing telephone line (twistedpair +copper wire, which we'll discuss in Section 1.2.2) to exchange data with +a digital subscriber line access multiplexer (DSLAM) located in the +telco's local central office (CO). The home's DSL modem takes digital +data and translates it to high-frequency tones for transmission over +telephone wires to the CO; the analog signals from many such houses are +translated back into digital format at the DSLAM. The residential +telephone line carries both data and traditional telephone signals +simultaneously, which are encoded at different frequencies: A high-speed +downstream channel, in the 50 kHz to 1 MHz band A medium-speed upstream +channel, in the 4 kHz to 50 kHz band An ordinary two-way telephone +channel, in the 0 to 4 kHz band This approach makes the single DSL link +appear as if there were three separate links, so that a telephone call +and an Internet connection can share the DSL link at the same time. + +Figure 1.5 DSL Internet access + +(We'll describe this technique of frequency-division multiplexing in +Section 1.3.1.) On the customer side, a splitter separates the data and +telephone signals arriving to the home and forwards the data signal to + + the DSL modem. On the telco side, in the CO, the DSLAM separates the +data and phone signals and sends the data into the Internet. Hundreds or +even thousands of households connect to a single DSLAM \[Dischinger +2007\]. The DSL standards define multiple transmission rates, including +12 Mbps downstream and 1.8 Mbps upstream \[ITU 1999\], and 55 Mbps +downstream and 15 Mbps upstream \[ITU 2006\]. Because the downstream and +upstream rates are different, the access is said to be asymmetric. The +actual downstream and upstream transmission rates achieved may be less +than the rates noted above, as the DSL provider may purposefully limit a +residential rate when tiered service (different rates, available at +different prices) are offered. The maximum rate is also limited by the +distance between the home and the CO, the gauge of the twisted-pair line +and the degree of electrical interference. Engineers have expressly +designed DSL for short distances between the home and the CO; generally, +if the residence is not located within 5 to 10 miles of the CO, the +residence must resort to an alternative form of Internet access. While +DSL makes use of the telco's existing local telephone infrastructure, +cable Internet access makes use of the cable television company's +existing cable television infrastructure. A residence obtains cable +Internet access from the same company that provides its cable +television. As illustrated in Figure 1.6, fiber optics connect the cable +head end to neighborhood-level junctions, from which traditional coaxial +cable is then used to reach individual houses and apartments. Each +neighborhood junction typically supports 500 to 5,000 homes. Because +both fiber and coaxial cable are employed in this system, it is often +referred to as hybrid fiber coax (HFC). + +Figure 1.6 A hybrid fiber-coaxial access network + +Cable internet access requires special modems, called cable modems. As +with a DSL modem, the cable + + modem is typically an external device and connects to the home PC +through an Ethernet port. (We will discuss Ethernet in great detail in +Chapter 6.) At the cable head end, the cable modem termination system +(CMTS) serves a similar function as the DSL network's DSLAM---turning +the analog signal sent from the cable modems in many downstream homes +back into digital format. Cable modems divide the HFC network into two +channels, a downstream and an upstream channel. As with DSL, access is +typically asymmetric, with the downstream channel typically allocated a +higher transmission rate than the upstream channel. The DOCSIS 2.0 +standard defines downstream rates up to 42.8 Mbps and upstream rates of +up to 30.7 Mbps. As in the case of DSL networks, the maximum achievable +rate may not be realized due to lower contracted data rates or media +impairments. One important characteristic of cable Internet access is +that it is a shared broadcast medium. In particular, every packet sent +by the head end travels downstream on every link to every home and every +packet sent by a home travels on the upstream channel to the head end. +For this reason, if several users are simultaneously downloading a video +file on the downstream channel, the actual rate at which each user +receives its video file will be significantly lower than the aggregate +cable downstream rate. On the other hand, if there are only a few active +users and they are all Web surfing, then each of the users may actually +receive Web pages at the full cable downstream rate, because the users +will rarely request a Web page at exactly the same time. Because the +upstream channel is also shared, a distributed multiple access protocol +is needed to coordinate transmissions and avoid collisions. (We'll +discuss this collision issue in some detail in Chapter 6.) Although DSL +and cable networks currently represent more than 85 percent of +residential broadband access in the United States, an up-and-coming +technology that provides even higher speeds is fiber to the home (FTTH) +\[FTTH Council 2016\]. As the name suggests, the FTTH concept is +simple---provide an optical fiber path from the CO directly to the home. +Many countries today---including the UAE, South Korea, Hong Kong, Japan, +Singapore, Taiwan, Lithuania, and Sweden---now have household +penetration rates exceeding 30% \[FTTH Council 2016\]. There are several +competing technologies for optical distribution from the CO to the +homes. The simplest optical distribution network is called direct fiber, +with one fiber leaving the CO for each home. More commonly, each fiber +leaving the central office is actually shared by many homes; it is not +until the fiber gets relatively close to the homes that it is split into +individual customer-specific fibers. There are two competing +optical-distribution network architectures that perform this splitting: +active optical networks (AONs) and passive optical networks (PONs). AON +is essentially switched Ethernet, which is discussed in Chapter 6. Here, +we briefly discuss PON, which is used in Verizon's FIOS service. Figure +1.7 shows FTTH using the PON distribution architecture. Each home has an +optical network terminator (ONT), which is connected by dedicated +optical fiber to a neighborhood splitter. The splitter combines a number +of homes (typically less + + Figure 1.7 FTTH Internet access + +than 100) onto a single, shared optical fiber, which connects to an +optical line terminator (OLT) in the telco's CO. The OLT, providing +conversion between optical and electrical signals, connects to the +Internet via a telco router. In the home, users connect a home router +(typically a wireless router) to the ONT and access the Internet via +this home router. In the PON architecture, all packets sent from OLT to +the splitter are replicated at the splitter (similar to a cable head +end). FTTH can potentially provide Internet access rates in the gigabits +per second range. However, most FTTH ISPs provide different rate +offerings, with the higher rates naturally costing more money. The +average downstream speed of US FTTH customers was approximately 20 Mbps +in 2011 (compared with 13 Mbps for cable access networks and less than 5 +Mbps for DSL) \[FTTH Council 2011b\]. Two other access network +technologies are also used to provide Internet access to the home. In +locations where DSL, cable, and FTTH are not available (e.g., in some +rural settings), a satellite link can be used to connect a residence to +the Internet at speeds of more than 1 Mbps; StarBand and HughesNet are +two such satellite access providers. Dial-up access over traditional +phone lines is based on the same model as DSL---a home modem connects +over a phone line to a modem in the ISP. Compared with DSL and other +broadband access networks, dial-up access is excruciatingly slow at 56 +kbps. Access in the Enterprise (and the Home): Ethernet and WiFi On +corporate and university campuses, and increasingly in home settings, a +local area network (LAN) is used to connect an end system to the edge +router. Although there are many types of LAN technologies, Ethernet is +by far the most prevalent access technology in corporate, university, +and home networks. As shown in Figure 1.8, Ethernet users use +twisted-pair copper wire to connect to an Ethernet switch, a technology +discussed in detail in Chapter 6. The Ethernet switch, or a network of +such + + Figure 1.8 Ethernet Internet access + +interconnected switches, is then in turn connected into the larger +Internet. With Ethernet access, users typically have 100 Mbps or 1 Gbps +access to the Ethernet switch, whereas servers may have 1 Gbps or even +10 Gbps access. Increasingly, however, people are accessing the Internet +wirelessly from laptops, smartphones, tablets, and other "things" (see +earlier sidebar on "Internet of Things"). In a wireless LAN setting, +wireless users transmit/receive packets to/from an access point that is +connected into the enterprise's network (most likely using wired +Ethernet), which in turn is connected to the wired Internet. A wireless +LAN user must typically be within a few tens of meters of the access +point. Wireless LAN access based on IEEE 802.11 technology, more +colloquially known as WiFi, is now just about everywhere---universities, +business offices, cafes, airports, homes, and even in airplanes. In many +cities, one can stand on a street corner and be within range of ten or +twenty base stations (for a browseable global map of 802.11 base +stations that have been discovered and logged on a Web site by people +who take great enjoyment in doing such things, see \[wigle.net 2016\]). +As discussed in detail in Chapter 7, 802.11 today provides a shared +transmission rate of up to more than 100 Mbps. Even though Ethernet and +WiFi access networks were initially deployed in enterprise (corporate, +university) settings, they have recently become relatively common +components of home networks. Many homes combine broadband residential +access (that is, cable modems or DSL) with these inexpensive wireless +LAN technologies to create powerful home networks \[Edwards 2011\]. +Figure 1.9 shows a typical home network. This home network consists of a +roaming laptop as well as a wired PC; a base station (the wireless +access point), which communicates with the wireless PC and other +wireless devices in the home; a cable modem, providing broadband access +to the Internet; and a router, which interconnects the base station and +the stationary PC with the cable modem. This network allows household +members to have broadband access to the Internet with one member roaming +from the + + kitchen to the backyard to the bedrooms. + +Figure 1.9 A typical home network + +Wide-Area Wireless Access: 3G and LTE Increasingly, devices such as +iPhones and Android devices are being used to message, share photos in +social networks, watch movies, and stream music while on the run. These +devices employ the same wireless infrastructure used for cellular +telephony to send/receive packets through a base station that is +operated by the cellular network provider. Unlike WiFi, a user need only +be within a few tens of kilometers (as opposed to a few tens of meters) +of the base station. Telecommunications companies have made enormous +investments in so-called third-generation (3G) wireless, which provides +packet-switched wide-area wireless Internet access at speeds in excess +of 1 Mbps. But even higher-speed wide-area access technologies---a +fourth-generation (4G) of wide-area wireless networks---are already +being deployed. LTE (for "Long-Term Evolution"---a candidate for Bad +Acronym of the Year Award) has its roots in 3G technology, and can +achieve rates in excess of 10 Mbps. LTE downstream rates of many tens of +Mbps have been reported in commercial deployments. We'll cover the basic +principles of wireless networks and mobility, as well as WiFi, 3G, and +LTE technologies (and more!) in Chapter 7. + +1.2.2 Physical Media In the previous subsection, we gave an overview of +some of the most important network access technologies in the Internet. +As we described these technologies, we also indicated the physical media +used. For example, we said that HFC uses a combination of fiber cable +and coaxial cable. We said that DSL and Ethernet use copper wire. And we +said that mobile access networks use the radio spectrum. In this +subsection we provide a brief overview of these and other transmission +media that are commonly used in the Internet. + + In order to define what is meant by a physical medium, let us reflect on +the brief life of a bit. Consider a bit traveling from one end system, +through a series of links and routers, to another end system. This poor +bit gets kicked around and transmitted many, many times! The source end +system first transmits the bit, and shortly thereafter the first router +in the series receives the bit; the first router then transmits the bit, +and shortly thereafter the second router receives the bit; and so on. +Thus our bit, when traveling from source to destination, passes through +a series of transmitter-receiver pairs. For each transmitterreceiver +pair, the bit is sent by propagating electromagnetic waves or optical +pulses across a physical medium. The physical medium can take many +shapes and forms and does not have to be of the same type for each +transmitter-receiver pair along the path. Examples of physical media +include twisted-pair copper wire, coaxial cable, multimode fiber-optic +cable, terrestrial radio spectrum, and satellite radio spectrum. +Physical media fall into two categories: guided media and unguided +media. With guided media, the waves are guided along a solid medium, +such as a fiber-optic cable, a twisted-pair copper wire, or a coaxial +cable. With unguided media, the waves propagate in the atmosphere and in +outer space, such as in a wireless LAN or a digital satellite channel. +But before we get into the characteristics of the various media types, +let us say a few words about their costs. The actual cost of the +physical link (copper wire, fiber-optic cable, and so on) is often +relatively minor compared with other networking costs. In particular, +the labor cost associated with the installation of the physical link can +be orders of magnitude higher than the cost of the material. For this +reason, many builders install twisted pair, optical fiber, and coaxial +cable in every room in a building. Even if only one medium is initially +used, there is a good chance that another medium could be used in the +near future, and so money is saved by not having to lay additional wires +in the future. Twisted-Pair Copper Wire The least expensive and most +commonly used guided transmission medium is twisted-pair copper wire. +For over a hundred years it has been used by telephone networks. In +fact, more than 99 percent of the wired connections from the telephone +handset to the local telephone switch use twisted-pair copper wire. Most +of us have seen twisted pair in our homes (or those of our parents or +grandparents!) and work environments. Twisted pair consists of two +insulated copper wires, each about 1 mm thick, arranged in a regular +spiral pattern. The wires are twisted together to reduce the electrical +interference from similar pairs close by. Typically, a number of pairs +are bundled together in a cable by wrapping the pairs in a protective +shield. A wire pair constitutes a single communication link. Unshielded +twisted pair (UTP) is commonly used for computer networks within a +building, that is, for LANs. Data rates for LANs using twisted pair +today range from 10 Mbps to 10 Gbps. The data rates that can be achieved +depend on the thickness of the wire and the distance between transmitter +and receiver. When fiber-optic technology emerged in the 1980s, many +people disparaged twisted pair because of its relatively low bit rates. +Some people even felt that fiber-optic technology would completely +replace twisted pair. But twisted pair did not give up so easily. Modern +twisted-pair technology, such as category + + 6a cable, can achieve data rates of 10 Gbps for distances up to a +hundred meters. In the end, twisted pair has emerged as the dominant +solution for high-speed LAN networking. As discussed earlier, twisted +pair is also commonly used for residential Internet access. We saw that +dial-up modem technology enables access at rates of up to 56 kbps over +twisted pair. We also saw that DSL (digital subscriber line) technology +has enabled residential users to access the Internet at tens of Mbps +over twisted pair (when users live close to the ISP's central office). +Coaxial Cable Like twisted pair, coaxial cable consists of two copper +conductors, but the two conductors are concentric rather than parallel. +With this construction and special insulation and shielding, coaxial +cable can achieve high data transmission rates. Coaxial cable is quite +common in cable television systems. As we saw earlier, cable television +systems have recently been coupled with cable modems to provide +residential users with Internet access at rates of tens of Mbps. In +cable television and cable Internet access, the transmitter shifts the +digital signal to a specific frequency band, and the resulting analog +signal is sent from the transmitter to one or more receivers. Coaxial +cable can be used as a guided shared medium. Specifically, a number of +end systems can be connected directly to the cable, with each of the end +systems receiving whatever is sent by the other end systems. Fiber +Optics An optical fiber is a thin, flexible medium that conducts pulses +of light, with each pulse representing a bit. A single optical fiber can +support tremendous bit rates, up to tens or even hundreds of gigabits +per second. They are immune to electromagnetic interference, have very +low signal attenuation up to 100 kilometers, and are very hard to tap. +These characteristics have made fiber optics the preferred longhaul +guided transmission media, particularly for overseas links. Many of the +long-distance telephone networks in the United States and elsewhere now +use fiber optics exclusively. Fiber optics is also prevalent in the +backbone of the Internet. However, the high cost of optical +devices---such as transmitters, receivers, and switches---has hindered +their deployment for short-haul transport, such as in a LAN or into the +home in a residential access network. The Optical Carrier (OC) standard +link speeds range from 51.8 Mbps to 39.8 Gbps; these specifications are +often referred to as OC-n, where the link speed equals n ∞ 51.8 Mbps. +Standards in use today include OC-1, OC-3, OC-12, OC-24, OC-48, OC96, +OC-192, OC-768. \[Mukherjee 2006, Ramaswami 2010\] provide coverage of +various aspects of optical networking. Terrestrial Radio Channels Radio +channels carry signals in the electromagnetic spectrum. They are an +attractive medium because they require no physical wire to be installed, +can penetrate walls, provide connectivity to a mobile user, + + and can potentially carry a signal for long distances. The +characteristics of a radio channel depend significantly on the +propagation environment and the distance over which a signal is to be +carried. Environmental considerations determine path loss and shadow +fading (which decrease the signal strength as the signal travels over a +distance and around/through obstructing objects), multipath fading (due +to signal reflection off of interfering objects), and interference (due +to other transmissions and electromagnetic signals). Terrestrial radio +channels can be broadly classified into three groups: those that operate +over very short distance (e.g., with one or two meters); those that +operate in local areas, typically spanning from ten to a few hundred +meters; and those that operate in the wide area, spanning tens of +kilometers. Personal devices such as wireless headsets, keyboards, and +medical devices operate over short distances; the wireless LAN +technologies described in Section 1.2.1 use local-area radio channels; +the cellular access technologies use wide-area radio channels. We'll +discuss radio channels in detail in Chapter 7. Satellite Radio Channels +A communication satellite links two or more Earth-based microwave +transmitter/ receivers, known as ground stations. The satellite receives +transmissions on one frequency band, regenerates the signal using a +repeater (discussed below), and transmits the signal on another +frequency. Two types of satellites are used in communications: +geostationary satellites and low-earth orbiting (LEO) satellites \[Wiki +Satellite 2016\]. Geostationary satellites permanently remain above the +same spot on Earth. This stationary presence is achieved by placing the +satellite in orbit at 36,000 kilometers above Earth's surface. This huge +distance from ground station through satellite back to ground station +introduces a substantial signal propagation delay of 280 milliseconds. +Nevertheless, satellite links, which can operate at speeds of hundreds +of Mbps, are often used in areas without access to DSL or cable-based +Internet access. LEO satellites are placed much closer to Earth and do +not remain permanently above one spot on Earth. They rotate around Earth +(just as the Moon does) and may communicate with each other, as well as +with ground stations. To provide continuous coverage to an area, many +satellites need to be placed in orbit. There are currently many +low-altitude communication systems in development. LEO satellite +technology may be used for Internet access sometime in the future. + + 1.3 The Network Core Having examined the Internet's edge, let us now +delve more deeply inside the network core---the mesh of packet switches +and links that interconnects the Internet's end systems. Figure 1.10 +highlights the network core with thick, shaded lines. + + Figure 1.10 The network core + +1.3.1 Packet Switching In a network application, end systems exchange +messages with each other. Messages can contain anything the application +designer wants. Messages may perform a control function (for example, +the "Hi" messages in our handshaking example in Figure 1.2) or can +contain data, such as an e-mail message, a JPEG image, or an MP3 audio +file. To send a message from a source end system to a destination end +system, the source breaks long messages into smaller chunks of data +known as packets. Between source and destination, each packet travels +through communication links and packet switches (for which there are two +predominant types, routers and link-layer switches). Packets are +transmitted over each communication link at a rate equal to the full +transmission rate of the link. So, if a source end system or a packet +switch is sending a packet of L bits over a link with transmission rate +R bits/sec, then the time to transmit the packet is L / R seconds. +Store-and-Forward Transmission Most packet switches use +store-and-forward transmission at the inputs to the links. +Store-and-forward transmission means that the packet switch must receive +the entire packet before it can begin to transmit the first bit of the +packet onto the outbound link. To explore store-and-forward transmission +in more detail, consider a simple network consisting of two end systems +connected by a single router, as shown in Figure 1.11. A router will +typically have many incident links, since its job is to switch an +incoming packet onto an outgoing link; in this simple example, the +router has the rather simple task of transferring a packet from one +(input) link to the only other attached link. In this example, the +source has three packets, each consisting of L bits, to send to the +destination. At the snapshot of time shown in Figure 1.11, the source +has transmitted some of packet 1, and the front of packet 1 has already +arrived at the router. Because the router employs store-and-forwarding, +at this instant of time, the router cannot transmit the bits it has +received; instead it must first buffer (i.e., "store") the packet's +bits. Only after the router has received all of the packet's bits can it +begin to transmit (i.e., "forward") the packet onto the outbound link. +To gain some insight into store-and-forward transmission, let's now +calculate the amount of time that elapses from when the source begins to +send the packet until the destination has received the entire packet. +(Here we will ignore propagation delay---the time it takes for the bits +to travel across the wire at near the speed of light---which will be +discussed in Section 1.4.) The source begins to transmit at time 0; at +time L/R seconds, the source has transmitted the entire packet, and the +entire packet has been received and stored at the router (since there is +no propagation delay). At time L/R seconds, since the router has just +received the entire packet, it can begin to transmit the packet onto the +outbound link towards the destination; at time 2L/R, the router has +transmitted the entire packet, and the + + entire packet has been received by the destination. Thus, the total +delay is 2L/R. If the + +Figure 1.11 Store-and-forward packet switching + +switch instead forwarded bits as soon as they arrive (without first +receiving the entire packet), then the total delay would be L/R since +bits are not held up at the router. But, as we will discuss in Section +1.4, routers need to receive, store, and process the entire packet +before forwarding. Now let's calculate the amount of time that elapses +from when the source begins to send the first packet until the +destination has received all three packets. As before, at time L/R, the +router begins to forward the first packet. But also at time L/R the +source will begin to send the second packet, since it has just finished +sending the entire first packet. Thus, at time 2L/R, the destination has +received the first packet and the router has received the second packet. +Similarly, at time 3L/R, the destination has received the first two +packets and the router has received the third packet. Finally, at time +4L/R the destination has received all three packets! Let's now consider +the general case of sending one packet from source to destination over a +path consisting of N links each of rate R (thus, there are N-1 routers +between source and destination). Applying the same logic as above, we +see that the end-to-end delay is: dend-to-end=NLR + +(1.1) + +You may now want to try to determine what the delay would be for P +packets sent over a series of N links. Queuing Delays and Packet Loss +Each packet switch has multiple links attached to it. For each attached +link, the packet switch has an output buffer (also called an output +queue), which stores packets that the router is about to send into that +link. The output buffers play a key role in packet switching. If an +arriving packet needs to be transmitted onto a link but finds the link +busy with the transmission of another packet, the arriving packet must +wait in the output buffer. Thus, in addition to the store-and-forward +delays, packets suffer output buffer queuing delays. These delays are +variable and depend on the level of congestion in the network. + + Since the amount of buffer space is finite, an + +Figure 1.12 Packet switching + +arriving packet may find that the buffer is completely full with other +packets waiting for transmission. In this case, packet loss will +occur---either the arriving packet or one of the already-queued packets +will be dropped. Figure 1.12 illustrates a simple packet-switched +network. As in Figure 1.11, packets are represented by three-dimensional +slabs. The width of a slab represents the number of bits in the packet. +In this figure, all packets have the same width and hence the same +length. Suppose Hosts A and B are sending packets to Host E. Hosts A and +B first send their packets along 100 Mbps Ethernet links to the first +router. The router then directs these packets to the 15 Mbps link. If, +during a short interval of time, the arrival rate of packets to the +router (when converted to bits per second) exceeds 15 Mbps, congestion +will occur at the router as packets queue in the link's output buffer +before being transmitted onto the link. For example, if Host A and B +each send a burst of five packets back-to-back at the same time, then +most of these packets will spend some time waiting in the queue. The +situation is, in fact, entirely analogous to many common-day +situations---for example, when we wait in line for a bank teller or wait +in front of a tollbooth. We'll examine this queuing delay in more detail +in Section 1.4. Forwarding Tables and Routing Protocols Earlier, we said +that a router takes a packet arriving on one of its attached +communication links and forwards that packet onto another one of its +attached communication links. But how does the router determine which +link it should forward the packet onto? Packet forwarding is actually +done in different ways in different types of computer networks. Here, we +briefly describe how it is done in the Internet. + + In the Internet, every end system has an address called an IP address. +When a source end system wants to send a packet to a destination end +system, the source includes the destination's IP address in the packet's +header. As with postal addresses, this address has a hierarchical +structure. When a packet arrives at a router in the network, the router +examines a portion of the packet's destination address and forwards the +packet to an adjacent router. More specifically, each router has a +forwarding table that maps destination addresses (or portions of the +destination addresses) to that router's outbound links. When a packet +arrives at a router, the router examines the address and searches its +forwarding table, using this destination address, to find the +appropriate outbound link. The router then directs the packet to this +outbound link. The end-to-end routing process is analogous to a car +driver who does not use maps but instead prefers to ask for directions. +For example, suppose Joe is driving from Philadelphia to 156 Lakeside +Drive in Orlando, Florida. Joe first drives to his neighborhood gas +station and asks how to get to 156 Lakeside Drive in Orlando, Florida. +The gas station attendant extracts the Florida portion of the address +and tells Joe that he needs to get onto the interstate highway I-95 +South, which has an entrance just next to the gas station. He also tells +Joe that once he enters Florida, he should ask someone else there. Joe +then takes I-95 South until he gets to Jacksonville, Florida, at which +point he asks another gas station attendant for directions. The +attendant extracts the Orlando portion of the address and tells Joe that +he should continue on I-95 to Daytona Beach and then ask someone else. +In Daytona Beach, another gas station attendant also extracts the +Orlando portion of the address and tells Joe that he should take I-4 +directly to Orlando. Joe takes I-4 and gets off at the Orlando exit. Joe +goes to another gas station attendant, and this time the attendant +extracts the Lakeside Drive portion of the address and tells Joe the +road he must follow to get to Lakeside Drive. Once Joe reaches Lakeside +Drive, he asks a kid on a bicycle how to get to his destination. The kid +extracts the 156 portion of the address and points to the house. Joe +finally reaches his ultimate destination. In the above analogy, the gas +station attendants and kids on bicycles are analogous to routers. We +just learned that a router uses a packet's destination address to index +a forwarding table and determine the appropriate outbound link. But this +statement begs yet another question: How do forwarding tables get set? +Are they configured by hand in each and every router, or does the +Internet use a more automated procedure? This issue will be studied in +depth in Chapter 5. But to whet your appetite here, we'll note now that +the Internet has a number of special routing protocols that are used to +automatically set the forwarding tables. A routing protocol may, for +example, determine the shortest path from each router to each +destination and use the shortest path results to configure the +forwarding tables in the routers. How would you actually like to see the +end-to-end route that packets take in the Internet? We now invite you to +get your hands dirty by interacting with the Trace-route program. Simply +visit the site www.traceroute.org, choose a source in a particular +country, and trace the route from that source to your computer. (For a +discussion of Traceroute, see Section 1.4.) + + 1.3.2 Circuit Switching There are two fundamental approaches to moving +data through a network of links and switches: circuit switching and +packet switching. Having covered packet-switched networks in the +previous subsection, we now turn our attention to circuit-switched +networks. In circuit-switched networks, the resources needed along a +path (buffers, link transmission rate) to provide for communication +between the end systems are reserved for the duration of the +communication session between the end systems. In packet-switched +networks, these resources are not reserved; a session's messages use the +resources on demand and, as a consequence, may have to wait (that is, +queue) for access to a communication link. As a simple analogy, consider +two restaurants, one that requires reservations and another that neither +requires reservations nor accepts them. For the restaurant that requires +reservations, we have to go through the hassle of calling before we +leave home. But when we arrive at the restaurant we can, in principle, +immediately be seated and order our meal. For the restaurant that does +not require reservations, we don't need to bother to reserve a table. +But when we arrive at the restaurant, we may have to wait for a table +before we can be seated. Traditional telephone networks are examples of +circuit-switched networks. Consider what happens when one person wants +to send information (voice or facsimile) to another over a telephone +network. Before the sender can send the information, the network must +establish a connection between the sender and the receiver. This is a +bona fide connection for which the switches on the path between the +sender and receiver maintain connection state for that connection. In +the jargon of telephony, this connection is called a circuit. When the +network establishes the circuit, it also reserves a constant +transmission rate in the network's links (representing a fraction of +each link's transmission capacity) for the duration of the connection. +Since a given transmission rate has been reserved for this +sender-toreceiver connection, the sender can transfer the data to the +receiver at the guaranteed constant rate. Figure 1.13 illustrates a +circuit-switched network. In this network, the four circuit switches are +interconnected by four links. Each of these links has four circuits, so +that each link can support four simultaneous connections. The hosts (for +example, PCs and workstations) are each directly connected to one of the +switches. When two hosts want to communicate, the network establishes a +dedicated endto-end connection between the two hosts. Thus, in order for +Host A to communicate with Host B, the network must first reserve one +circuit on each of two links. In this example, the dedicated end-to-end +connection uses the second circuit in the first link and the fourth +circuit in the second link. Because each link has four circuits, for +each link used by the end-to-end connection, the connection gets one +fourth of the link's total transmission capacity for the duration of the +connection. Thus, for example, if each link between adjacent switches +has a transmission rate of 1 Mbps, then each end-to-end circuit-switch +connection gets 250 kbps of dedicated transmission rate. + + Figure 1.13 A simple circuit-switched network consisting of four +switches and four links + +In contrast, consider what happens when one host wants to send a packet +to another host over a packet-switched network, such as the Internet. As +with circuit switching, the packet is transmitted over a series of +communication links. But different from circuit switching, the packet is +sent into the network without reserving any link resources whatsoever. +If one of the links is congested because other packets need to be +transmitted over the link at the same time, then the packet will have to +wait in a buffer at the sending side of the transmission link and suffer +a delay. The Internet makes its best effort to deliver packets in a +timely manner, but it does not make any guarantees. Multiplexing in +Circuit-Switched Networks A circuit in a link is implemented with either +frequency-division multiplexing (FDM) or time-division multiplexing +(TDM). With FDM, the frequency spectrum of a link is divided up among +the connections established across the link. Specifically, the link +dedicates a frequency band to each connection for the duration of the +connection. In telephone networks, this frequency band typically has a +width of 4 kHz (that is, 4,000 hertz or 4,000 cycles per second). The +width of the band is called, not surprisingly, the bandwidth. FM radio +stations also use FDM to share the frequency spectrum between 88 MHz and +108 MHz, with each station being allocated a specific frequency band. +For a TDM link, time is divided into frames of fixed duration, and each +frame is divided into a fixed number of time slots. When the network +establishes a connection across a link, the network dedicates one time +slot in every frame to this connection. These slots are dedicated for +the sole use of that connection, with one time slot available for use +(in every frame) to transmit the connection's data. + + Figure 1.14 With FDM, each circuit continuously gets a fraction of the +bandwidth. With TDM, each circuit gets all of the bandwidth periodically +during brief intervals of time (that is, during slots) + +Figure 1.14 illustrates FDM and TDM for a specific network link +supporting up to four circuits. For FDM, the frequency domain is +segmented into four bands, each of bandwidth 4 kHz. For TDM, the time +domain is segmented into frames, with four time slots in each frame; +each circuit is assigned the same dedicated slot in the revolving TDM +frames. For TDM, the transmission rate of a circuit is equal to the +frame rate multiplied by the number of bits in a slot. For example, if +the link transmits 8,000 frames per second and each slot consists of 8 +bits, then the transmission rate of each circuit is 64 kbps. Proponents +of packet switching have always argued that circuit switching is +wasteful because the dedicated circuits are idle during silent periods. +For example, when one person in a telephone call stops talking, the idle +network resources (frequency bands or time slots in the links along the +connection's route) cannot be used by other ongoing connections. As +another example of how these resources can be underutilized, consider a +radiologist who uses a circuit-switched network to remotely access a +series of x-rays. The radiologist sets up a connection, requests an +image, contemplates the image, and then requests a new image. Network +resources are allocated to the connection but are not used (i.e., are +wasted) during the radiologist's contemplation periods. Proponents of +packet switching also enjoy pointing out that establishing end-to-end +circuits and reserving end-to-end transmission capacity is complicated +and requires complex signaling software to coordinate the operation of +the switches along the end-to-end path. Before we finish our discussion +of circuit switching, let's work through a numerical example that should +shed further insight on the topic. Let us consider how long it takes to +send a file of 640,000 bits from Host A to Host B over a +circuit-switched network. Suppose that all links in the network use TDM +with 24 slots and have a bit rate of 1.536 Mbps. Also suppose that it +takes 500 msec to establish an end-to-end circuit before Host A can +begin to transmit the file. How long does it take to send the file? Each +circuit has a transmission rate of (1.536 Mbps)/24=64 kbps, so it takes +(640,000 bits)/(64 kbps)=10 seconds to transmit the file. To this 10 +seconds we add the circuit establishment time, giving 10.5 seconds to +send the file. Note that the transmission time is independent of the +number of links: The transmission time would be 10 seconds if the +end-to-end circuit passed through one link or a hundred links. (The +actual + + end-to-end delay also includes a propagation delay; see Section 1.4.) +Packet Switching Versus Circuit Switching Having described circuit +switching and packet switching, let us compare the two. Critics of +packet switching have often argued that packet switching is not suitable +for real-time services (for example, telephone calls and video +conference calls) because of its variable and unpredictable end-to-end +delays (due primarily to variable and unpredictable queuing delays). +Proponents of packet switching argue that (1) it offers better sharing +of transmission capacity than circuit switching and (2) it is simpler, +more efficient, and less costly to implement than circuit switching. An +interesting discussion of packet switching versus circuit switching is +\[Molinero-Fernandez 2002\]. Generally speaking, people who do not like +to hassle with restaurant reservations prefer packet switching to +circuit switching. Why is packet switching more efficient? Let's look at +a simple example. Suppose users share a 1 Mbps link. Also suppose that +each user alternates between periods of activity, when a user generates +data at a constant rate of 100 kbps, and periods of inactivity, when a +user generates no data. Suppose further that a user is active only 10 +percent of the time (and is idly drinking coffee during the remaining 90 +percent of the time). With circuit switching, 100 kbps must be reserved +for each user at all times. For example, with circuit-switched TDM, if a +one-second frame is divided into 10 time slots of 100 ms each, then each +user would be allocated one time slot per frame. Thus, the +circuit-switched link can support only 10(=1 Mbps/100 kbps) simultaneous +users. With packet switching, the probability that a specific user is +active is 0.1 (that is, 10 percent). If there are 35 users, the +probability that there are 11 or more simultaneously active users is +approximately 0.0004. (Homework Problem P8 outlines how this probability +is obtained.) When there are 10 or fewer simultaneously active users +(which happens with probability 0.9996), the aggregate arrival rate of +data is less than or equal to 1 Mbps, the output rate of the link. Thus, +when there are 10 or fewer active users, users' packets flow through the +link essentially without delay, as is the case with circuit switching. +When there are more than 10 simultaneously active users, then the +aggregate arrival rate of packets exceeds the output capacity of the +link, and the output queue will begin to grow. (It continues to grow +until the aggregate input rate falls back below 1 Mbps, at which point +the queue will begin to diminish in length.) Because the probability of +having more than 10 simultaneously active users is minuscule in this +example, packet switching provides essentially the same performance as +circuit switching, but does so while allowing for more than three times +the number of users. Let's now consider a second simple example. Suppose +there are 10 users and that one user suddenly generates one thousand +1,000-bit packets, while other users remain quiescent and do not +generate packets. Under TDM circuit switching with 10 slots per frame +and each slot consisting of 1,000 bits, the active user can only use its +one time slot per frame to transmit data, while the remaining nine time +slots in each frame remain idle. It will be 10 seconds before all of the +active user's one million bits of data has + + been transmitted. In the case of packet switching, the active user can +continuously send its packets at the full link rate of 1 Mbps, since +there are no other users generating packets that need to be multiplexed +with the active user's packets. In this case, all of the active user's +data will be transmitted within 1 second. The above examples illustrate +two ways in which the performance of packet switching can be superior to +that of circuit switching. They also highlight the crucial difference +between the two forms of sharing a link's transmission rate among +multiple data streams. Circuit switching pre-allocates use of the +transmission link regardless of demand, with allocated but unneeded link +time going unused. Packet switching on the other hand allocates link use +on demand. Link transmission capacity will be shared on a +packet-by-packet basis only among those users who have packets that need +to be transmitted over the link. Although packet switching and circuit +switching are both prevalent in today's telecommunication networks, the +trend has certainly been in the direction of packet switching. Even many +of today's circuitswitched telephone networks are slowly migrating +toward packet switching. In particular, telephone networks often use +packet switching for the expensive overseas portion of a telephone call. + +1.3.3 A Network of Networks We saw earlier that end systems (PCs, +smartphones, Web servers, mail servers, and so on) connect into the +Internet via an access ISP. The access ISP can provide either wired or +wireless connectivity, using an array of access technologies including +DSL, cable, FTTH, Wi-Fi, and cellular. Note that the access ISP does not +have to be a telco or a cable company; instead it can be, for example, a +university (providing Internet access to students, staff, and faculty), +or a company (providing access for its employees). But connecting end +users and content providers into an access ISP is only a small piece of +solving the puzzle of connecting the billions of end systems that make +up the Internet. To complete this puzzle, the access ISPs themselves +must be interconnected. This is done by creating a network of +networks---understanding this phrase is the key to understanding the +Internet. Over the years, the network of networks that forms the +Internet has evolved into a very complex structure. Much of this +evolution is driven by economics and national policy, rather than by +performance considerations. In order to understand today's Internet +network structure, let's incrementally build a series of network +structures, with each new structure being a better approximation of the +complex Internet that we have today. Recall that the overarching goal is +to interconnect the access ISPs so that all end systems can send packets +to each other. One naive approach would be to have each access ISP +directly connect with every other access ISP. Such a mesh design is, of +course, much too costly for the access ISPs, as it would require each +access ISP to have a separate communication link to each of the hundreds +of thousands of other access ISPs all over the world. + + Our first network structure, Network Structure 1, interconnects all of +the access ISPs with a single global transit ISP. Our (imaginary) global +transit ISP is a network of routers and communication links that not +only spans the globe, but also has at least one router near each of the +hundreds of thousands of access ISPs. Of course, it would be very costly +for the global ISP to build such an extensive network. To be profitable, +it would naturally charge each of the access ISPs for connectivity, with +the pricing reflecting (but not necessarily directly proportional to) +the amount of traffic an access ISP exchanges with the global ISP. Since +the access ISP pays the global transit ISP, the access ISP is said to be +a customer and the global transit ISP is said to be a provider. Now if +some company builds and operates a global transit ISP that is +profitable, then it is natural for other companies to build their own +global transit ISPs and compete with the original global transit ISP. +This leads to Network Structure 2, which consists of the hundreds of +thousands of access ISPs and multiple global transit ISPs. The access +ISPs certainly prefer Network Structure 2 over Network Structure 1 since +they can now choose among the competing global transit providers as a +function of their pricing and services. Note, however, that the global +transit ISPs themselves must interconnect: Otherwise access ISPs +connected to one of the global transit providers would not be able to +communicate with access ISPs connected to the other global transit +providers. Network Structure 2, just described, is a two-tier hierarchy +with global transit providers residing at the top tier and access ISPs +at the bottom tier. This assumes that global transit ISPs are not only +capable of getting close to each and every access ISP, but also find it +economically desirable to do so. In reality, although some ISPs do have +impressive global coverage and do directly connect with many access +ISPs, no ISP has presence in each and every city in the world. Instead, +in any given region, there may be a regional ISP to which the access +ISPs in the region connect. Each regional ISP then connects to tier-1 +ISPs. Tier-1 ISPs are similar to our (imaginary) global transit ISP; but +tier-1 ISPs, which actually do exist, do not have a presence in every +city in the world. There are approximately a dozen tier-1 ISPs, +including Level 3 Communications, AT&T, Sprint, and NTT. Interestingly, +no group officially sanctions tier-1 status; as the saying goes---if you +have to ask if you're a member of a group, you're probably not. +Returning to this network of networks, not only are there multiple +competing tier-1 ISPs, there may be multiple competing regional ISPs in +a region. In such a hierarchy, each access ISP pays the regional ISP to +which it connects, and each regional ISP pays the tier-1 ISP to which it +connects. (An access ISP can also connect directly to a tier-1 ISP, in +which case it pays the tier-1 ISP). Thus, there is customerprovider +relationship at each level of the hierarchy. Note that the tier-1 ISPs +do not pay anyone as they are at the top of the hierarchy. To further +complicate matters, in some regions, there may be a larger regional ISP +(possibly spanning an entire country) to which the smaller regional ISPs +in that region connect; the larger regional ISP then connects to a +tier-1 ISP. For example, in China, there are access ISPs in each city, +which connect to provincial ISPs, which in turn connect to national +ISPs, which finally connect to tier-1 ISPs \[Tian 2012\]. We refer to +this multi-tier hierarchy, which is still only a crude + + approximation of today's Internet, as Network Structure 3. To build a +network that more closely resembles today's Internet, we must add points +of presence (PoPs), multi-homing, peering, and Internet exchange points +(IXPs) to the hierarchical Network Structure 3. PoPs exist in all levels +of the hierarchy, except for the bottom (access ISP) level. A PoP is +simply a group of one or more routers (at the same location) in the +provider's network where customer ISPs can connect into the provider +ISP. For a customer network to connect to a provider's PoP, it can lease +a high-speed link from a third-party telecommunications provider to +directly connect one of its routers to a router at the PoP. Any ISP +(except for tier-1 ISPs) may choose to multi-home, that is, to connect +to two or more provider ISPs. So, for example, an access ISP may +multi-home with two regional ISPs, or it may multi-home with two +regional ISPs and also with a tier-1 ISP. Similarly, a regional ISP may +multi-home with multiple tier-1 ISPs. When an ISP multi-homes, it can +continue to send and receive packets into the Internet even if one of +its providers has a failure. As we just learned, customer ISPs pay their +provider ISPs to obtain global Internet interconnectivity. The amount +that a customer ISP pays a provider ISP reflects the amount of traffic +it exchanges with the provider. To reduce these costs, a pair of nearby +ISPs at the same level of the hierarchy can peer, that is, they can +directly connect their networks together so that all the traffic between +them passes over the direct connection rather than through upstream +intermediaries. When two ISPs peer, it is typically settlement-free, +that is, neither ISP pays the other. As noted earlier, tier-1 ISPs also +peer with one another, settlement-free. For a readable discussion of +peering and customer-provider relationships, see \[Van der Berg 2008\]. +Along these same lines, a third-party company can create an Internet +Exchange Point (IXP), which is a meeting point where multiple ISPs can +peer together. An IXP is typically in a stand-alone building with its +own switches \[Ager 2012\]. There are over 400 IXPs in the Internet +today \[IXP List 2016\]. We refer to this ecosystem---consisting of +access ISPs, regional ISPs, tier-1 ISPs, PoPs, multi-homing, peering, +and IXPs---as Network Structure 4. We now finally arrive at Network +Structure 5, which describes today's Internet. Network Structure 5, +illustrated in Figure 1.15, builds on top of Network Structure 4 by +adding content-provider networks. Google is currently one of the leading +examples of such a content-provider network. As of this writing, it is +estimated that Google has 50--100 data centers distributed across North +America, Europe, Asia, South America, and Australia. Some of these data +centers house over one hundred thousand servers, while other data +centers are smaller, housing only hundreds of servers. The Google data +centers are all interconnected via Google's private TCP/IP network, +which spans the entire globe but is nevertheless separate from the +public Internet. Importantly, the Google private network only carries +traffic to/from Google servers. As shown in Figure 1.15, the Google +private network attempts to "bypass" the upper tiers of the Internet by +peering (settlement free) with lower-tier ISPs, either by directly +connecting with them or by connecting with them at IXPs \[Labovitz +2010\]. However, because many access ISPs can still only be reached by +transiting through tier-1 networks, the Google network also connects to +tier-1 ISPs, and pays those ISPs for the traffic it exchanges with them. +By creating its own network, a content + + provider not only reduces its payments to upper-tier ISPs, but also has +greater control of how its services are ultimately delivered to end +users. Google's network infrastructure is described in greater detail in +Section 2.6. In summary, today's Internet---a network of networks---is +complex, consisting of a dozen or so tier-1 ISPs and hundreds of +thousands of lower-tier ISPs. The ISPs are diverse in their coverage, +with some spanning multiple continents and oceans, and others limited to +narrow geographic regions. The lowertier ISPs connect to the higher-tier +ISPs, and the higher-tier ISPs interconnect with one another. Users and +content providers are customers of lower-tier ISPs, and lower-tier ISPs +are customers of higher-tier ISPs. In recent years, major content +providers have also created their own networks and connect directly into +lower-tier ISPs where possible. + +Figure 1.15 Interconnection of ISPs + + 1.4 Delay, Loss, and Throughput in Packet-Switched Networks Back in +Section 1.1 we said that the Internet can be viewed as an infrastructure +that provides services to distributed applications running on end +systems. Ideally, we would like Internet services to be able to move as +much data as we want between any two end systems, instantaneously, +without any loss of data. Alas, this is a lofty goal, one that is +unachievable in reality. Instead, computer networks necessarily +constrain throughput (the amount of data per second that can be +transferred) between end systems, introduce delays between end systems, +and can actually lose packets. On one hand, it is unfortunate that the +physical laws of reality introduce delay and loss as well as constrain +throughput. On the other hand, because computer networks have these +problems, there are many fascinating issues surrounding how to deal with +the problems---more than enough issues to fill a course on computer +networking and to motivate thousands of PhD theses! In this section, +we'll begin to examine and quantify delay, loss, and throughput in +computer networks. + +1.4.1 Overview of Delay in Packet-Switched Networks Recall that a packet +starts in a host (the source), passes through a series of routers, and +ends its journey in another host (the destination). As a packet travels +from one node (host or router) to the subsequent node (host or router) +along this path, the packet suffers from several types of delays at each +node along the path. The most important of these delays are the nodal +processing delay, queuing delay, transmission delay, and propagation +delay; together, these delays accumulate to give a total nodal delay. +The performance of many Internet applications---such as search, Web +browsing, e-mail, maps, instant messaging, and voice-over-IP---are +greatly affected by network delays. In order to acquire a deep +understanding of packet switching and computer networks, we must +understand the nature and importance of these delays. Types of Delay +Let's explore these delays in the context of Figure 1.16. As part of its +end-to-end route between source and destination, a packet is sent from +the upstream node through router A to router B. Our goal is to +characterize the nodal delay at router A. Note that router A has an +outbound link leading to router B. This link is preceded by a queue +(also known as a buffer). When the packet arrives at router A from the +upstream node, router A examines the packet's header to determine the +appropriate outbound link for the packet and then directs the packet to +this link. In this example, the outbound link for the packet is the one +that leads to router B. A packet can be transmitted on a link only if +there is no other packet currently + + being transmitted on the link and if there are no other packets +preceding it in the queue; if the link is + +Figure 1.16 The nodal delay at router A + +currently busy or if there are other packets already queued for the +link, the newly arriving packet will then join the queue. Processing +Delay The time required to examine the packet's header and determine +where to direct the packet is part of the processing delay. The +processing delay can also include other factors, such as the time needed +to check for bit-level errors in the packet that occurred in +transmitting the packet's bits from the upstream node to router A. +Processing delays in high-speed routers are typically on the order of +microseconds or less. After this nodal processing, the router directs +the packet to the queue that precedes the link to router B. (In Chapter +4 we'll study the details of how a router operates.) Queuing Delay At +the queue, the packet experiences a queuing delay as it waits to be +transmitted onto the link. The length of the queuing delay of a specific +packet will depend on the number of earlier-arriving packets that are +queued and waiting for transmission onto the link. If the queue is empty +and no other packet is currently being transmitted, then our packet's +queuing delay will be zero. On the other hand, if the traffic is heavy +and many other packets are also waiting to be transmitted, the queuing +delay will be long. We will see shortly that the number of packets that +an arriving packet might expect to find is a function of the intensity +and nature of the traffic arriving at the queue. Queuing delays can be +on the order of microseconds to milliseconds in practice. Transmission +Delay Assuming that packets are transmitted in a first-come-first-served +manner, as is common in packetswitched networks, our packet can be +transmitted only after all the packets that have arrived before it have +been transmitted. Denote the length of the packet by L bits, and denote +the transmission rate of + + the link from router A to router B by R bits/sec. For example, for a 10 +Mbps Ethernet link, the rate is R=10 Mbps; for a 100 Mbps Ethernet link, +the rate is R=100 Mbps. The transmission delay is L/R. This is the +amount of time required to push (that is, transmit) all of the packet's +bits into the link. Transmission delays are typically on the order of +microseconds to milliseconds in practice. Propagation Delay Once a bit +is pushed into the link, it needs to propagate to router B. The time +required to propagate from the beginning of the link to router B is the +propagation delay. The bit propagates at the propagation speed of the +link. The propagation speed depends on the physical medium of the link +(that is, fiber optics, twisted-pair copper wire, and so on) and is in +the range of 2⋅108 meters/sec to 3⋅108 meters/sec which is equal to, or +a little less than, the speed of light. The propagation delay is the +distance between two routers divided by the propagation speed. That is, +the propagation delay is d/s, where d is the distance between router A +and router B and s is the propagation speed of the link. Once the last +bit of the packet propagates to node B, it and all the preceding bits of +the packet are stored in router B. The whole process then continues with +router B now performing the forwarding. In wide-area networks, +propagation delays are on the order of milliseconds. Comparing +Transmission and Propagation Delay + +Exploring propagation delay and transmission delay + +Newcomers to the field of computer networking sometimes have difficulty +understanding the difference between transmission delay and propagation +delay. The difference is subtle but important. The transmission delay is +the amount of time required for the router to push out the packet; it is +a function of the packet's length and the transmission rate of the link, +but has nothing to do with the distance between the two routers. The +propagation delay, on the other hand, is the time it takes a bit to +propagate from one router to the next; it is a function of the distance +between the two routers, but has nothing to do with the packet's length +or the transmission rate of the link. An analogy might clarify the +notions of transmission and propagation delay. Consider a highway that +has a tollbooth every 100 kilometers, as shown in Figure 1.17. You can +think of the highway segments + + between tollbooths as links and the tollbooths as routers. Suppose that +cars travel (that is, propagate) on the highway at a rate of 100 km/hour +(that is, when a car leaves a tollbooth, it instantaneously accelerates +to 100 km/hour and maintains that speed between tollbooths). Suppose +next that 10 cars, traveling together as a caravan, follow each other in +a fixed order. You can think of each car as a bit and the caravan as a +packet. Also suppose that each + +Figure 1.17 Caravan analogy + +tollbooth services (that is, transmits) a car at a rate of one car per +12 seconds, and that it is late at night so that the caravan's cars are +the only cars on the highway. Finally, suppose that whenever the first +car of the caravan arrives at a tollbooth, it waits at the entrance +until the other nine cars have arrived and lined up behind it. (Thus the +entire caravan must be stored at the tollbooth before it can begin to be +forwarded.) The time required for the tollbooth to push the entire +caravan onto the highway is (10 cars)/(5 cars/minute)=2 minutes. This +time is analogous to the transmission delay in a router. The time +required for a car to travel from the exit of one tollbooth to the next +tollbooth is 100 km/(100 km/hour)=1 hour. This time is analogous to +propagation delay. Therefore, the time from when the caravan is stored +in front of a tollbooth until the caravan is stored in front of the next +tollbooth is the sum of transmission delay and propagation delay---in +this example, 62 minutes. Let's explore this analogy a bit more. What +would happen if the tollbooth service time for a caravan were greater +than the time for a car to travel between tollbooths? For example, +suppose now that the cars travel at the rate of 1,000 km/hour and the +tollbooth services cars at the rate of one car per minute. Then the +traveling delay between two tollbooths is 6 minutes and the time to +serve a caravan is 10 minutes. In this case, the first few cars in the +caravan will arrive at the second tollbooth before the last cars in the +caravan leave the first tollbooth. This situation also arises in +packet-switched networks---the first bits in a packet can arrive at a +router while many of the remaining bits in the packet are still waiting +to be transmitted by the preceding router. If a picture speaks a +thousand words, then an animation must speak a million words. The Web +site for this textbook provides an interactive Java applet that nicely +illustrates and contrasts transmission delay and propagation delay. The +reader is highly encouraged to visit that applet. \[Smith 2009\] also +provides a very readable discussion of propagation, queueing, and +transmission delays. If we let dproc, dqueue, dtrans, and dprop denote +the processing, queuing, transmission, and propagation + + delays, then the total nodal delay is given by +dnodal=dproc+dqueue+dtrans+dprop The contribution of these delay +components can vary significantly. For example, dprop can be negligible +(for example, a couple of microseconds) for a link connecting two +routers on the same university campus; however, dprop is hundreds of +milliseconds for two routers interconnected by a geostationary satellite +link, and can be the dominant term in dnodal. Similarly, dtrans can +range from negligible to significant. Its contribution is typically +negligible for transmission rates of 10 Mbps and higher (for example, +for LANs); however, it can be hundreds of milliseconds for large +Internet packets sent over low-speed dial-up modem links. The processing +delay, dproc, is often negligible; however, it strongly influences a +router's maximum throughput, which is the maximum rate at which a router +can forward packets. + +1.4.2 Queuing Delay and Packet Loss The most complicated and interesting +component of nodal delay is the queuing delay, dqueue. In fact, queuing +delay is so important and interesting in computer networking that +thousands of papers and numerous books have been written about it +\[Bertsekas 1991; Daigle 1991; Kleinrock 1975, Kleinrock 1976; Ross +1995\]. We give only a high-level, intuitive discussion of queuing delay +here; the more curious reader may want to browse through some of the +books (or even eventually write a PhD thesis on the subject!). Unlike +the other three delays (namely, dproc, dtrans, and dprop), the queuing +delay can vary from packet to packet. For example, if 10 packets arrive +at an empty queue at the same time, the first packet transmitted will +suffer no queuing delay, while the last packet transmitted will suffer a +relatively large queuing delay (while it waits for the other nine +packets to be transmitted). Therefore, when characterizing queuing +delay, one typically uses statistical measures, such as average queuing +delay, variance of queuing delay, and the probability that the queuing +delay exceeds some specified value. When is the queuing delay large and +when is it insignificant? The answer to this question depends on the +rate at which traffic arrives at the queue, the transmission rate of the +link, and the nature of the arriving traffic, that is, whether the +traffic arrives periodically or arrives in bursts. To gain some insight +here, let a denote the average rate at which packets arrive at the queue +(a is in units of packets/sec). Recall that R is the transmission rate; +that is, it is the rate (in bits/sec) at which bits are pushed out of +the queue. Also suppose, for simplicity, that all packets consist of L +bits. Then the average rate at which bits arrive at the queue is La +bits/sec. Finally, assume that the queue is very big, so that it can +hold essentially an infinite number of bits. The ratio La/R, called the +traffic intensity, often plays an important role in estimating the +extent of the queuing delay. If La/R \> 1, then the average rate at +which bits arrive at the queue exceeds the rate at which the bits can be +transmitted from the queue. In this + + unfortunate situation, the queue will tend to increase without bound and +the queuing delay will approach infinity! Therefore, one of the golden +rules in traffic engineering is: Design your system so that the traffic +intensity is no greater than 1. Now consider the case La/R ≤ 1. Here, +the nature of the arriving traffic impacts the queuing delay. For +example, if packets arrive periodically---that is, one packet arrives +every L/R seconds---then every packet will arrive at an empty queue and +there will be no queuing delay. On the other hand, if packets arrive in +bursts but periodically, there can be a significant average queuing +delay. For example, suppose N packets arrive simultaneously every (L/R)N +seconds. Then the first packet transmitted has no queuing delay; the +second packet transmitted has a queuing delay of L/R seconds; and more +generally, the nth packet transmitted has a queuing delay of (n−1)L/R +seconds. We leave it as an exercise for you to calculate the average +queuing delay in this example. The two examples of periodic arrivals +described above are a bit academic. Typically, the arrival process to a +queue is random; that is, the arrivals do not follow any pattern and the +packets are spaced apart by random amounts of time. In this more +realistic case, the quantity La/R is not usually sufficient to fully +characterize the queuing delay statistics. Nonetheless, it is useful in +gaining an intuitive understanding of the extent of the queuing delay. +In particular, if the traffic intensity is close to zero, then packet +arrivals are few and far between and it is unlikely that an arriving +packet will find another packet in the queue. Hence, the average queuing +delay will be close to zero. On the other hand, when the traffic +intensity is close to 1, there will be intervals of time when the +arrival rate exceeds the transmission capacity (due to variations in +packet arrival rate), and a queue will form during these periods of +time; when the arrival rate is less than the transmission capacity, the +length of the queue will shrink. Nonetheless, as the traffic intensity +approaches 1, the average queue length gets larger and larger. The +qualitative dependence of average queuing delay on the traffic intensity +is shown in Figure 1.18. One important aspect of Figure 1.18 is the fact +that as the traffic intensity approaches 1, the average queuing delay +increases rapidly. A small percentage increase in the intensity will +result in a much larger percentage-wise increase in delay. Perhaps you +have experienced this phenomenon on the highway. If you regularly drive +on a road that is typically congested, the fact that the road is +typically + + Figure 1.18 Dependence of average queuing delay on traffic intensity + +congested means that its traffic intensity is close to 1. If some event +causes an even slightly larger-thanusual amount of traffic, the delays +you experience can be huge. To really get a good feel for what queuing +delays are about, you are encouraged once again to visit the textbook +Web site, which provides an interactive Java applet for a queue. If you +set the packet arrival rate high enough so that the traffic intensity +exceeds 1, you will see the queue slowly build up over time. Packet Loss +In our discussions above, we have assumed that the queue is capable of +holding an infinite number of packets. In reality a queue preceding a +link has finite capacity, although the queuing capacity greatly depends +on the router design and cost. Because the queue capacity is finite, +packet delays do not really approach infinity as the traffic intensity +approaches 1. Instead, a packet can arrive to find a full queue. With no +place to store such a packet, a router will drop that packet; that is, +the packet will be lost. This overflow at a queue can again be seen in +the Java applet for a queue when the traffic intensity is greater +than 1. From an end-system viewpoint, a packet loss will look like a +packet having been transmitted into the network core but never emerging +from the network at the destination. The fraction of lost packets +increases as the traffic intensity increases. Therefore, performance at +a node is often measured not only in terms of delay, but also in terms +of the probability of packet loss. As we'll discuss in the subsequent +chapters, a lost packet may be retransmitted on an end-to-end basis in +order to ensure that all data are eventually transferred from source to +destination. + +1.4.3 End-to-End Delay + + Our discussion up to this point has focused on the nodal delay, that is, +the delay at a single router. Let's now consider the total delay from +source to destination. To get a handle on this concept, suppose there +are N−1 routers between the source host and the destination host. Let's +also suppose for the moment that the network is uncongested (so that +queuing delays are negligible), the processing delay at each router and +at the source host is dproc, the transmission rate out of each router +and out of the source host is R bits/sec, and the propagation on each +link is dprop. The nodal delays accumulate and give an end-toend delay, +dend−end=N(dproc+dtrans+dprop) + +(1.2) + +where, once again, dtrans=L/R, where L is the packet size. Note that +Equation 1.2 is a generalization of Equation 1.1, which did not take +into account processing and propagation delays. We leave it to you to +generalize Equation 1.2 to the case of heterogeneous delays at the nodes +and to the presence of an average queuing delay at each node. Traceroute + +Using Traceroute to discover network paths and measure network delay + +To get a hands-on feel for end-to-end delay in a computer network, we +can make use of the Traceroute program. Traceroute is a simple program +that can run in any Internet host. When the user specifies a destination +hostname, the program in the source host sends multiple, special packets +toward that destination. As these packets work their way toward the +destination, they pass through a series of routers. When a router +receives one of these special packets, it sends back to the source a +short message that contains the name and address of the router. More +specifically, suppose there are N−1 routers between the source and the +destination. Then the source will send N special packets into the +network, with each packet addressed to the ultimate destination. These N +special packets are marked 1 through N, with the first packet marked 1 +and the last packet marked N. When the nth router receives the nth +packet marked n, the router does not forward the packet toward its +destination, but instead sends a message back to the source. When the +destination host receives the Nth packet, it too returns a message back +to the source. The source records the time that elapses between when it +sends a packet and when it receives the corresponding + + return message; it also records the name and address of the router (or +the destination host) that returns the message. In this manner, the +source can reconstruct the route taken by packets flowing from source to +destination, and the source can determine the round-trip delays to all +the intervening routers. Traceroute actually repeats the experiment just +described three times, so the source actually sends 3 • N packets to the +destination. RFC 1393 describes Traceroute in detail. Here is an example +of the output of the Traceroute program, where the route was being +traced from the source host gaia.cs.umass.edu (at the University of +Massachusetts) to the host cis.poly.edu (at Polytechnic University in +Brooklyn). The output has six columns: the first column is the n value +described above, that is, the number of the router along the route; the +second column is the name of the router; the third column is the address +of the router (of the form xxx.xxx.xxx.xxx); the last three columns are +the round-trip delays for three experiments. If the source receives +fewer than three messages from any given router (due to packet loss in +the network), Traceroute places an asterisk just after the router number +and reports fewer than three round-trip times for that router. + +1 + +cs-gw (128.119.240.254) 1.009 ms 0.899 ms 0.993 ms + +2 + +128.119.3.154 (128.119.3.154) 0.931 ms 0.441 ms 0.651 ms + +3 + +-border4-rt-gi-1-3.gw.umass.edu (128.119.2.194) 1.032 ms 0.484 ms + +0.451 ms 4 + +-acr1-ge-2-1-0.Boston.cw.net (208.172.51.129) 10.006 ms 8.150 ms 8.460 + +ms 5 + +-agr4-loopback.NewYork.cw.net (206.24.194.104) 12.272 ms 14.344 ms + +13.267 ms 6 + +-acr2-loopback.NewYork.cw.net (206.24.194.62) 13.225 ms 12.292 ms + +12.148 ms 7 + +-pos10-2.core2.NewYork1.Level3.net (209.244.160.133) 12.218 ms 11.823 + +ms 11.793 ms 8 + +-gige9-1-52.hsipaccess1.NewYork1.Level3.net (64.159.17.39) 13.081 ms + +11.556 ms 13.297 ms 9 + +-p0-0.polyu.bbnplanet.net (4.25.109.122) 12.716 ms 13.052 ms 12.786 ms + +10 cis.poly.edu (128.238.32.126) 14.080 ms 13.035 ms 12.802 ms + +In the trace above there are nine routers between the source and the +destination. Most of these routers have a name, and all of them have +addresses. For example, the name of Router 3 is +border4-rt-gi1-3.gw.umass.edu and its address is 128.119.2.194 . Looking +at the data provided for this same router, we see that in the first of +the three trials the round-trip delay between the source and the router +was 1.03 msec. The round-trip delays for the subsequent two trials were +0.48 and 0.45 msec. These + + round-trip delays include all of the delays just discussed, including +transmission delays, propagation delays, router processing delays, and +queuing delays. Because the queuing delay is varying with time, the +round-trip delay of packet n sent to a router n can sometimes be longer +than the round-trip delay of packet n+1 sent to router n+1. Indeed, we +observe this phenomenon in the above example: the delays to Router 6 are +larger than the delays to Router 7! Want to try out Traceroute for +yourself? We highly recommended that you visit http:// +www.traceroute.org, which provides a Web interface to an extensive list +of sources for route tracing. You choose a source and supply the +hostname for any destination. The Traceroute program then does all the +work. There are a number of free software programs that provide a +graphical interface to Traceroute; one of our favorites is PingPlotter +\[PingPlotter 2016\]. End System, Application, and Other Delays In +addition to processing, transmission, and propagation delays, there can +be additional significant delays in the end systems. For example, an end +system wanting to transmit a packet into a shared medium (e.g., as in a +WiFi or cable modem scenario) may purposefully delay its transmission as +part of its protocol for sharing the medium with other end systems; +we'll consider such protocols in detail in Chapter 6. Another important +delay is media packetization delay, which is present in Voice-over-IP +(VoIP) applications. In VoIP, the sending side must first fill a packet +with encoded digitized speech before passing the packet to the Internet. +This time to fill a packet---called the packetization delay---can be +significant and can impact the user-perceived quality of a VoIP call. +This issue will be further explored in a homework problem at the end of +this chapter. + +1.4.4 Throughput in Computer Networks In addition to delay and packet +loss, another critical performance measure in computer networks is +endto-end throughput. To define throughput, consider transferring a +large file from Host A to Host B across a computer network. This +transfer might be, for example, a large video clip from one peer to +another in a P2P file sharing system. The instantaneous throughput at +any instant of time is the rate (in bits/sec) at which Host B is +receiving the file. (Many applications, including many P2P file sharing +systems, display the instantaneous throughput during downloads in the +user interface---perhaps you have observed this before!) If the file +consists of F bits and the transfer takes T seconds for Host B to +receive all F bits, then the average throughput of the file transfer is +F/T bits/sec. For some applications, such as Internet telephony, it is +desirable to have a low delay and an instantaneous throughput +consistently above some threshold (for example, over 24 kbps for some +Internet telephony applications and over 256 kbps for some real-time +video applications). For other applications, including those involving +file transfers, delay is not critical, but it is desirable to have the +highest possible throughput. + + To gain further insight into the important concept of throughput, let's +consider a few examples. Figure 1.19(a) shows two end systems, a server +and a client, connected by two communication links and a router. +Consider the throughput for a file transfer from the server to the +client. Let Rs denote the rate of the link between the server and the +router; and Rc denote the rate of the link between the router and the +client. Suppose that the only bits being sent in the entire network are +those from the server to the client. We now ask, in this ideal scenario, +what is the server-to-client throughput? To answer this question, we may +think of bits as fluid and communication links as pipes. Clearly, the +server cannot pump bits through its link at a rate faster than Rs bps; +and the router cannot forward bits at a rate faster than Rc bps. If +Rs\<Rc, then the bits pumped by the server will "flow" right through the +router and arrive at the client at a rate of Rs bps, giving a throughput +of Rs bps. If, on the other hand, Rc\<Rs, then the router will not be +able to forward bits as quickly as it receives them. In this case, bits +will only leave the router at rate Rc, giving an end-to-end throughput +of Rc. (Note also that if bits continue to arrive at the router at rate +Rs, and continue to leave the router at Rc, the backlog of bits at the +router waiting + +Figure 1.19 Throughput for a file transfer from server to client + +for transmission to the client will grow and grow---a most undesirable +situation!) Thus, for this simple two-link network, the throughput is +min{Rc, Rs}, that is, it is the transmission rate of the bottleneck +link. Having determined the throughput, we can now approximate the time +it takes to transfer a large file of F bits from server to client as +F/min{Rs, Rc}. For a specific example, suppose you are downloading an +MP3 file of F=32 million bits, the server has a transmission rate of +Rs=2 Mbps, and you have an access link of Rc=1 Mbps. The time needed to +transfer the file is then 32 seconds. Of course, these expressions for +throughput and transfer time are only approximations, as they do not +account for store-and-forward and processing delays as well as protocol +issues. Figure 1.19(b) now shows a network with N links between the +server and the client, with the transmission rates of the N links being +R1,R2,..., RN. Applying the same analysis as for the two-link network, +we find that the throughput for a file transfer from server to client is +min{R1,R2,..., RN}, which + + is once again the transmission rate of the bottleneck link along the +path between server and client. Now consider another example motivated +by today's Internet. Figure 1.20(a) shows two end systems, a server and +a client, connected to a computer network. Consider the throughput for a +file transfer from the server to the client. The server is connected to +the network with an access link of rate Rs and the client is connected +to the network with an access link of rate Rc. Now suppose that all the +links in the core of the communication network have very high +transmission rates, much higher than Rs and Rc. Indeed, today, the core +of the Internet is over-provisioned with high speed links that +experience little congestion. Also suppose that the only bits being sent +in the entire network are those from the server to the client. Because +the core of the computer network is like a wide pipe in this example, +the rate at which bits can flow from source to destination is again the +minimum of Rs and Rc, that is, throughput = min{Rs, Rc}. Therefore, the +constraining factor for throughput in today's Internet is typically the +access network. For a final example, consider Figure 1.20(b) in which +there are 10 servers and 10 clients connected to the core of the +computer network. In this example, there are 10 simultaneous downloads +taking place, involving 10 client-server pairs. Suppose that these 10 +downloads are the only traffic in the network at the current time. As +shown in the figure, there is a link in the core that is traversed by +all 10 downloads. Denote R for the transmission rate of this link R. +Let's suppose that all server access links have the same rate Rs, all +client access links have the same rate Rc, and the transmission rates of +all the links in the core---except the one common link of rate R---are +much larger than Rs, Rc, and R. Now we ask, what are the throughputs of +the downloads? Clearly, if the rate of the common link, R, is +large---say a hundred times larger than both Rs and Rc---then the +throughput for each download will once again be min{Rs, Rc}. But what if +the rate of the common link is of the same order as Rs and Rc? What will +the throughput be in this case? Let's take a look at a specific example. +Suppose Rs=2 Mbps, Rc=1 Mbps, R=5 Mbps, and the + + Figure 1.20 End-to-end throughput: (a) Client downloads a file from +server; (b) 10 clients downloading with 10 servers + +common link divides its transmission rate equally among the 10 +downloads. Then the bottleneck for each download is no longer in the +access network, but is now instead the shared link in the core, which +only provides each download with 500 kbps of throughput. Thus the +end-to-end throughput for each download is now reduced to 500 kbps. The +examples in Figure 1.19 and Figure 1.20(a) show that throughput depends +on the transmission rates of the links over which the data flows. We saw +that when there is no other intervening traffic, the throughput can +simply be approximated as the minimum transmission rate along the path +between source and destination. The example in Figure 1.20(b) shows that +more generally the throughput depends not only on the transmission rates +of the links along the path, but also on the intervening traffic. In +particular, a link with a high transmission rate may nonetheless be the +bottleneck link for a file transfer if many other data flows are also +passing through that link. We will examine throughput in computer +networks more closely in the homework problems and in the subsequent +chapters. + + 1.5 Protocol Layers and Their Service Models From our discussion thus +far, it is apparent that the Internet is an extremely complicated +system. We have seen that there are many pieces to the Internet: +numerous applications and protocols, various types of end systems, +packet switches, and various types of link-level media. Given this +enormous complexity, is there any hope of organizing a network +architecture, or at least our discussion of network architecture? +Fortunately, the answer to both questions is yes. + +1.5.1 Layered Architecture Before attempting to organize our thoughts on +Internet architecture, let's look for a human analogy. Actually, we deal +with complex systems all the time in our everyday life. Imagine if +someone asked you to describe, for example, the airline system. How +would you find the structure to describe this complex system that has +ticketing agents, baggage checkers, gate personnel, pilots, airplanes, +air traffic control, and a worldwide system for routing airplanes? One +way to describe this system might be to describe the series of actions +you take (or others take for you) when you fly on an airline. You +purchase your ticket, check your bags, go to the gate, and eventually +get loaded onto the plane. The plane takes off and is routed to its +destination. After your plane lands, you deplane at the gate and claim +your bags. If the trip was bad, you complain about the flight to the +ticket agent (getting nothing for your effort). This scenario is shown +in Figure 1.21. + +Figure 1.21 Taking an airplane trip: actions + + Figure 1.22 Horizontal layering of airline functionality + +Already, we can see some analogies here with computer networking: You +are being shipped from source to destination by the airline; a packet is +shipped from source host to destination host in the Internet. But this +is not quite the analogy we are after. We are looking for some structure +in Figure 1.21. Looking at Figure 1.21, we note that there is a +ticketing function at each end; there is also a baggage function for +already-ticketed passengers, and a gate function for already-ticketed +and already-baggagechecked passengers. For passengers who have made it +through the gate (that is, passengers who are already ticketed, +baggage-checked, and through the gate), there is a takeoff and landing +function, and while in flight, there is an airplane-routing function. +This suggests that we can look at the functionality in Figure 1.21 in a +horizontal manner, as shown in Figure 1.22. Figure 1.22 has divided the +airline functionality into layers, providing a framework in which we can +discuss airline travel. Note that each layer, combined with the layers +below it, implements some functionality, some service. At the ticketing +layer and below, airline-counter-to-airline-counter transfer of a person +is accomplished. At the baggage layer and below, +baggage-check-to-baggage-claim transfer of a person and bags is +accomplished. Note that the baggage layer provides this service only to +an already-ticketed person. At the gate layer, +departure-gate-to-arrival-gate transfer of a person and bags is +accomplished. At the takeoff/landing layer, runway-to-runway transfer of +people and their bags is accomplished. Each layer provides its service +by (1) performing certain actions within that layer (for example, at the +gate layer, loading and unloading people from an airplane) and by (2) +using the services of the layer directly below it (for example, in the +gate layer, using the runway-to-runway passenger transfer service of the +takeoff/landing layer). A layered architecture allows us to discuss a +well-defined, specific part of a large and complex system. This +simplification itself is of considerable value by providing modularity, +making it much easier to change the implementation of the service +provided by the layer. As long as the layer provides the same service to +the layer above it, and uses the same services from the layer below it, +the remainder of the system remains unchanged when a layer's +implementation is changed. (Note that changing the + + implementation of a service is very different from changing the service +itself!) For example, if the gate functions were changed (for instance, +to have people board and disembark by height), the remainder of the +airline system would remain unchanged since the gate layer still +provides the same function (loading and unloading people); it simply +implements that function in a different manner after the change. For +large and complex systems that are constantly being updated, the ability +to change the implementation of a service without affecting other +components of the system is another important advantage of layering. +Protocol Layering But enough about airlines. Let's now turn our +attention to network protocols. To provide structure to the design of +network protocols, network designers organize protocols---and the +network hardware and software that implement the protocols---in layers. +Each protocol belongs to one of the layers, just as each function in the +airline architecture in Figure 1.22 belonged to a layer. We are again +interested in the services that a layer offers to the layer above---the +so-called service model of a layer. Just as in the case of our airline +example, each layer provides its service by (1) performing certain +actions within that layer and by (2) using the services of the layer +directly below it. For example, the services provided by layer n may +include reliable delivery of messages from one edge of the network to +the other. This might be implemented by using an unreliable edge-to-edge +message delivery service of layer n−1, and adding layer n functionality +to detect and retransmit lost messages. A protocol layer can be +implemented in software, in hardware, or in a combination of the two. +Application-layer protocols---such as HTTP and SMTP---are almost always +implemented in software in the end systems; so are transport-layer +protocols. Because the physical layer and data link layers are +responsible for handling communication over a specific link, they are +typically implemented in a network interface card (for example, Ethernet +or WiFi interface cards) associated with a given link. The network layer +is often a mixed implementation of hardware and software. Also note that +just as the functions in the layered airline architecture were +distributed among the various airports and flight control centers that +make up the system, so too is a layer n protocol distributed among the +end systems, packet switches, and other components that make up the +network. That is, there's often a piece of a layer n protocol in each of +these network components. Protocol layering has conceptual and +structural advantages \[RFC 3439\]. As we have seen, layering provides a +structured way to discuss system components. Modularity makes it easier +to update system components. We mention, however, that some researchers +and networking engineers are vehemently opposed to layering \[Wakeman +1992\]. One potential drawback of layering is that one layer may +duplicate lower-layer functionality. For example, many protocol stacks +provide error recovery + + Figure 1.23 The Internet protocol stack (a) and OSI reference model (b) + +on both a per-link basis and an end-to-end basis. A second potential +drawback is that functionality at one layer may need information (for +example, a timestamp value) that is present only in another layer; this +violates the goal of separation of layers. When taken together, the +protocols of the various layers are called the protocol stack. The +Internet protocol stack consists of five layers: the physical, link, +network, transport, and application layers, as shown in Figure 1.23(a). +If you examine the Table of Contents, you will see that we have roughly +organized this book using the layers of the Internet protocol stack. We +take a top-down approach, first covering the application layer and then +proceeding downward. Application Layer The application layer is where +network applications and their application-layer protocols reside. The +Internet's application layer includes many protocols, such as the HTTP +protocol (which provides for Web document request and transfer), SMTP +(which provides for the transfer of e-mail messages), and FTP (which +provides for the transfer of files between two end systems). We'll see +that certain network functions, such as the translation of +human-friendly names for Internet end systems like www.ietf.org to a +32-bit network address, are also done with the help of a specific +application-layer protocol, namely, the domain name system (DNS). We'll +see in Chapter 2 that it is very easy to create and deploy our own new +application-layer protocols. An application-layer protocol is +distributed over multiple end systems, with the application in one end +system using the protocol to exchange packets of information with the +application in another end system. We'll refer to this packet of +information at the application layer as a message. Transport Layer + + The Internet's transport layer transports application-layer messages +between application endpoints. In the Internet there are two transport +protocols, TCP and UDP, either of which can transport applicationlayer +messages. TCP provides a connection-oriented service to its +applications. This service includes guaranteed delivery of +application-layer messages to the destination and flow control (that is, +sender/receiver speed matching). TCP also breaks long messages into +shorter segments and provides a congestion-control mechanism, so that a +source throttles its transmission rate when the network is congested. +The UDP protocol provides a connectionless service to its applications. +This is a no-frills service that provides no reliability, no flow +control, and no congestion control. In this book, we'll refer to a +transport-layer packet as a segment. Network Layer The Internet's +network layer is responsible for moving network-layer packets known as +datagrams from one host to another. The Internet transport-layer +protocol (TCP or UDP) in a source host passes a transport-layer segment +and a destination address to the network layer, just as you would give +the postal service a letter with a destination address. The network +layer then provides the service of delivering the segment to the +transport layer in the destination host. The Internet's network layer +includes the celebrated IP protocol, which defines the fields in the +datagram as well as how the end systems and routers act on these fields. +There is only one IP protocol, and all Internet components that have a +network layer must run the IP protocol. The Internet's network layer +also contains routing protocols that determine the routes that datagrams +take between sources and destinations. The Internet has many routing +protocols. As we saw in Section 1.3, the Internet is a network of +networks, and within a network, the network administrator can run any +routing protocol desired. Although the network layer contains both the +IP protocol and numerous routing protocols, it is often simply referred +to as the IP layer, reflecting the fact that IP is the glue that binds +the Internet together. Link Layer The Internet's network layer routes a +datagram through a series of routers between the source and destination. +To move a packet from one node (host or router) to the next node in the +route, the network layer relies on the services of the link layer. In +particular, at each node, the network layer passes the datagram down to +the link layer, which delivers the datagram to the next node along the +route. At this next node, the link layer passes the datagram up to the +network layer. The services provided by the link layer depend on the +specific link-layer protocol that is employed over the link. For +example, some link-layer protocols provide reliable delivery, from +transmitting node, over one link, to receiving node. Note that this +reliable delivery service is different from the reliable delivery +service of TCP, which provides reliable delivery from one end system to +another. Examples of link-layer + + protocols include Ethernet, WiFi, and the cable access network's DOCSIS +protocol. As datagrams typically need to traverse several links to +travel from source to destination, a datagram may be handled by +different link-layer protocols at different links along its route. For +example, a datagram may be handled by Ethernet on one link and by PPP on +the next link. The network layer will receive a different service from +each of the different link-layer protocols. In this book, we'll refer to +the link-layer packets as frames. Physical Layer While the job of the +link layer is to move entire frames from one network element to an +adjacent network element, the job of the physical layer is to move the +individual bits within the frame from one node to the next. The +protocols in this layer are again link dependent and further depend on +the actual transmission medium of the link (for example, twisted-pair +copper wire, single-mode fiber optics). For example, Ethernet has many +physical-layer protocols: one for twisted-pair copper wire, another for +coaxial cable, another for fiber, and so on. In each case, a bit is +moved across the link in a different way. The OSI Model Having discussed +the Internet protocol stack in detail, we should mention that it is not +the only protocol stack around. In particular, back in the late 1970s, +the International Organization for Standardization (ISO) proposed that +computer networks be organized around seven layers, called the Open +Systems Interconnection (OSI) model \[ISO 2016\]. The OSI model took +shape when the protocols that were to become the Internet protocols were +in their infancy, and were but one of many different protocol suites +under development; in fact, the inventors of the original OSI model +probably did not have the Internet in mind when creating it. +Nevertheless, beginning in the late 1970s, many training and university +courses picked up on the ISO mandate and organized courses around the +seven-layer model. Because of its early impact on networking education, +the seven-layer model continues to linger on in some networking +textbooks and training courses. The seven layers of the OSI reference +model, shown in Figure 1.23(b), are: application layer, presentation +layer, session layer, transport layer, network layer, data link layer, +and physical layer. The functionality of five of these layers is roughly +the same as their similarly named Internet counterparts. Thus, let's +consider the two additional layers present in the OSI reference +model---the presentation layer and the session layer. The role of the +presentation layer is to provide services that allow communicating +applications to interpret the meaning of data exchanged. These services +include data compression and data encryption (which are +self-explanatory) as well as data description (which frees the +applications from having to worry about the internal format in which +data are represented/stored---formats that may differ from one computer +to another). The session layer provides for delimiting and +synchronization of data exchange, including the means to build a +checkpointing and recovery scheme. + + The fact that the Internet lacks two layers found in the OSI reference +model poses a couple of interesting questions: Are the services provided +by these layers unimportant? What if an application needs one of these +services? The Internet's answer to both of these questions is the +same---it's up to the application developer. It's up to the application +developer to decide if a service is important, and if the service is +important, it's up to the application developer to build that +functionality into the application. + +1.5.2 Encapsulation Figure 1.24 shows the physical path that data takes +down a sending end system's protocol stack, up and down the protocol +stacks of an intervening link-layer switch + +Figure 1.24 Hosts, routers, and link-layer switches; each contains a +different set of layers, reflecting their differences in functionality + +and router, and then up the protocol stack at the receiving end system. +As we discuss later in this book, routers and link-layer switches are +both packet switches. Similar to end systems, routers and link-layer +switches organize their networking hardware and software into layers. +But routers and link-layer switches do not implement all of the layers +in the protocol stack; they typically implement only the bottom layers. +As shown in Figure 1.24, link-layer switches implement layers 1 and 2; +routers implement layers 1 through 3. This means, for example, that +Internet routers are capable of implementing the IP protocol (a layer 3 +protocol), while link-layer switches are not. We'll see later that + + while link-layer switches do not recognize IP addresses, they are +capable of recognizing layer 2 addresses, such as Ethernet addresses. +Note that hosts implement all five layers; this is consistent with the +view that the Internet architecture puts much of its complexity at the +edges of the network. Figure 1.24 also illustrates the important concept +of encapsulation. At the sending host, an application-layer message (M +in Figure 1.24) is passed to the transport layer. In the simplest case, +the transport layer takes the message and appends additional information +(so-called transport-layer header information, Ht in Figure 1.24) that +will be used by the receiver-side transport layer. The application-layer +message and the transport-layer header information together constitute +the transportlayer segment. The transport-layer segment thus +encapsulates the application-layer message. The added information might +include information allowing the receiver-side transport layer to +deliver the message up to the appropriate application, and +error-detection bits that allow the receiver to determine whether bits +in the message have been changed in route. The transport layer then +passes the segment to the network layer, which adds network-layer header +information (Hn in Figure 1.24) such as source and destination end +system addresses, creating a network-layer datagram. The datagram is +then passed to the link layer, which (of course!) will add its own +link-layer header information and create a link-layer frame. Thus, we +see that at each layer, a packet has two types of fields: header fields +and a payload field. The payload is typically a packet from the layer +above. A useful analogy here is the sending of an interoffice memo from +one corporate branch office to another via the public postal service. +Suppose Alice, who is in one branch office, wants to send a memo to Bob, +who is in another branch office. The memo is analogous to the +application-layer message. Alice puts the memo in an interoffice +envelope with Bob's name and department written on the front of the +envelope. The interoffice envelope is analogous to a transport-layer +segment---it contains header information (Bob's name and department +number) and it encapsulates the application-layer message (the memo). +When the sending branch-office mailroom receives the interoffice +envelope, it puts the interoffice envelope inside yet another envelope, +which is suitable for sending through the public postal service. The +sending mailroom also writes the postal address of the sending and +receiving branch offices on the postal envelope. Here, the postal +envelope is analogous to the datagram---it encapsulates the +transportlayer segment (the interoffice envelope), which encapsulates +the original message (the memo). The postal service delivers the postal +envelope to the receiving branch-office mailroom. There, the process of +de-encapsulation is begun. The mailroom extracts the interoffice memo +and forwards it to Bob. Finally, Bob opens the envelope and removes the +memo. The process of encapsulation can be more complex than that +described above. For example, a large message may be divided into +multiple transport-layer segments (which might themselves each be +divided into multiple network-layer datagrams). At the receiving end, +such a segment must then be reconstructed from its constituent +datagrams. + + 1.6 Networks Under Attack The Internet has become mission critical for +many institutions today, including large and small companies, +universities, and government agencies. Many individuals also rely on the +Internet for many of their professional, social, and personal +activities. Billions of "things," including wearables and home devices, +are currently being connected to the Internet. But behind all this +utility and excitement, there is a dark side, a side where "bad guys" +attempt to wreak havoc in our daily lives by damaging our +Internetconnected computers, violating our privacy, and rendering +inoperable the Internet services on which we depend. The field of +network security is about how the bad guys can attack computer networks +and about how we, soon-to-be experts in computer networking, can defend +networks against those attacks, or better yet, design new architectures +that are immune to such attacks in the first place. Given the frequency +and variety of existing attacks as well as the threat of new and more +destructive future attacks, network security has become a central topic +in the field of computer networking. One of the features of this +textbook is that it brings network security issues to the forefront. +Since we don't yet have expertise in computer networking and Internet +protocols, we'll begin here by surveying some of today's more prevalent +security-related problems. This will whet our appetite for more +substantial discussions in the upcoming chapters. So we begin here by +simply asking, what can go wrong? How are computer networks vulnerable? +What are some of the more prevalent types of attacks today? The Bad Guys +Can Put Malware into Your Host Via the Internet We attach devices to the +Internet because we want to receive/send data from/to the Internet. This +includes all kinds of good stuff, including Instagram posts, Internet +search results, streaming music, video conference calls, streaming +movies, and so on. But, unfortunately, along with all that good stuff +comes malicious stuff---collectively known as malware---that can also +enter and infect our devices. Once malware infects our device it can do +all kinds of devious things, including deleting our files and installing +spyware that collects our private information, such as social security +numbers, passwords, and keystrokes, and then sends this (over the +Internet, of course!) back to the bad guys. Our compromised host may +also be enrolled in a network of thousands of similarly compromised +devices, collectively known as a botnet, which the bad guys control and +leverage for spam e-mail distribution or distributed denial-of-service +attacks (soon to be discussed) against targeted hosts. + + Much of the malware out there today is self-replicating: once it infects +one host, from that host it seeks entry into other hosts over the +Internet, and from the newly infected hosts, it seeks entry into yet +more hosts. In this manner, self-replicating malware can spread +exponentially fast. Malware can spread in the form of a virus or a worm. +Viruses are malware that require some form of user interaction to infect +the user's device. The classic example is an e-mail attachment +containing malicious executable code. If a user receives and opens such +an attachment, the user inadvertently runs the malware on the device. +Typically, such e-mail viruses are self-replicating: once executed, the +virus may send an identical message with an identical malicious +attachment to, for example, every recipient in the user's address book. +Worms are malware that can enter a device without any explicit user +interaction. For example, a user may be running a vulnerable network +application to which an attacker can send malware. In some cases, +without any user intervention, the application may accept the malware +from the Internet and run it, creating a worm. The worm in the newly +infected device then scans the Internet, searching for other hosts +running the same vulnerable network application. When it finds other +vulnerable hosts, it sends a copy of itself to those hosts. Today, +malware, is pervasive and costly to defend against. As you work through +this textbook, we encourage you to think about the following question: +What can computer network designers do to defend Internet-attached +devices from malware attacks? The Bad Guys Can Attack Servers and +Network Infrastructure Another broad class of security threats are known +as denial-of-service (DoS) attacks. As the name suggests, a DoS attack +renders a network, host, or other piece of infrastructure unusable by +legitimate users. Web servers, e-mail servers, DNS servers (discussed in +Chapter 2), and institutional networks can all be subject to DoS +attacks. Internet DoS attacks are extremely common, with thousands of +DoS attacks occurring every year \[Moore 2001\]. The site Digital Attack +Map allows use to visualize the top daily DoS attacks worldwide \[DAM +2016\]. Most Internet DoS attacks fall into one of three categories: +Vulnerability attack. This involves sending a few well-crafted messages +to a vulnerable application or operating system running on a targeted +host. If the right sequence of packets is sent to a vulnerable +application or operating system, the service can stop or, worse, the +host can crash. Bandwidth flooding. The attacker sends a deluge of +packets to the targeted host---so many packets that the target's access +link becomes clogged, preventing legitimate packets from reaching the +server. Connection flooding. The attacker establishes a large number of +half-open or fully open TCP connections (TCP connections are discussed +in Chapter 3) at the target host. The host can become so bogged down +with these bogus connections that it stops accepting legitimate +connections. Let's now explore the bandwidth-flooding attack in more +detail. Recalling our delay and loss analysis discussion in Section +1.4.2, it's evident that if the server has an access rate of R bps, then +the attacker will need to send traffic at a rate of approximately R bps +to cause damage. If R is very large, a single attack source may not be +able to generate enough traffic to harm the server. Furthermore, if all +the + + traffic emanates from a single source, an upstream router may be able to +detect the attack and block all traffic from that source before the +traffic gets near the server. In a distributed DoS (DDoS) attack, +illustrated in Figure 1.25, the attacker controls multiple sources and +has each source blast traffic at the target. With this approach, the +aggregate traffic rate across all the controlled sources needs to be +approximately R to cripple the service. DDoS attacks leveraging botnets +with thousands of comprised hosts are a common occurrence today \[DAM +2016\]. DDos attacks are much harder to detect and defend against than a +DoS attack from a single host. We encourage you to consider the +following question as you work your way through this book: What can +computer network designers do to defend against DoS attacks? We will see +that different defenses are needed for the three types of DoS attacks. + +Figure 1.25 A distributed denial-of-service attack + +The Bad Guys Can Sniff Packets Many users today access the Internet via +wireless devices, such as WiFi-connected laptops or handheld devices +with cellular Internet connections (covered in Chapter 7). While +ubiquitous Internet access is extremely convenient and enables marvelous +new applications for mobile users, it also creates a major security +vulnerability---by placing a passive receiver in the vicinity of the +wireless transmitter, that receiver can obtain a copy of every packet +that is transmitted! These packets can contain all kinds of sensitive +information, including passwords, social security numbers, trade +secrets, and private personal messages. A passive receiver that records +a copy of every packet that flies by is called a packet sniffer. + + Sniffers can be deployed in wired environments as well. In wired +broadcast environments, as in many Ethernet LANs, a packet sniffer can +obtain copies of broadcast packets sent over the LAN. As described in +Section 1.2, cable access technologies also broadcast packets and are +thus vulnerable to sniffing. Furthermore, a bad guy who gains access to +an institution's access router or access link to the Internet may be +able to plant a sniffer that makes a copy of every packet going to/from +the organization. Sniffed packets can then be analyzed offline for +sensitive information. Packet-sniffing software is freely available at +various Web sites and as commercial products. Professors teaching a +networking course have been known to assign lab exercises that involve +writing a packetsniffing and application-layer data reconstruction +program. Indeed, the Wireshark \[Wireshark 2016\] labs associated with +this text (see the introductory Wireshark lab at the end of this +chapter) use exactly such a packet sniffer! Because packet sniffers are +passive---that is, they do not inject packets into the channel---they +are difficult to detect. So, when we send packets into a wireless +channel, we must accept the possibility that some bad guy may be +recording copies of our packets. As you may have guessed, some of the +best defenses against packet sniffing involve cryptography. We will +examine cryptography as it applies to network security in Chapter 8. The +Bad Guys Can Masquerade as Someone You Trust It is surprisingly easy +(you will have the knowledge to do so shortly as you proceed through +this text!) to create a packet with an arbitrary source address, packet +content, and destination address and then transmit this hand-crafted +packet into the Internet, which will dutifully forward the packet to its +destination. Imagine the unsuspecting receiver (say an Internet router) +who receives such a packet, takes the (false) source address as being +truthful, and then performs some command embedded in the packet's +contents (say modifies its forwarding table). The ability to inject +packets into the Internet with a false source address is known as IP +spoofing, and is but one of many ways in which one user can masquerade +as another user. To solve this problem, we will need end-point +authentication, that is, a mechanism that will allow us to determine +with certainty if a message originates from where we think it does. Once +again, we encourage you to think about how this can be done for network +applications and protocols as you progress through the chapters of this +book. We will explore mechanisms for end-point authentication in Chapter +8. In closing this section, it's worth considering how the Internet got +to be such an insecure place in the first place. The answer, in essence, +is that the Internet was originally designed to be that way, based on +the model of "a group of mutually trusting users attached to a +transparent network" \[Blumenthal 2001\]---a model in which (by +definition) there is no need for security. Many aspects of the original +Internet architecture deeply reflect this notion of mutual trust. For +example, the ability for one user to send a + + packet to any other user is the default rather than a requested/granted +capability, and user identity is taken at declared face value, rather +than being authenticated by default. But today's Internet certainly does +not involve "mutually trusting users." Nonetheless, today's users still +need to communicate when they don't necessarily trust each other, may +wish to communicate anonymously, may communicate indirectly through +third parties (e.g., Web caches, which we'll study in Chapter 2, or +mobility-assisting agents, which we'll study in Chapter 7), and may +distrust the hardware, software, and even the air through which they +communicate. We now have many security-related challenges before us as +we progress through this book: We should seek defenses against sniffing, +endpoint masquerading, man-in-the-middle attacks, DDoS attacks, malware, +and more. We should keep in mind that communication among mutually +trusted users is the exception rather than the rule. Welcome to the +world of modern computer networking! + + 1.7 History of Computer Networking and the Internet Sections 1.1 through +1.6 presented an overview of the technology of computer networking and +the Internet. You should know enough now to impress your family and +friends! However, if you really want to be a big hit at the next +cocktail party, you should sprinkle your discourse with tidbits about +the fascinating history of the Internet \[Segaller 1998\]. + +1.7.1 The Development of Packet Switching: 1961--1972 The field of +computer networking and today's Internet trace their beginnings back to +the early 1960s, when the telephone network was the world's dominant +communication network. Recall from Section 1.3 that the telephone +network uses circuit switching to transmit information from a sender to +a receiver---an appropriate choice given that voice is transmitted at a +constant rate between sender and receiver. Given the increasing +importance of computers in the early 1960s and the advent of timeshared +computers, it was perhaps natural to consider how to hook computers +together so that they could be shared among geographically distributed +users. The traffic generated by such users was likely to be +bursty---intervals of activity, such as the sending of a command to a +remote computer, followed by periods of inactivity while waiting for a +reply or while contemplating the received response. Three research +groups around the world, each unaware of the others' work \[Leiner +1998\], began inventing packet switching as an efficient and robust +alternative to circuit switching. The first published work on +packet-switching techniques was that of Leonard Kleinrock \[Kleinrock +1961; Kleinrock 1964\], then a graduate student at MIT. Using queuing +theory, Kleinrock's work elegantly demonstrated the effectiveness of the +packet-switching approach for bursty traffic sources. In 1964, Paul +Baran \[Baran 1964\] at the Rand Institute had begun investigating the +use of packet switching for secure voice over military networks, and at +the National Physical Laboratory in England, Donald Davies and Roger +Scantlebury were also developing their ideas on packet switching. The +work at MIT, Rand, and the NPL laid the foundations for today's +Internet. But the Internet also has a long history of a +let's-build-it-and-demonstrate-it attitude that also dates back to the +1960s. J. C. R. Licklider \[DEC 1990\] and Lawrence Roberts, both +colleagues of Kleinrock's at MIT, went on to lead the computer science +program at the Advanced Research Projects Agency (ARPA) in the United +States. Roberts published an overall plan for the ARPAnet \[Roberts +1967\], the first packet-switched computer network and a direct ancestor +of today's public Internet. On Labor Day in 1969, the first packet +switch was installed at UCLA under Kleinrock's supervision, and three +additional packet switches were installed + + shortly thereafter at the Stanford Research Institute (SRI), UC Santa +Barbara, and the University of Utah (Figure 1.26). The fledgling +precursor to the Internet was four nodes large by the end of 1969. +Kleinrock recalls the very first use of the network to perform a remote +login from UCLA to SRI, crashing the system \[Kleinrock 2004\]. By 1972, +ARPAnet had grown to approximately 15 nodes and was given its first +public demonstration by Robert Kahn. The first host-to-host protocol +between ARPAnet end systems, known as the networkcontrol protocol (NCP), +was completed \[RFC 001\]. With an end-to-end protocol available, +applications could now be written. Ray Tomlinson wrote the first e-mail +program in 1972. + +1.7.2 Proprietary Networks and Internetworking: 1972--1980 The initial +ARPAnet was a single, closed network. In order to communicate with an +ARPAnet host, one had to be actually attached to another ARPAnet IMP. In +the early to mid-1970s, additional stand-alone packet-switching networks +besides ARPAnet came into being: ALOHANet, a microwave network linking +universities on the Hawaiian islands \[Abramson 1970\], as well as +DARPA's packet-satellite \[RFC 829\] + + Figure 1.26 An early packet switch + +and packet-radio networks \[Kahn 1978\]; Telenet, a BBN commercial +packet-switching network based on ARPAnet technology; Cyclades, a French +packet-switching network pioneered by Louis Pouzin \[Think 2012\]; +Time-sharing networks such as Tymnet and the GE Information Services +network, among others, in the late 1960s and early 1970s \[Schwartz +1977\]; IBM's SNA (1969--1974), which paralleled the ARPAnet work +\[Schwartz 1977\]. + + The number of networks was growing. With perfect hindsight we can see +that the time was ripe for developing an encompassing architecture for +connecting networks together. Pioneering work on interconnecting +networks (under the sponsorship of the Defense Advanced Research +Projects Agency (DARPA)), in essence creating a network of networks, was +done by Vinton Cerf and Robert Kahn \[Cerf 1974\]; the term internetting +was coined to describe this work. These architectural principles were +embodied in TCP. The early versions of TCP, however, were quite +different from today's TCP. The early versions of TCP combined a +reliable in-sequence delivery of data via end-system retransmission +(still part of today's TCP) with forwarding functions (which today are +performed by IP). Early experimentation with TCP, combined with the +recognition of the importance of an unreliable, non-flow-controlled, +end-to-end transport service for applications such as packetized voice, +led to the separation of IP out of TCP and the development of the UDP +protocol. The three key Internet protocols that we see today---TCP, UDP, +and IP---were conceptually in place by the end of the 1970s. In addition +to the DARPA Internet-related research, many other important networking +activities were underway. In Hawaii, Norman Abramson was developing +ALOHAnet, a packet-based radio network that allowed multiple remote +sites on the Hawaiian Islands to communicate with each other. The ALOHA +protocol \[Abramson 1970\] was the first multiple-access protocol, +allowing geographically distributed users to share a single broadcast +communication medium (a radio frequency). Metcalfe and Boggs built on +Abramson's multiple-access protocol work when they developed the +Ethernet protocol \[Metcalfe 1976\] for wire-based shared broadcast +networks. Interestingly, Metcalfe and Boggs' Ethernet protocol was +motivated by the need to connect multiple PCs, printers, and shared +disks \[Perkins 1994\]. Twentyfive years ago, well before the PC +revolution and the explosion of networks, Metcalfe and Boggs were laying +the foundation for today's PC LANs. + +1.7.3 A Proliferation of Networks: 1980--1990 By the end of the 1970s, +approximately two hundred hosts were connected to the ARPAnet. By the +end of the 1980s the number of hosts connected to the public Internet, a +confederation of networks looking much like today's Internet, would +reach a hundred thousand. The 1980s would be a time of tremendous +growth. Much of that growth resulted from several distinct efforts to +create computer networks linking universities together. BITNET provided +e-mail and file transfers among several universities in the Northeast. +CSNET (computer science network) was formed to link university +researchers who did not have access to ARPAnet. In 1986, NSFNET was +created to provide access to NSF-sponsored supercomputing centers. +Starting with an initial backbone speed of 56 kbps, NSFNET's backbone +would be running at 1.5 Mbps by the end of the decade and would serve as +a primary backbone linking regional networks. + + In the ARPAnet community, many of the final pieces of today's Internet +architecture were falling into place. January 1, 1983 saw the official +deployment of TCP/IP as the new standard host protocol for ARPAnet +(replacing the NCP protocol). The transition \[RFC 801\] from NCP to +TCP/IP was a flag day event---all hosts were required to transfer over +to TCP/IP as of that day. In the late 1980s, important extensions were +made to TCP to implement host-based congestion control \[Jacobson +1988\]. The DNS, used to map between a human-readable Internet name (for +example, gaia.cs.umass.edu) and its 32-bit IP address, was also +developed \[RFC 1034\]. Paralleling this development of the ARPAnet +(which was for the most part a US effort), in the early 1980s the French +launched the Minitel project, an ambitious plan to bring data networking +into everyone's home. Sponsored by the French government, the Minitel +system consisted of a public packet-switched network (based on the X.25 +protocol suite), Minitel servers, and inexpensive terminals with +built-in low-speed modems. The Minitel became a huge success in 1984 +when the French government gave away a free Minitel terminal to each +French household that wanted one. Minitel sites included free +sites---such as a telephone directory site---as well as private sites, +which collected a usage-based fee from each user. At its peak in the mid +1990s, it offered more than 20,000 services, ranging from home banking +to specialized research databases. The Minitel was in a large proportion +of French homes 10 years before most Americans had ever heard of the +Internet. + +1.7.4 The Internet Explosion: The 1990s The 1990s were ushered in with a +number of events that symbolized the continued evolution and the +soon-to-arrive commercialization of the Internet. ARPAnet, the +progenitor of the Internet, ceased to exist. In 1991, NSFNET lifted its +restrictions on the use of NSFNET for commercial purposes. NSFNET itself +would be decommissioned in 1995, with Internet backbone traffic being +carried by commercial Internet Service Providers. The main event of the +1990s was to be the emergence of the World Wide Web application, which +brought the Internet into the homes and businesses of millions of people +worldwide. The Web served as a platform for enabling and deploying +hundreds of new applications that we take for granted today, including +search (e.g., Google and Bing) Internet commerce (e.g., Amazon and eBay) +and social networks (e.g., Facebook). The Web was invented at CERN by +Tim Berners-Lee between 1989 and 1991 \[Berners-Lee 1989\], based on +ideas originating in earlier work on hypertext from the 1940s by +Vannevar Bush \[Bush 1945\] and since the 1960s by Ted Nelson \[Xanadu +2012\]. Berners-Lee and his associates developed initial versions of +HTML, HTTP, a Web server, and a browser---the four key components of the +Web. Around the end of 1993 there were about two hundred Web servers in +operation, this collection of servers being + + just a harbinger of what was about to come. At about this time several +researchers were developing Web browsers with GUI interfaces, including +Marc Andreessen, who along with Jim Clark, formed Mosaic Communications, +which later became Netscape Communications Corporation \[Cusumano 1998; +Quittner 1998\]. By 1995, university students were using Netscape +browsers to surf the Web on a daily basis. At about this time +companies---big and small---began to operate Web servers and transact +commerce over the Web. In 1996, Microsoft started to make browsers, +which started the browser war between Netscape and Microsoft, which +Microsoft won a few years later \[Cusumano 1998\]. The second half of +the 1990s was a period of tremendous growth and innovation for the +Internet, with major corporations and thousands of startups creating +Internet products and services. By the end of the millennium the +Internet was supporting hundreds of popular applications, including four +killer applications: E-mail, including attachments and Web-accessible +e-mail The Web, including Web browsing and Internet commerce Instant +messaging, with contact lists Peer-to-peer file sharing of MP3s, +pioneered by Napster Interestingly, the first two killer applications +came from the research community, whereas the last two were created by a +few young entrepreneurs. The period from 1995 to 2001 was a +roller-coaster ride for the Internet in the financial markets. Before +they were even profitable, hundreds of Internet startups made initial +public offerings and started to be traded in a stock market. Many +companies were valued in the billions of dollars without having any +significant revenue streams. The Internet stocks collapsed in +2000--2001, and many startups shut down. Nevertheless, a number of +companies emerged as big winners in the Internet space, including +Microsoft, Cisco, Yahoo, e-Bay, Google, and Amazon. + +1.7.5 The New Millennium Innovation in computer networking continues at +a rapid pace. Advances are being made on all fronts, including +deployments of faster routers and higher transmission speeds in both +access networks and in network backbones. But the following developments +merit special attention: Since the beginning of the millennium, we have +been seeing aggressive deployment of broadband Internet access to +homes---not only cable modems and DSL but also fiber to the home, as +discussed in Section 1.2. This high-speed Internet access has set the +stage for a wealth of video applications, including the distribution of +user-generated video (for example, YouTube), on-demand streaming of +movies and television shows (e.g., Netflix), and multi-person video +conference (e.g., Skype, + + Facetime, and Google Hangouts). The increasing ubiquity of high-speed +(54 Mbps and higher) public WiFi networks and mediumspeed (tens of Mbps) +Internet access via 4G cellular telephony networks is not only making it +possible to remain constantly connected while on the move, but also +enabling new location-specific applications such as Yelp, Tinder, Yik +Yak, and Waz. The number of wireless devices connecting to the Internet +surpassed the number of wired devices in 2011. This high-speed wireless +access has set the stage for the rapid emergence of hand-held computers +(iPhones, Androids, iPads, and so on), which enjoy constant and +untethered access to the Internet. Online social networks---such as +Facebook, Instagram, Twitter, and WeChat (hugely popular in +China)---have created massive people networks on top of the Internet. +Many of these social networks are extensively used for messaging as well +as photo sharing. Many Internet users today "live" primarily within one +or more social networks. Through their APIs, the online social networks +create platforms for new networked applications and distributed games. +As discussed in Section 1.3.3, online service providers, such as Google +and Microsoft, have deployed their own extensive private networks, which +not only connect together their globally distributed data centers, but +are used to bypass the Internet as much as possible by peering directly +with lower-tier ISPs. As a result, Google provides search results and +e-mail access almost instantaneously, as if their data centers were +running within one's own computer. Many Internet commerce companies are +now running their applications in the "cloud"---such as in Amazon's EC2, +in Google's Application Engine, or in Microsoft's Azure. Many companies +and universities have also migrated their Internet applications (e.g., +e-mail and Web hosting) to the cloud. Cloud companies not only provide +applications scalable computing and storage environments, but also +provide the applications implicit access to their high-performance +private networks. + + 1.8 Summary In this chapter we've covered a tremendous amount of +material! We've looked at the various pieces of hardware and software +that make up the Internet in particular and computer networks in +general. We started at the edge of the network, looking at end systems +and applications, and at the transport service provided to the +applications running on the end systems. We also looked at the +link-layer technologies and physical media typically found in the access +network. We then dove deeper inside the network, into the network core, +identifying packet switching and circuit switching as the two basic +approaches for transporting data through a telecommunication network, +and we examined the strengths and weaknesses of each approach. We also +examined the structure of the global Internet, learning that the +Internet is a network of networks. We saw that the Internet's +hierarchical structure, consisting of higherand lower-tier ISPs, has +allowed it to scale to include thousands of networks. In the second part +of this introductory chapter, we examined several topics central to the +field of computer networking. We first examined the causes of delay, +throughput and packet loss in a packetswitched network. We developed +simple quantitative models for transmission, propagation, and queuing +delays as well as for throughput; we'll make extensive use of these +delay models in the homework problems throughout this book. Next we +examined protocol layering and service models, key architectural +principles in networking that we will also refer back to throughout this +book. We also surveyed some of the more prevalent security attacks in +the Internet day. We finished our introduction to networking with a +brief history of computer networking. The first chapter in itself +constitutes a minicourse in computer networking. So, we have indeed +covered a tremendous amount of ground in this first chapter! If you're a +bit overwhelmed, don't worry. In the following chapters we'll revisit +all of these ideas, covering them in much more detail (that's a promise, +not a threat!). At this point, we hope you leave this chapter with a +still-developing intuition for the pieces that make up a network, a +still-developing command of the vocabulary of networking (don't be shy +about referring back to this chapter), and an ever-growing desire to +learn more about networking. That's the task ahead of us for the rest of +this book. + +Road-Mapping This Book Before starting any trip, you should always +glance at a road map in order to become familiar with the major roads +and junctures that lie ahead. For the trip we are about to embark on, +the ultimate destination is a deep understanding of the how, what, and +why of computer networks. Our road map is + + the sequence of chapters of this book: + +1. Computer Networks and the Internet +2. Application Layer +3. Transport Layer +4. Network Layer: Data Plane +5. Network Layer: Control Plane +6. The Link Layer and LANs +7. Wireless and Mobile Networks +8. Security in Computer Networks +9. Multimedia Networking Chapters 2 through 6 are the five core + chapters of this book. You should notice that these chapters are + organized around the top four layers of the five-layer Internet + protocol. Further note that our journey will begin at the top of the + Internet protocol stack, namely, the application layer, and will + work its way downward. The rationale behind this top-down journey is + that once we understand the applications, we can understand the + network services needed to support these applications. We can then, + in turn, examine the various ways in which such services might be + implemented by a network architecture. Covering applications early + thus provides motivation for the remainder of the text. The second + half of the book---Chapters 7 through 9---zooms in on three + enormously important (and somewhat independent) topics in modern + computer networking. In Chapter 7, we examine wireless and mobile + networks, including wireless LANs (including WiFi and Bluetooth), + Cellular telephony networks (including GSM, 3G, and 4G), and + mobility (in both IP and GSM networks). Chapter 8, which addresses + security in computer networks, first looks at the underpinnings of + encryption and network security, and then we examine how the basic + theory is being applied in a broad range of Internet contexts. The + last chapter, which addresses multimedia networking, examines audio + and video applications such as Internet phone, video conferencing, + and streaming of stored media. We also look at how a packetswitched + network can be designed to provide consistent quality of service to + audio and video applications. + + Homework Problems and Questions + +Chapter 1 Review Questions + +SECTION 1.1 R1. What is the difference between a host and an end system? +List several different types of end systems. Is a Web server an end +system? R2. The word protocol is often used to describe diplomatic +relations. How does Wikipedia describe diplomatic protocol? R3. Why are +standards important for protocols? + +SECTION 1.2 R4. List six access technologies. Classify each one as home +access, enterprise access, or widearea wireless access. R5. Is HFC +transmission rate dedicated or shared among users? Are collisions +possible in a downstream HFC channel? Why or why not? R6. List the +available residential access technologies in your city. For each type of +access, provide the advertised downstream rate, upstream rate, and +monthly price. R7. What is the transmission rate of Ethernet LANs? R8. +What are some of the physical media that Ethernet can run over? R9. +Dial-up modems, HFC, DSL and FTTH are all used for residential access. +For each of these access technologies, provide a range of transmission +rates and comment on whether the transmission rate is shared or +dedicated. R10. Describe the most popular wireless Internet access +technologies today. Compare and contrast them. + +SECTION 1.3 R11. Suppose there is exactly one packet switch between a +sending host and a receiving host. The transmission rates between the +sending host and the switch and between the switch and the receiving +host are R1 and R2, respectively. Assuming that the switch uses +store-and-forward packet switching, what is the total end-to-end delay +to send a packet of length L? (Ignore queuing, propagation delay, and +processing delay.) + + R12. What advantage does a circuit-switched network have over a +packet-switched network? What advantages does TDM have over FDM in a +circuit-switched network? R13. Suppose users share a 2 Mbps link. Also +suppose each user transmits continuously at 1 Mbps when transmitting, +but each user transmits only 20 percent of the time. (See the discussion +of statistical multiplexing in Section 1.3 .) + +a. When circuit switching is used, how many users can be supported? + +b. For the remainder of this problem, suppose packet switching is used. + Why will there be essentially no queuing delay before the link if + two or fewer users transmit at the same time? Why will there be a + queuing delay if three users transmit at the same time? + +c. Find the probability that a given user is transmitting. + +d. Suppose now there are three users. Find the probability that at any + given time, all three users are transmitting simultaneously. Find + the fraction of time during which the queue grows. R14. Why will two + ISPs at the same level of the hierarchy often peer with each other? + How does an IXP earn money? R15. Some content providers have created + their own networks. Describe Google's network. What motivates + content providers to create these networks? + +SECTION 1.4 R16. Consider sending a packet from a source host to a +destination host over a fixed route. List the delay components in the +end-to-end delay. Which of these delays are constant and which are +variable? R17. Visit the Transmission Versus Propagation Delay applet at +the companion Web site. Among the rates, propagation delay, and packet +sizes available, find a combination for which the sender finishes +transmitting before the first bit of the packet reaches the receiver. +Find another combination for which the first bit of the packet reaches +the receiver before the sender finishes transmitting. R18. How long does +it take a packet of length 1,000 bytes to propagate over a link of +distance 2,500 km, propagation speed 2.5⋅108 m/s, and transmission rate +2 Mbps? More generally, how long does it take a packet of length L to +propagate over a link of distance d, propagation speed s, and +transmission rate R bps? Does this delay depend on packet length? Does +this delay depend on transmission rate? R19. Suppose Host A wants to +send a large file to Host B. The path from Host A to Host B has three +links, of rates R1=500 kbps, R2=2 Mbps, and R3=1 Mbps. + +a. Assuming no other traffic in the network, what is the throughput for + the file transfer? + +b. Suppose the file is 4 million bytes. Dividing the file size by the + throughput, roughly how long will it take to transfer the file to + Host B? + +c. Repeat (a) and (b), but now with R2 reduced to 100 kbps. + + R20. Suppose end system A wants to send a large file to end system B. At +a very high level, describe how end system A creates packets from the +file. When one of these packets arrives to a router, what information in +the packet does the router use to determine the link onto which the +packet is forwarded? Why is packet switching in the Internet analogous +to driving from one city to another and asking directions along the way? +R21. Visit the Queuing and Loss applet at the companion Web site. What +is the maximum emission rate and the minimum transmission rate? With +those rates, what is the traffic intensity? Run the applet with these +rates and determine how long it takes for packet loss to occur. Then +repeat the experiment a second time and determine again how long it +takes for packet loss to occur. Are the values different? Why or why +not? + +SECTION 1.5 R22. List five tasks that a layer can perform. Is it +possible that one (or more) of these tasks could be performed by two (or +more) layers? R23. What are the five layers in the Internet protocol +stack? What are the principal responsibilities of each of these layers? +R24. What is an application-layer message? A transport-layer segment? A +network-layer datagram? A link-layer frame? R25. Which layers in the +Internet protocol stack does a router process? Which layers does a +link-layer switch process? Which layers does a host process? + +SECTION 1.6 R26. What is the difference between a virus and a worm? R27. +Describe how a botnet can be created and how it can be used for a DDoS +attack. R28. Suppose Alice and Bob are sending packets to each other +over a computer network. Suppose Trudy positions herself in the network +so that she can capture all the packets sent by Alice and send whatever +she wants to Bob; she can also capture all the packets sent by Bob and +send whatever she wants to Alice. List some of the malicious things +Trudy can do from this position. + +Problems P1. Design and describe an application-level protocol to be +used between an automatic teller machine and a bank's centralized +computer. Your protocol should allow a user's card and password to be +verified, the account balance (which is maintained at the centralized +computer) to be queried, and an account withdrawal to be made (that is, +money disbursed to the user). + + Your protocol entities should be able to handle the all-too-common case +in which there is not enough money in the account to cover the +withdrawal. Specify your protocol by listing the messages exchanged and +the action taken by the automatic teller machine or the bank's +centralized computer on transmission and receipt of messages. Sketch the +operation of your protocol for the case of a simple withdrawal with no +errors, using a diagram similar to that in Figure 1.2 . Explicitly state +the assumptions made by your protocol about the underlying end-toend +transport service. P2. Equation 1.1 gives a formula for the end-to-end +delay of sending one packet of length L over N links of transmission +rate R. Generalize this formula for sending P such packets back-toback +over the N links. P3. Consider an application that transmits data at a +steady rate (for example, the sender generates an N-bit unit of data +every k time units, where k is small and fixed). Also, when such an +application starts, it will continue running for a relatively long +period of time. Answer the following questions, briefly justifying your +answer: + +a. Would a packet-switched network or a circuit-switched network be + more appropriate for this application? Why? + +b. Suppose that a packet-switched network is used and the only traffic + in this network comes from such applications as described above. + Furthermore, assume that the sum of the application data rates is + less than the capacities of each and every link. Is some form of + congestion control needed? Why? P4. Consider the circuit-switched + network in Figure 1.13 . Recall that there are 4 circuits on each + link. Label the four switches A, B, C, and D, going in the clockwise + direction. + +c. What is the maximum number of simultaneous connections that can be + in progress at any one time in this network? + +d. Suppose that all connections are between switches A and C. What is + the maximum number of simultaneous connections that can be in + progress? + +e. Suppose we want to make four connections between switches A and C, + and another four connections between switches B and D. Can we route + these calls through the four links to accommodate all eight + connections? P5. Review the car-caravan analogy in Section 1.4 . + Assume a propagation speed of 100 km/hour. + +f. Suppose the caravan travels 150 km, beginning in front of one + tollbooth, passing through a second tollbooth, and finishing just + after a third tollbooth. What is the end-to-end delay? + +g. Repeat (a), now assuming that there are eight cars in the caravan + instead of ten. P6. This elementary problem begins to explore + propagation delay and transmission delay, two central concepts in + data networking. Consider two hosts, A and B, connected by a single + link of rate R bps. Suppose that the two hosts are separated by m + meters, and suppose the + + propagation speed along the link is s meters/sec. Host A is to send a +packet of size L bits to Host B. + +Exploring propagation delay and transmission delay + +a. Express the propagation delay, dprop, in terms of m and s. + +b. Determine the transmission time of the packet, dtrans, in terms of L + and R. + +c. Ignoring processing and queuing delays, obtain an expression for the + end-to-end delay. + +d. Suppose Host A begins to transmit the packet at time t=0. At time t= + dtrans, where is the last bit of the packet? + +e. Suppose dprop is greater than dtrans. At time t=dtrans, where is the + first bit of the packet? + +f. Suppose dprop is less than dtrans. At time t=dtrans, where is the + first bit of the packet? + +g. Suppose s=2.5⋅108, L=120 bits, and R=56 kbps. Find the distance m so + that dprop equals dtrans. P7. In this problem, we consider sending + real-time voice from Host A to Host B over a packetswitched network + (VoIP). Host A converts analog voice to a digital 64 kbps bit stream + on the fly. Host A then groups the bits into 56-byte packets. There + is one link between Hosts A and B; its transmission rate is 2 Mbps + and its propagation delay is 10 msec. As soon as Host A gathers a + packet, it sends it to Host B. As soon as Host B receives an entire + packet, it converts the packet's bits to an analog signal. How much + time elapses from the time a bit is created (from the original + analog signal at Host A) until the bit is decoded (as part of the + analog signal at Host B)? P8. Suppose users share a 3 Mbps link. + Also suppose each user requires 150 kbps when transmitting, but each + user transmits only 10 percent of the time. (See the discussion of + packet switching versus circuit switching in Section 1.3 .) + +h. When circuit switching is used, how many users can be supported? + +i. For the remainder of this problem, suppose packet switching is used. + Find the probability that a given user is transmitting. + +j. Suppose there are 120 users. Find the probability that at any given + time, exactly n users are transmitting simultaneously. (Hint: Use + the binomial distribution.) + +k. Find the probability that there are 21 or more users transmitting + simultaneously. P9. Consider the discussion in Section 1.3 of packet + switching versus circuit switching in which an example is provided + with a 1 Mbps link. Users are generating data at a rate of 100 kbps + when busy, but are busy generating data only with probability p=0.1. + Suppose that the 1 Mbps link is + + replaced by a 1 Gbps link. + +a. What is N, the maximum number of users that can be supported + simultaneously under circuit switching? + +b. Now consider packet switching and a user population of M users. Give + a formula (in terms of p, M, N) for the probability that more than N + users are sending data. P10. Consider a packet of length L that + begins at end system A and travels over three links to a destination + end system. These three links are connected by two packet switches. + Let di, si, and Ri denote the length, propagation speed, and the + transmission rate of link i, for i=1,2,3. The packet switch delays + each packet by dproc. Assuming no queuing delays, in terms of di, + si, Ri, (i=1,2,3), and L, what is the total end-to-end delay for the + packet? Suppose now the packet is 1,500 bytes, the propagation speed + on all three links is 2.5⋅108m/s, the transmission rates of all + three links are 2 Mbps, the packet switch processing delay is 3 + msec, the length of the first link is 5,000 km, the length of the + second link is 4,000 km, and the length of the last link is 1,000 + km. For these values, what is the end-to-end delay? P11. In the + above problem, suppose R1=R2=R3=R and dproc=0. Further suppose the + packet switch does not store-and-forward packets but instead + immediately transmits each bit it receives before waiting for the + entire packet to arrive. What is the end-to-end delay? P12. A packet + switch receives a packet and determines the outbound link to which + the packet should be forwarded. When the packet arrives, one other + packet is halfway done being transmitted on this outbound link and + four other packets are waiting to be transmitted. Packets are + transmitted in order of arrival. Suppose all packets are 1,500 bytes + and the link rate is 2 Mbps. What is the queuing delay for the + packet? More generally, what is the queuing delay when all packets + have length L, the transmission rate is R, x bits of the + currently-being-transmitted packet have been transmitted, and n + packets are already in the queue? P13. + +c. Suppose N packets arrive simultaneously to a link at which no + packets are currently being transmitted or queued. Each packet is of + length L and the link has transmission rate R. What is the average + queuing delay for the N packets? + +d. Now suppose that N such packets arrive to the link every LN/R + seconds. What is the average queuing delay of a packet? P14. + Consider the queuing delay in a router buffer. Let I denote traffic + intensity; that is, I=La/R. Suppose that the queuing delay takes the + form IL/R(1−I) for I\<1. + +e. Provide a formula for the total delay, that is, the queuing delay + plus the transmission delay. + +f. Plot the total delay as a function of L /R. P15. Let a denote the + rate of packets arriving at a link in packets/sec, and let µ denote + the link's transmission rate in packets/sec. Based on the formula + for the total delay (i.e., the queuing delay + + plus the transmission delay) derived in the previous problem, derive a +formula for the total delay in terms of a and µ. P16. Consider a router +buffer preceding an outbound link. In this problem, you will use +Little's formula, a famous formula from queuing theory. Let N denote the +average number of packets in the buffer plus the packet being +transmitted. Let a denote the rate of packets arriving at the link. Let +d denote the average total delay (i.e., the queuing delay plus the +transmission delay) experienced by a packet. Little's formula is +N=a⋅d. Suppose that on average, the buffer contains 10 packets, and the +average packet queuing delay is 10 msec. The link's transmission rate is +100 packets/sec. Using Little's formula, what is the average packet +arrival rate, assuming there is no packet loss? P17. + +a. Generalize Equation 1.2 in Section 1.4.3 for heterogeneous + processing rates, transmission rates, and propagation delays. + +b. Repeat (a), but now also suppose that there is an average queuing + delay of dqueue at each node. P18. Perform a Traceroute between + source and destination on the same continent at three different + hours of the day. + +Using Traceroute to discover network paths and measure network delay + +a. Find the average and standard deviation of the round-trip delays at + each of the three hours. + +b. Find the number of routers in the path at each of the three hours. + Did the paths change during any of the hours? + +c. Try to identify the number of ISP networks that the Traceroute + packets pass through from source to destination. Routers with + similar names and/or similar IP addresses should be considered as + part of the same ISP. In your experiments, do the largest delays + occur at the peering interfaces between adjacent ISPs? + +d. Repeat the above for a source and destination on different + continents. Compare the intra-continent and inter-continent results. + P19. + +e. Visit the site www.traceroute.org and perform traceroutes from two + different cities in France to the same destination host in the + United States. How many links are the same + + in the two traceroutes? Is the transatlantic link the same? + +b. Repeat (a) but this time choose one city in France and another city + in Germany. + +c. Pick a city in the United States, and perform traceroutes to two + hosts, each in a different city in China. How many links are common + in the two traceroutes? Do the two traceroutes diverge before + reaching China? P20. Consider the throughput example corresponding + to Figure 1.20(b) . Now suppose that there are M client-server pairs + rather than 10. Denote Rs, Rc, and R for the rates of the server + links, client links, and network link. Assume all other links have + abundant capacity and that there is no other traffic in the network + besides the traffic generated by the M client-server pairs. Derive a + general expression for throughput in terms of Rs, Rc, R, and M. P21. + Consider Figure 1.19(b) . Now suppose that there are M paths between + the server and the client. No two paths share any link. Path + k(k=1,...,M) consists of N links with transmission rates + R1k,R2k,...,RNk. If the server can only use one path to send data to + the client, what is the maximum throughput that the server can + achieve? If the server can use all M paths to send data, what is the + maximum throughput that the server can achieve? P22. Consider Figure + 1.19(b) . Suppose that each link between the server and the client + has a packet loss probability p, and the packet loss probabilities + for these links are independent. What is the probability that a + packet (sent by the server) is successfully received by the + receiver? If a packet is lost in the path from the server to the + client, then the server will re-transmit the packet. On average, how + many times will the server re-transmit the packet in order for the + client to successfully receive the packet? P23. Consider Figure + 1.19(a) . Assume that we know the bottleneck link along the path + from the server to the client is the first link with rate Rs + bits/sec. Suppose we send a pair of packets back to back from the + server to the client, and there is no other traffic on this path. + Assume each packet of size L bits, and both links have the same + propagation delay dprop. + +d. What is the packet inter-arrival time at the destination? That is, + how much time elapses from when the last bit of the first packet + arrives until the last bit of the second packet arrives? + +e. Now assume that the second link is the bottleneck link (i.e., + Rc\<Rs). Is it possible that the second packet queues at the input + queue of the second link? Explain. Now suppose that the server sends + the second packet T seconds after sending the first packet. How + large must T be to ensure no queuing before the second link? + Explain. P24. Suppose you would like to urgently deliver 40 + terabytes data from Boston to Los Angeles. You have available a 100 + Mbps dedicated link for data transfer. Would you prefer to transmit + the data via this link or instead use FedEx over-night delivery? + Explain. P25. Suppose two hosts, A and B, are separated by 20,000 + kilometers and are connected by a direct link of R=2 Mbps. Suppose + the propagation speed over the link is 2.5⋅108 meters/sec. + +f. Calculate the bandwidth-delay product, R⋅dprop. + + b. Consider sending a file of 800,000 bits from Host A to Host B. +Suppose the file is sent continuously as one large message. What is the +maximum number of bits that will be in the link at any given time? + +c. Provide an interpretation of the bandwidth-delay product. + +d. What is the width (in meters) of a bit in the link? Is it longer + than a football field? + +e. Derive a general expression for the width of a bit in terms of the + propagation speed s, the transmission rate R, and the length of the + link m. P26. Referring to problem P25, suppose we can modify R. For + what value of R is the width of a bit as long as the length of the + link? P27. Consider problem P25 but now with a link of R=1 Gbps. + +f. Calculate the bandwidth-delay product, R⋅dprop. + +g. Consider sending a file of 800,000 bits from Host A to Host B. + Suppose the file is sent continuously as one big message. What is + the maximum number of bits that will be in the link at any given + time? + +h. What is the width (in meters) of a bit in the link? P28. Refer again + to problem P25. + +i. How long does it take to send the file, assuming it is sent + continuously? + +j. Suppose now the file is broken up into 20 packets with each packet + containing 40,000 bits. Suppose that each packet is acknowledged by + the receiver and the transmission time of an acknowledgment packet + is negligible. Finally, assume that the sender cannot send a packet + until the preceding one is acknowledged. How long does it take to + send the file? + +k. Compare the results from (a) and (b). P29. Suppose there is a 10 + Mbps microwave link between a geostationary satellite and its base + station on Earth. Every minute the satellite takes a digital photo + and sends it to the base station. Assume a propagation speed of + 2.4⋅108 meters/sec. + +l. What is the propagation delay of the link? + +m. What is the bandwidth-delay product, R⋅dprop? + +n. Let x denote the size of the photo. What is the minimum value of x + for the microwave link to be continuously transmitting? P30. + Consider the airline travel analogy in our discussion of layering in + Section 1.5 , and the addition of headers to protocol data units as + they flow down the protocol stack. Is there an equivalent notion of + header information that is added to passengers and baggage as they + move down the airline protocol stack? P31. In modern packet-switched + networks, including the Internet, the source host segments long, + application-layer messages (for example, an image or a music file) + into smaller packets + + and sends the packets into the network. The receiver then reassembles +the packets back into the original message. We refer to this process as +message segmentation. Figure 1.27 illustrates the end-to-end transport +of a message with and without message segmentation. Consider a message +that is 8⋅106 bits long that is to be sent from source to destination in +Figure 1.27 . Suppose each link in the figure is 2 Mbps. Ignore +propagation, queuing, and processing delays. + +a. Consider sending the message from source to destination without + message segmentation. How long does it take to move the message from + the source host to the first packet switch? Keeping in mind that + each switch uses store-and-forward packet switching, what is the + total time to move the message from source host to destination host? + +b. Now suppose that the message is segmented into 800 packets, with + each packet being 10,000 bits long. How long does it take to move + the first packet from source host to the first switch? When the + first packet is being sent from the first switch to the second + switch, the second packet is being sent from the source host to the + first switch. At what time will the second packet be fully received + at the first switch? + +c. How long does it take to move the file from source host to + destination host when message segmentation is used? Compare this + result with your answer in part (a) and comment. + +Figure 1.27 End-to-end message transport: (a) without message +segmentation; (b) with message segmentation + +d. In addition to reducing delay, what are reasons to use message + segmentation? +e. Discuss the drawbacks of message segmentation. P32. Experiment with + the Message Segmentation applet at the book's Web site. Do the + delays in the applet correspond to the delays in the previous + problem? How do link propagation delays affect the overall + end-to-end delay for packet switching (with message segmentation) + and for message switching? P33. Consider sending a large file of F + bits from Host A to Host B. There are three links (and two switches) + between A and B, and the links are uncongested (that is, no queuing + delays). Host A + + segments the file into segments of S bits each and adds 80 bits of +header to each segment, forming packets of L=80 + S bits. Each link has +a transmission rate of R bps. Find the value of S that minimizes the +delay of moving the file from Host A to Host B. Disregard propagation +delay. P34. Skype offers a service that allows you to make a phone call +from a PC to an ordinary phone. This means that the voice call must pass +through both the Internet and through a telephone network. Discuss how +this might be done. + +Wireshark Lab + +"Tell me and I forget. Show me and I remember. Involve me and I +understand." Chinese proverb + +One's understanding of network protocols can often be greatly deepened +by seeing them in action and by playing around with them---observing the +sequence of messages exchanged between two protocol entities, delving +into the details of protocol operation, causing protocols to perform +certain actions, and observing these actions and their consequences. +This can be done in simulated scenarios or in a real network environment +such as the Internet. The Java applets at the textbook Web site take the +first approach. In the Wireshark labs, we'll take the latter approach. +You'll run network applications in various scenarios using a computer on +your desk, at home, or in a lab. You'll observe the network protocols in +your computer, interacting and exchanging messages with protocol +entities executing elsewhere in the Internet. Thus, you and your +computer will be an integral part of these live labs. You'll +observe---and you'll learn---by doing. The basic tool for observing the +messages exchanged between executing protocol entities is called a +packet sniffer. As the name suggests, a packet sniffer passively copies +(sniffs) messages being sent from and received by your computer; it also +displays the contents of the various protocol fields of these captured +messages. A screenshot of the Wireshark packet sniffer is shown in +Figure 1.28. Wireshark is a free packet sniffer that runs on Windows, +Linux/Unix, and Mac computers. + + Figure 1.28 A Wireshark screenshot (Wireshark screenshot reprinted by +permission of the Wireshark Foundation.) + +Throughout the textbook, you will find Wireshark labs that allow you to +explore a number of the protocols studied in the chapter. In this first +Wireshark lab, you'll obtain and install a copy of Wireshark, access a +Web site, and capture and examine the protocol messages being exchanged +between your Web browser and the Web server. You can find full details +about this first Wireshark lab (including instructions about how to +obtain and install Wireshark) at the Web site +http://www.pearsonhighered.com/csresources/. + +AN INTERVIEW WITH... Leonard Kleinrock Leonard Kleinrock is a professor +of computer science at the University of California, Los Angeles. In +1969, his computer at UCLA became the first node of the Internet. His +creation of packet-switching principles in 1961 became the technology +behind the Internet. He received his B.E.E. from the City College of New +York (CCNY) and his masters and PhD in electrical engineering from MIT. + + What made you decide to specialize in networking/Internet technology? As +a PhD student at MIT in 1959, I looked around and found that most of my +classmates were doing research in the area of information theory and +coding theory. At MIT, there was the great researcher, Claude Shannon, +who had launched these fields and had solved most of the important +problems already. The research problems that were left were hard and of +lesser consequence. So I decided to launch out in a new area that no one +else had yet conceived of. Remember that at MIT I was surrounded by lots +of computers, and it was clear to me that soon these machines would need +to communicate with each other. At the time, there was no effective way +for them to do so, so I decided to develop the technology that would +permit efficient and reliable data networks to be created. What was your +first job in the computer industry? What did it entail? I went to the +evening session at CCNY from 1951 to 1957 for my bachelor's degree in +electrical engineering. During the day, I worked first as a technician +and then as an engineer at a small, industrial electronics firm called +Photobell. While there, I introduced digital technology to their product +line. Essentially, we were using photoelectric devices to detect the +presence of certain items (boxes, people, etc.) and the use of a circuit +known then as a bistable multivibrator was just the kind of technology +we needed to bring digital processing into this field of detection. +These circuits happen to be the building blocks for computers, and have +come to be known as flip-flops or switches in today's vernacular. What +was going through your mind when you sent the first host-to-host message +(from UCLA to the Stanford Research Institute)? Frankly, we had no idea +of the importance of that event. We had not prepared a special message +of historic significance, as did so many inventors of the past (Samuel +Morse with "What hath God wrought." or Alexander Graham Bell with +"Watson, come here! I want you." or Neal Amstrong with "That's one small +step for a man, one giant leap for mankind.") Those guys were + + smart! They understood media and public relations. All we wanted to do +was to login to the SRI computer. So we typed the "L", which was +correctly received, we typed the "o" which was received, and then we +typed the "g" which caused the SRI host computer to crash! So, it turned +out that our message was the shortest and perhaps the most prophetic +message ever, namely "Lo!" as in "Lo and behold!" Earlier that year, I +was quoted in a UCLA press release saying that once the network was up +and running, it would be possible to gain access to computer utilities +from our homes and offices as easily as we gain access to electricity +and telephone connectivity. So my vision at that time was that the +Internet would be ubiquitous, always on, always available, anyone with +any device could connect from any location, and it would be invisible. +However, I never anticipated that my 99-year-old mother would use the +Internet---and indeed she did! What is your vision for the future of +networking? The easy part of the vision is to predict the infrastructure +itself. I anticipate that we see considerable deployment of nomadic +computing, mobile devices, and smart spaces. Indeed, the availability of +lightweight, inexpensive, high-performance, portable computing, and +communication devices (plus the ubiquity of the Internet) has enabled us +to become nomads. Nomadic computing refers to the technology that +enables end users who travel from place to place to gain access to +Internet services in a transparent fashion, no matter where they travel +and no matter what device they carry or gain access to. The harder part +of the vision is to predict the applications and services, which have +consistently surprised us in dramatic ways (e-mail, search technologies, +the World Wide Web, blogs, social networks, user generation, and sharing +of music, photos, and videos, etc.). We are on the verge of a new class +of surprising and innovative mobile applications delivered to our +hand-held devices. The next step will enable us to move out from the +netherworld of cyberspace to the physical world of smart spaces. Our +environments (desks, walls, vehicles, watches, belts, and so on) will +come alive with technology, through actuators, sensors, logic, +processing, storage, cameras, microphones, speakers, displays, and +communication. This embedded technology will allow our environment to +provide the IP services we want. When I walk into a room, the room will +know I entered. I will be able to communicate with my environment +naturally, as in spoken English; my requests will generate replies that +present Web pages to me from wall displays, through my eyeglasses, as +speech, holograms, and so forth. Looking a bit further out, I see a +networking future that includes the following additional key components. +I see intelligent software agents deployed across the network whose +function it is to mine data, act on that data, observe trends, and carry +out tasks dynamically and adaptively. I see considerably more network +traffic generated not so much by humans, but by these embedded devices +and these intelligent software agents. I see large collections of +selforganizing systems controlling this vast, fast network. I see huge +amounts of information flashing + + across this network instantaneously with this information undergoing +enormous processing and filtering. The Internet will essentially be a +pervasive global nervous system. I see all these things and more as we +move headlong through the twenty-first century. What people have +inspired you professionally? By far, it was Claude Shannon from MIT, a +brilliant researcher who had the ability to relate his mathematical +ideas to the physical world in highly intuitive ways. He was on my PhD +thesis committee. Do you have any advice for students entering the +networking/Internet field? The Internet and all that it enables is a +vast new frontier, full of amazing challenges. There is room for great +innovation. Don't be constrained by today's technology. Reach out and +imagine what could be and then make it happen. + + Chapter 2 Application Layer + +Network applications are the raisons d'être of a computer network---if +we couldn't conceive of any useful applications, there wouldn't be any +need for networking infrastructure and protocols to support them. Since +the Internet's inception, numerous useful and entertaining applications +have indeed been created. These applications have been the driving force +behind the Internet's success, motivating people in homes, schools, +governments, and businesses to make the Internet an integral part of +their daily activities. Internet applications include the classic +text-based applications that became popular in the 1970s and 1980s: text +e-mail, remote access to computers, file transfers, and newsgroups. They +include the killer application of the mid-1990s, the World Wide Web, +encompassing Web surfing, search, and electronic commerce. They include +instant messaging and P2P file sharing, the two killer applications +introduced at the end of the millennium. In the new millennium, new and +highly compelling applications continue to emerge, including voice over +IP and video conferencing such as Skype, Facetime, and Google Hangouts; +user generated video such as YouTube and movies on demand such as +Netflix; multiplayer online games such as Second Life and World of +Warcraft. During this same period, we have seen the emergence of a new +generation of social networking applications---such as Facebook, +Instagram, Twitter, and WeChat---which have created engaging human +networks on top of the Internet's network or routers and communication +links. And most recently, along with the arrival of the smartphone, +there has been a profusion of location based mobile apps, including +popular check-in, dating, and road-traffic forecasting apps (such as +Yelp, Tinder, Waz, and Yik Yak). Clearly, there has been no slowing down +of new and exciting Internet applications. Perhaps some of the readers +of this text will create the next generation of killer Internet +applications! In this chapter we study the conceptual and implementation +aspects of network applications. We begin by defining key +application-layer concepts, including network services required by +applications, clients and servers, processes, and transport-layer +interfaces. We examine several network applications in detail, including +the Web, e-mail, DNS, peer-to-peer (P2P) file distribution, and video +streaming. (Chapter 9 will further examine multimedia applications, +including streaming video and VoIP.) We then cover network application +development, over both TCP and UDP. In particular, we study the socket +interface and walk through some simple client-server applications in +Python. We also provide several fun and interesting socket programming +assignments at the end of the chapter. + + The application layer is a particularly good place to start our study of +protocols. It's familiar ground. We're acquainted with many of the +applications that rely on the protocols we'll study. It will give us a +good feel for what protocols are all about and will introduce us to many +of the same issues that we'll see again when we study transport, +network, and link layer protocols. + + 2.1 Principles of Network Applications Suppose you have an idea for a +new network application. Perhaps this application will be a great +service to humanity, or will please your professor, or will bring you +great wealth, or will simply be fun to develop. Whatever the motivation +may be, let's now examine how you transform the idea into a real-world +network application. At the core of network application development is +writing programs that run on different end systems and communicate with +each other over the network. For example, in the Web application there +are two distinct programs that communicate with each other: the browser +program running in the user's host (desktop, laptop, tablet, smartphone, +and so on); and the Web server program running in the Web server host. +As another example, in a P2P file-sharing system there is a program in +each host that participates in the file-sharing community. In this case, +the programs in the various hosts may be similar or identical. Thus, +when developing your new application, you need to write software that +will run on multiple end systems. This software could be written, for +example, in C, Java, or Python. Importantly, you do not need to write +software that runs on network-core devices, such as routers or +link-layer switches. Even if you wanted to write application software +for these network-core devices, you wouldn't be able to do so. As we +learned in Chapter 1, and as shown earlier in Figure 1.24, network-core +devices do not function at the application layer but instead function at +lower layers---specifically at the network layer and below. This basic +design---namely, confining application software to the end systems---as +shown in Figure 2.1, has facilitated the rapid development and +deployment of a vast array of network applications. + + Figure 2.1 Communication for a network application takes place between +end systems at the application layer + +2.1.1 Network Application Architectures + + Before diving into software coding, you should have a broad +architectural plan for your application. Keep in mind that an +application's architecture is distinctly different from the network +architecture (e.g., the five-layer Internet architecture discussed in +Chapter 1). From the application developer's perspective, the network +architecture is fixed and provides a specific set of services to +applications. The application architecture, on the other hand, is +designed by the application developer and dictates how the application +is structured over the various end systems. In choosing the application +architecture, an application developer will likely draw on one of the +two predominant architectural paradigms used in modern network +applications: the client-server architecture or the peer-to-peer (P2P) +architecture. In a client-server architecture, there is an always-on +host, called the server, which services requests from many other hosts, +called clients. A classic example is the Web application for which an +always-on Web server services requests from browsers running on client +hosts. When a Web server receives a request for an object from a client +host, it responds by sending the requested object to the client host. +Note that with the client-server architecture, clients do not directly +communicate with each other; for example, in the Web application, two +browsers do not directly communicate. Another characteristic of the +client-server architecture is that the server has a fixed, well-known +address, called an IP address (which we'll discuss soon). Because the +server has a fixed, well-known address, and because the server is always +on, a client can always contact the server by sending a packet to the +server's IP address. Some of the better-known applications with a +client-server architecture include the Web, FTP, Telnet, and e-mail. The +client-server architecture is shown in Figure 2.2(a). Often in a +client-server application, a single-server host is incapable of keeping +up with all the requests from clients. For example, a popular +social-networking site can quickly become overwhelmed if it has only one +server handling all of its requests. For this reason, a data center, +housing a large number of hosts, is often used to create a powerful +virtual server. The most popular Internet services---such as search +engines (e.g., Google, Bing, Baidu), Internet commerce (e.g., Amazon, +eBay, Alibaba), Webbased e-mail (e.g., Gmail and Yahoo Mail), social +networking (e.g., Facebook, Instagram, Twitter, and WeChat)---employ one +or more data centers. As discussed in Section 1.3.3, Google has 30 to 50 +data centers distributed around the world, which collectively handle +search, YouTube, Gmail, and other services. A data center can have +hundreds of thousands of servers, which must be powered and maintained. +Additionally, the service providers must pay recurring interconnection +and bandwidth costs for sending data from their data centers. In a P2P +architecture, there is minimal (or no) reliance on dedicated servers in +data centers. Instead the application exploits direct communication +between pairs of intermittently connected hosts, called peers. The peers +are not owned by the service provider, but are instead desktops and +laptops controlled by users, with most of the + + Figure 2.2 (a) Client-server architecture; (b) P2P architecture + + peers residing in homes, universities, and offices. Because the peers +communicate without passing through a dedicated server, the architecture +is called peer-to-peer. Many of today's most popular and +traffic-intensive applications are based on P2P architectures. These +applications include file sharing (e.g., BitTorrent), peer-assisted +download acceleration (e.g., Xunlei), and Internet telephony and video +conference (e.g., Skype). The P2P architecture is illustrated in Figure +2.2(b). We mention that some applications have hybrid architectures, +combining both client-server and P2P elements. For example, for many +instant messaging applications, servers are used to track the IP +addresses of users, but user-touser messages are sent directly between +user hosts (without passing through intermediate servers). One of the +most compelling features of P2P architectures is their self-scalability. +For example, in a P2P file-sharing application, although each peer +generates workload by requesting files, each peer also adds service +capacity to the system by distributing files to other peers. P2P +architectures are also cost effective, since they normally don't require +significant server infrastructure and server bandwidth (in contrast with +clients-server designs with datacenters). However, P2P applications face +challenges of security, performance, and reliability due to their highly +decentralized structure. + +2.1.2 Processes Communicating Before building your network application, +you also need a basic understanding of how the programs, running in +multiple end systems, communicate with each other. In the jargon of +operating systems, it is not actually programs but processes that +communicate. A process can be thought of as a program that is running +within an end system. When processes are running on the same end system, +they can communicate with each other with interprocess communication, +using rules that are governed by the end system's operating system. But +in this book we are not particularly interested in how processes in the +same host communicate, but instead in how processes running on different +hosts (with potentially different operating systems) communicate. +Processes on two different end systems communicate with each other by +exchanging messages across the computer network. A sending process +creates and sends messages into the network; a receiving process +receives these messages and possibly responds by sending messages back. +Figure 2.1 illustrates that processes communicating with each other +reside in the application layer of the five-layer protocol stack. Client +and Server Processes A network application consists of pairs of +processes that send messages to each other over a network. For example, +in the Web application a client browser process exchanges messages with +a Web server + + process. In a P2P file-sharing system, a file is transferred from a +process in one peer to a process in another peer. For each pair of +communicating processes, we typically label one of the two processes as +the client and the other process as the server. With the Web, a browser +is a client process and a Web server is a server process. With P2P file +sharing, the peer that is downloading the file is labeled as the client, +and the peer that is uploading the file is labeled as the server. You +may have observed that in some applications, such as in P2P file +sharing, a process can be both a client and a server. Indeed, a process +in a P2P file-sharing system can both upload and download files. +Nevertheless, in the context of any given communication session between +a pair of processes, we can still label one process as the client and +the other process as the server. We define the client and server +processes as follows: In the context of a communication session between +a pair of processes, the process that initiates the communication (that +is, initially contacts the other process at the beginning of the +session) is labeled as the client. The process that waits to be +contacted to begin the session is the server. In the Web, a browser +process initializes contact with a Web server process; hence the browser +process is the client and the Web server process is the server. In P2P +file sharing, when Peer A asks Peer B to send a specific file, Peer A is +the client and Peer B is the server in the context of this specific +communication session. When there's no confusion, we'll sometimes also +use the terminology "client side and server side of an application." At +the end of this chapter, we'll step through simple code for both the +client and server sides of network applications. The Interface Between +the Process and the Computer Network As noted above, most applications +consist of pairs of communicating processes, with the two processes in +each pair sending messages to each other. Any message sent from one +process to another must go through the underlying network. A process +sends messages into, and receives messages from, the network through a +software interface called a socket. Let's consider an analogy to help us +understand processes and sockets. A process is analogous to a house and +its socket is analogous to its door. When a process wants to send a +message to another process on another host, it shoves the message out +its door (socket). This sending process assumes that there is a +transportation infrastructure on the other side of its door that will +transport the message to the door of the destination process. Once the +message arrives at the destination host, the message passes through the +receiving process's door (socket), and the receiving process then acts +on the message. Figure 2.3 illustrates socket communication between two +processes that communicate over the Internet. (Figure 2.3 assumes that +the underlying transport protocol used by the processes is the +Internet's TCP protocol.) As shown in this figure, a socket is the +interface between the application layer and the transport layer within a +host. It is also referred to as the Application Programming Interface +(API) + + between the application and the network, since the socket is the +programming interface with which network applications are built. The +application developer has control of everything on the applicationlayer +side of the socket but has little control of the transport-layer side of +the socket. The only control that the application developer has on the +transport-layer side is (1) the choice of transport protocol and (2) +perhaps the ability to fix a few transport-layer parameters such as +maximum buffer and maximum segment sizes (to be covered in Chapter 3). +Once the application developer chooses a transport protocol (if a choice +is available), the application is built using the transport-layer +services provided by that protocol. We'll explore sockets in some detail +in Section 2.7. Addressing Processes In order to send postal mail to a +particular destination, the destination needs to have an address. +Similarly, in order for a process running on one host to send packets to +a process running on another host, the receiving process needs to have +an address. + +Figure 2.3 Application processes, sockets, and underlying transport +protocol + +To identify the receiving process, two pieces of information need to be +specified: (1) the address of the host and (2) an identifier that +specifies the receiving process in the destination host. In the +Internet, the host is identified by its IP address. We'll discuss IP +addresses in great detail in Chapter 4. For now, all we need to know is +that an IP address is a 32-bit quantity that we can think of as uniquely +identifying the host. In addition to knowing the address of the host to +which a message is destined, the sending process must also identify the +receiving process (more specifically, the receiving socket) running in +the host. This information is needed because in general a host could be +running many network applications. A destination port number serves this +purpose. Popular applications have been + + assigned specific port numbers. For example, a Web server is identified +by port number 80. A mail server process (using the SMTP protocol) is +identified by port number 25. A list of well-known port numbers for all +Internet standard protocols can be found at www.iana.org. We'll examine +port numbers in detail in Chapter 3. + +2.1.3 Transport Services Available to Applications Recall that a socket +is the interface between the application process and the transport-layer +protocol. The application at the sending side pushes messages through +the socket. At the other side of the socket, the transport-layer +protocol has the responsibility of getting the messages to the socket of +the receiving process. Many networks, including the Internet, provide +more than one transport-layer protocol. When you develop an application, +you must choose one of the available transport-layer protocols. How do +you make this choice? Most likely, you would study the services provided +by the available transport-layer protocols, and then pick the protocol +with the services that best match your application's needs. The +situation is similar to choosing either train or airplane transport for +travel between two cities. You have to choose one or the other, and each +transportation mode offers different services. (For example, the train +offers downtown pickup and drop-off, whereas the plane offers shorter +travel time.) What are the services that a transport-layer protocol can +offer to applications invoking it? We can broadly classify the possible +services along four dimensions: reliable data transfer, throughput, +timing, and security. Reliable Data Transfer As discussed in Chapter 1, +packets can get lost within a computer network. For example, a packet +can overflow a buffer in a router, or can be discarded by a host or +router after having some of its bits corrupted. For many +applications---such as electronic mail, file transfer, remote host +access, Web document transfers, and financial applications---data loss +can have devastating consequences (in the latter case, for either the +bank or the customer!). Thus, to support these applications, something +has to be done to guarantee that the data sent by one end of the +application is delivered correctly and completely to the other end of +the application. If a protocol provides such a guaranteed data delivery +service, it is said to provide reliable data transfer. One important +service that a transport-layer protocol can potentially provide to an +application is process-to-process reliable data transfer. When a +transport protocol provides this service, the sending process can just +pass its data into the socket and know with complete confidence that the +data will arrive without errors at the receiving process. When a +transport-layer protocol doesn't provide reliable data transfer, some of +the data sent by the + + sending process may never arrive at the receiving process. This may be +acceptable for loss-tolerant applications, most notably multimedia +applications such as conversational audio/video that can tolerate some +amount of data loss. In these multimedia applications, lost data might +result in a small glitch in the audio/video---not a crucial impairment. +Throughput In Chapter 1 we introduced the concept of available +throughput, which, in the context of a communication session between two +processes along a network path, is the rate at which the sending process +can deliver bits to the receiving process. Because other sessions will +be sharing the bandwidth along the network path, and because these other +sessions will be coming and going, the available throughput can +fluctuate with time. These observations lead to another natural service +that a transportlayer protocol could provide, namely, guaranteed +available throughput at some specified rate. With such a service, the +application could request a guaranteed throughput of r bits/sec, and the +transport protocol would then ensure that the available throughput is +always at least r bits/sec. Such a guaranteed throughput service would +appeal to many applications. For example, if an Internet telephony +application encodes voice at 32 kbps, it needs to send data into the +network and have data delivered to the receiving application at this +rate. If the transport protocol cannot provide this throughput, the +application would need to encode at a lower rate (and receive enough +throughput to sustain this lower coding rate) or may have to give up, +since receiving, say, half of the needed throughput is of little or no +use to this Internet telephony application. Applications that have +throughput requirements are said to be bandwidth-sensitive applications. +Many current multimedia applications are bandwidth sensitive, although +some multimedia applications may use adaptive coding techniques to +encode digitized voice or video at a rate that matches the currently +available throughput. While bandwidth-sensitive applications have +specific throughput requirements, elastic applications can make use of +as much, or as little, throughput as happens to be available. Electronic +mail, file transfer, and Web transfers are all elastic applications. Of +course, the more throughput, the better. There'san adage that says that +one cannot be too rich, too thin, or have too much throughput! Timing A +transport-layer protocol can also provide timing guarantees. As with +throughput guarantees, timing guarantees can come in many shapes and +forms. An example guarantee might be that every bit that the sender +pumps into the socket arrives at the receiver's socket no more than 100 +msec later. Such a service would be appealing to interactive real-time +applications, such as Internet telephony, virtual environments, +teleconferencing, and multiplayer games, all of which require tight +timing constraints on data delivery in order to be effective. (See +Chapter 9, \[Gauthier 1999; Ramjee 1994\].) Long delays in Internet +telephony, for example, tend to result in unnatural pauses in the +conversation; in a multiplayer game or virtual interactive environment, +a long delay between taking an action and seeing the response + + from the environment (for example, from another player at the end of an +end-to-end connection) makes the application feel less realistic. For +non-real-time applications, lower delay is always preferable to higher +delay, but no tight constraint is placed on the end-to-end delays. +Security Finally, a transport protocol can provide an application with +one or more security services. For example, in the sending host, a +transport protocol can encrypt all data transmitted by the sending +process, and in the receiving host, the transport-layer protocol can +decrypt the data before delivering the data to the receiving process. +Such a service would provide confidentiality between the two processes, +even if the data is somehow observed between sending and receiving +processes. A transport protocol can also provide other security services +in addition to confidentiality, including data integrity and end-point +authentication, topics that we'll cover in detail in Chapter 8. + +2.1.4 Transport Services Provided by the Internet Up until this point, +we have been considering transport services that a computer network +could provide in general. Let's now get more specific and examine the +type of transport services provided by the Internet. The Internet (and, +more generally, TCP/IP networks) makes two transport protocols available +to applications, UDP and TCP. When you (as an application developer) +create a new network application for the Internet, one of the first +decisions you have to make is whether to use UDP or TCP. Each of these +protocols offers a different set of services to the invoking +applications. Figure 2.4 shows the service requirements for some +selected applications. TCP Services The TCP service model includes a +connection-oriented service and a reliable data transfer service. When +an application invokes TCP as its transport protocol, the application +receives both of these services from TCP. Connection-oriented service. +TCP has the client and server exchange transport-layer control +information with each other before the application-level messages begin +to flow. This so-called handshaking procedure alerts the client and +server, allowing them to prepare for an onslaught of packets. After the +handshaking phase, a TCP connection is said to exist between the sockets + + Figure 2.4 Requirements of selected network applications + +of the two processes. The connection is a full-duplex connection in that +the two processes can send messages to each other over the connection at +the same time. When the application finishes sending messages, it must +tear down the connection. In Chapter 3 we'll discuss connection-oriented +service in detail and examine how it is implemented. Reliable data +transfer service. The communicating processes can rely on TCP to deliver +all data sent without error and in the proper order. When one side of +the application passes a stream of bytes into a socket, it can count on +TCP to deliver the same stream of bytes to the receiving socket, with no +missing or duplicate bytes. TCP also includes a congestion-control +mechanism, a service for the general welfare of the Internet rather than +for the direct benefit of the communicating processes. The TCP +congestion-control mechanism throttles a sending process (client or +server) when the network is congested between sender and receiver. As we +will see + +FOCUS ON SECURITY SECURING TCP Neither TCP nor UDP provides any +encryption---the data that the sending process passes into its socket is +the same data that travels over the network to the destination process. +So, for example, if the sending process sends a password in cleartext +(i.e., unencrypted) into its socket, the cleartext password will travel +over all the links between sender and receiver, potentially getting +sniffed and discovered at any of the intervening links. Because privacy +and other security issues have become critical for many applications, +the Internet community has developed an enhancement for TCP, called +Secure Sockets Layer (SSL). TCP-enhanced-with-SSL not only + + does everything that traditional TCP does but also provides critical +process-to-process security services, including encryption, data +integrity, and end-point authentication. We emphasize that SSL is not a +third Internet transport protocol, on the same level as TCP and UDP, but +instead is an enhancement of TCP, with the enhancements being +implemented in the application layer. In particular, if an application +wants to use the services of SSL, it needs to include SSL code +(existing, highly optimized libraries and classes) in both the client +and server sides of the application. SSL has its own socket API that is +similar to the traditional TCP socket API. When an application uses SSL, +the sending process passes cleartext data to the SSL socket; SSL in the +sending host then encrypts the data and passes the encrypted data to the +TCP socket. The encrypted data travels over the Internet to the TCP +socket in the receiving process. The receiving socket passes the +encrypted data to SSL, which decrypts the data. Finally, SSL passes the +cleartext data through its SSL socket to the receiving process. We'll +cover SSL in some detail in Chapter 8. + +in Chapter 3, TCP congestion control also attempts to limit each TCP +connection to its fair share of network bandwidth. UDP Services UDP is a +no-frills, lightweight transport protocol, providing minimal services. +UDP is connectionless, so there is no handshaking before the two +processes start to communicate. UDP provides an unreliable data transfer +service---that is, when a process sends a message into a UDP socket, UDP +provides no guarantee that the message will ever reach the receiving +process. Furthermore, messages that do arrive at the receiving process +may arrive out of order. UDP does not include a congestion-control +mechanism, so the sending side of UDP can pump data into the layer below +(the network layer) at any rate it pleases. (Note, however, that the +actual end-to-end throughput may be less than this rate due to the +limited transmission capacity of intervening links or due to +congestion). Services Not Provided by Internet Transport Protocols We +have organized transport protocol services along four dimensions: +reliable data transfer, throughput, timing, and security. Which of these +services are provided by TCP and UDP? We have already noted that TCP +provides reliable end-to-end data transfer. And we also know that TCP +can be easily enhanced at the application layer with SSL to provide +security services. But in our brief description of TCP and UDP, +conspicuously missing was any mention of throughput or timing +guarantees--- services not provided by today's Internet transport +protocols. Does this mean that time-sensitive applications such as +Internet telephony cannot run in today's Internet? The answer is clearly +no---the Internet has been hosting time-sensitive applications for many +years. These applications often work fairly well because + + they have been designed to cope, to the greatest extent possible, with +this lack of guarantee. We'll investigate several of these design tricks +in Chapter 9. Nevertheless, clever design has its limitations when delay +is excessive, or the end-to-end throughput is limited. In summary, +today's Internet can often provide satisfactory service to +time-sensitive applications, but it cannot provide any timing or +throughput guarantees. Figure 2.5 indicates the transport protocols used +by some popular Internet applications. We see that email, remote +terminal access, the Web, and file transfer all use TCP. These +applications have chosen TCP primarily because TCP provides reliable +data transfer, guaranteeing that all data will eventually get to its +destination. Because Internet telephony applications (such as Skype) can +often tolerate some loss but require a minimal rate to be effective, +developers of Internet telephony applications usually prefer to run +their applications over UDP, thereby circumventing TCP's congestion +control mechanism and packet overheads. But because many firewalls are +configured to block (most types of) UDP traffic, Internet telephony +applications often are designed to use TCP as a backup if UDP +communication fails. + +Figure 2.5 Popular Internet applications, their application-layer +protocols, and their underlying transport protocols + +2.1.5 Application-Layer Protocols We have just learned that network +processes communicate with each other by sending messages into sockets. +But how are these messages structured? What are the meanings of the +various fields in the messages? When do the processes send the messages? +These questions bring us into the realm of application-layer protocols. +An application-layer protocol defines how an application's processes, +running on different end systems, pass messages to each other. In +particular, an application-layer protocol defines: + + The types of messages exchanged, for example, request messages and +response messages The syntax of the various message types, such as the +fields in the message and how the fields are delineated The semantics of +the fields, that is, the meaning of the information in the fields Rules +for determining when and how a process sends messages and responds to +messages Some application-layer protocols are specified in RFCs and are +therefore in the public domain. For example, the Web's application-layer +protocol, HTTP (the HyperText Transfer Protocol \[RFC 2616\]), is +available as an RFC. If a browser developer follows the rules of the +HTTP RFC, the browser will be able to retrieve Web pages from any Web +server that has also followed the rules of the HTTP RFC. Many other +application-layer protocols are proprietary and intentionally not +available in the public domain. For example, Skype uses proprietary +application-layer protocols. It is important to distinguish between +network applications and application-layer protocols. An +application-layer protocol is only one piece of a network application +(albeit, a very important piece of the application from our point of +view!). Let's look at a couple of examples. The Web is a client-server +application that allows users to obtain documents from Web servers on +demand. The Web application consists of many components, including a +standard for document formats (that is, HTML), Web browsers (for +example, Firefox and Microsoft Internet Explorer), Web servers (for +example, Apache and Microsoft servers), and an application-layer +protocol. The Web's application-layer protocol, HTTP, defines the format +and sequence of messages exchanged between browser and Web server. Thus, +HTTP is only one piece (albeit, an important piece) of the Web +application. As another example, an Internet e-mail application also has +many components, including mail servers that house user mailboxes; mail +clients (such as Microsoft Outlook) that allow users to read and create +messages; a standard for defining the structure of an e-mail message; +and application-layer protocols that define how messages are passed +between servers, how messages are passed between servers and mail +clients, and how the contents of message headers are to be interpreted. +The principal application-layer protocol for electronic mail is SMTP +(Simple Mail Transfer Protocol) \[RFC 5321\]. Thus, e-mail's principal +application-layer protocol, SMTP, is only one piece (albeit an important +piece) of the e-mail application. + +2.1.6 Network Applications Covered in This Book New public domain and +proprietary Internet applications are being developed every day. Rather +than covering a large number of Internet applications in an encyclopedic +manner, we have chosen to focus on a small number of applications that +are both pervasive and important. In this chapter we discuss five +important applications: the Web, electronic mail, directory service +video streaming, and P2P applications. We first discuss the Web, not +only because it is an enormously popular application, but also because +its application-layer protocol, HTTP, is straightforward and easy to +understand. We then discuss electronic mail, the Internet's first killer +application. E-mail is more complex than the Web in the + + sense that it makes use of not one but several application-layer +protocols. After e-mail, we cover DNS, which provides a directory +service for the Internet. Most users do not interact with DNS directly; +instead, users invoke DNS indirectly through other applications +(including the Web, file transfer, and electronic mail). DNS illustrates +nicely how a piece of core network functionality (network-name to +networkaddress translation) can be implemented at the application layer +in the Internet. We then discuss P2P file sharing applications, and +complete our application study by discussing video streaming on demand, +including distributing stored video over content distribution networks. +In Chapter 9, we'll cover multimedia applications in more depth, +including voice over IP and video conferencing. + + 2.2 The Web and HTTP Until the early 1990s the Internet was used +primarily by researchers, academics, and university students to log in +to remote hosts, to transfer files from local hosts to remote hosts and +vice versa, to receive and send news, and to receive and send electronic +mail. Although these applications were (and continue to be) extremely +useful, the Internet was essentially unknown outside of the academic and +research communities. Then, in the early 1990s, a major new application +arrived on the scene---the World Wide Web \[Berners-Lee 1994\]. The Web +was the first Internet application that caught the general public's eye. +It dramatically changed, and continues to change, how people interact +inside and outside their work environments. It elevated the Internet +from just one of many data networks to essentially the one and only data +network. Perhaps what appeals the most to users is that the Web operates +on demand. Users receive what they want, when they want it. This is +unlike traditional broadcast radio and television, which force users to +tune in when the content provider makes the content available. In +addition to being available on demand, the Web has many other wonderful +features that people love and cherish. It is enormously easy for any +individual to make information available over the Web---everyone can +become a publisher at extremely low cost. Hyperlinks and search engines +help us navigate through an ocean of information. Photos and videos +stimulate our senses. Forms, JavaScript, Java applets, and many other +devices enable us to interact with pages and sites. And the Web and its +protocols serve as a platform for YouTube, Web-based e-mail (such as +Gmail), and most mobile Internet applications, including Instagram and +Google Maps. + +2.2.1 Overview of HTTP The HyperText Transfer Protocol (HTTP), the Web's +application-layer protocol, is at the heart of the Web. It is defined in +\[RFC 1945\] and \[RFC 2616\]. HTTP is implemented in two programs: a +client program and a server program. The client program and server +program, executing on different end systems, talk to each other by +exchanging HTTP messages. HTTP defines the structure of these messages +and how the client and server exchange the messages. Before explaining +HTTP in detail, we should review some Web terminology. A Web page (also +called a document) consists of objects. An object is simply a +file---such as an HTML file, a JPEG image, a Java applet, or a video +clip---that is addressable by a single URL. Most Web pages consist of a +base HTML file and several referenced objects. For example, if a Web +page + + contains HTML text and five JPEG images, then the Web page has six +objects: the base HTML file plus the five images. The base HTML file +references the other objects in the page with the objects' URLs. Each +URL has two components: the hostname of the server that houses the +object and the object's path name. For example, the URL + +http://www.someSchool.edu/someDepartment/picture.gif + +has www.someSchool.edu for a hostname and /someDepartment/picture.gif +for a path name. Because Web browsers (such as Internet Explorer and +Firefox) implement the client side of HTTP, in the context of the Web, +we will use the words browser and client interchangeably. Web servers, +which implement the server side of HTTP, house Web objects, each +addressable by a URL. Popular Web servers include Apache and Microsoft +Internet Information Server. HTTP defines how Web clients request Web +pages from Web servers and how servers transfer Web pages to clients. We +discuss the interaction between client and server in detail later, but +the general idea is illustrated in Figure 2.6. When a user requests a +Web page (for example, clicks on a hyperlink), the browser sends HTTP +request messages for the objects in the page to the server. The server +receives the requests and responds with HTTP response messages that +contain the objects. HTTP uses TCP as its underlying transport protocol +(rather than running on top of UDP). The HTTP client first initiates a +TCP connection with the server. Once the connection is established, the +browser and the server processes access TCP through their socket +interfaces. As described in Section 2.1, on the client side the socket +interface is the door between the client process and the TCP connection; +on the server side it is the door between the server process and the TCP +connection. The client sends HTTP request messages into its socket +interface and receives HTTP response messages from its socket interface. +Similarly, the HTTP server receives request messages + + Figure 2.6 HTTP request-response behavior + +from its socket interface and sends response messages into its socket +interface. Once the client sends a message into its socket interface, +the message is out of the client's hands and is "in the hands" of TCP. +Recall from Section 2.1 that TCP provides a reliable data transfer +service to HTTP. This implies that each HTTP request message sent by a +client process eventually arrives intact at the server; similarly, each +HTTP response message sent by the server process eventually arrives +intact at the client. Here we see one of the great advantages of a +layered architecture---HTTP need not worry about lost data or the +details of how TCP recovers from loss or reordering of data within the +network. That is the job of TCP and the protocols in the lower layers of +the protocol stack. It is important to note that the server sends +requested files to clients without storing any state information about +the client. If a particular client asks for the same object twice in a +period of a few seconds, the server does not respond by saying that it +just served the object to the client; instead, the server resends the +object, as it has completely forgotten what it did earlier. Because an +HTTP server maintains no information about the clients, HTTP is said to +be a stateless protocol. We also remark that the Web uses the +client-server application architecture, as described in Section 2.1. A +Web server is always on, with a fixed IP address, and it services +requests from potentially millions of different browsers. + +2.2.2 Non-Persistent and Persistent Connections In many Internet +applications, the client and server communicate for an extended period +of time, with the client making a series of requests and the server +responding to each of the requests. Depending on the application and on +how the application is being used, the series of requests may be made +back-to-back, periodically at regular intervals, or intermittently. When +this client-server interaction is taking place over TCP, the application +developer needs to make an important decision---should each +request/response pair be sent over a separate TCP connection, or should +all of the requests and their corresponding responses be sent over the +same TCP connection? In the former approach, the application is said to +use non-persistent connections; and in the latter approach, persistent +connections. To gain a deep understanding of this design issue, let's +examine the advantages and disadvantages of persistent connections in +the context of a specific application, namely, HTTP, which can use both +non-persistent connections and persistent connections. Although HTTP +uses persistent connections in its default mode, HTTP clients and +servers can be configured to use non-persistent connections instead. +HTTP with Non-Persistent Connections + + Let's walk through the steps of transferring a Web page from server to +client for the case of nonpersistent connections. Let's suppose the page +consists of a base HTML file and 10 JPEG images, and that all 11 of +these objects reside on the same server. Further suppose the URL for the +base HTML file is + +http://www.someSchool.edu/someDepartment/home.index + +Here is what happens: + +1. The HTTP client process initiates a TCP connection to the server + www.someSchool.edu on port number 80, which is the default port + number for HTTP. Associated with the TCP connection, there will be a + socket at the client and a socket at the server. + +2. The HTTP client sends an HTTP request message to the server via its + socket. The request message includes the path name + /someDepartment/home .index . (We will discuss HTTP messages in some + detail below.) + +3. The HTTP server process receives the request message via its socket, + retrieves the object /someDepartment/home.index from its storage + (RAM or disk), encapsulates the object in an HTTP response message, + and sends the response message to the client via its socket. + +4. The HTTP server process tells TCP to close the TCP connection. (But + TCP doesn't actually terminate the connection until it knows for + sure that the client has received the response message intact.) + +5. The HTTP client receives the response message. The TCP connection + terminates. The message indicates that the encapsulated object is an + HTML file. The client extracts the file from the response message, + examines the HTML file, and finds references to the 10 JPEG objects. + +6. The first four steps are then repeated for each of the referenced + JPEG objects. As the browser receives the Web page, it displays the + page to the user. Two different browsers may interpret (that is, + display to the user) a Web page in somewhat different ways. HTTP has + nothing to do with how a Web page is interpreted by a client. The + HTTP specifications (\[RFC 1945\] and \[RFC 2616\]) define only the + communication protocol between the client HTTP program and the + server HTTP program. The steps above illustrate the use of + non-persistent connections, where each TCP connection is closed + after the server sends the object---the connection does not persist + for other objects. Note that each TCP connection transports exactly + one request message and one response message. Thus, in this example, + when a user requests the Web page, 11 TCP connections are generated. + In the steps described above, we were intentionally vague about + whether the client obtains the 10 + + JPEGs over 10 serial TCP connections, or whether some of the JPEGs are +obtained over parallel TCP connections. Indeed, users can configure +modern browsers to control the degree of parallelism. In their default +modes, most browsers open 5 to 10 parallel TCP connections, and each of +these connections handles one request-response transaction. If the user +prefers, the maximum number of parallel connections can be set to one, +in which case the 10 connections are established serially. As we'll see +in the next chapter, the use of parallel connections shortens the +response time. Before continuing, let's do a back-of-the-envelope +calculation to estimate the amount of time that elapses from when a +client requests the base HTML file until the entire file is received by +the client. To this end, we define the round-trip time (RTT), which is +the time it takes for a small packet to travel from client to server and +then back to the client. The RTT includes packet-propagation delays, +packetqueuing delays in intermediate routers and switches, and +packet-processing delays. (These delays were discussed in Section 1.4.) +Now consider what happens when a user clicks on a hyperlink. As shown in +Figure 2.7, this causes the browser to initiate a TCP connection between +the browser and the Web server; this involves a "three-way +handshake"---the client sends a small TCP segment to the server, the +server acknowledges and responds with a small TCP segment, and, finally, +the client acknowledges back to the server. The first two parts of the +three-way handshake take one RTT. After completing the first two parts +of the handshake, the client sends the HTTP request message combined +with the third part of the three-way handshake (the acknowledgment) into +the TCP connection. Once the request message arrives at + + Figure 2.7 Back-of-the-envelope calculation for the time needed to +request and receive an HTML file + +the server, the server sends the HTML file into the TCP connection. This +HTTP request/response eats up another RTT. Thus, roughly, the total +response time is two RTTs plus the transmission time at the server of +the HTML file. HTTP with Persistent Connections Non-persistent +connections have some shortcomings. First, a brand-new connection must +be established and maintained for each requested object. For each of +these connections, TCP buffers must be allocated and TCP variables must +be kept in both the client and server. This can place a significant +burden on the Web server, which may be serving requests from hundreds of +different clients simultaneously. Second, as we just described, each +object suffers a delivery delay of two RTTs---one RTT to establish the +TCP connection and one RTT to request and receive an object. With HTTP +1.1 persistent connections, the server leaves the TCP connection open +after sending a response. Subsequent requests and responses between the +same client and server can be sent over the same connection. In +particular, an entire Web page (in the example above, the base HTML file +and the 10 images) can be sent over a single persistent TCP connection. +Moreover, multiple Web pages residing on the same server can be sent +from the server to the same client over a single persistent TCP +connection. These requests for objects can be made back-to-back, without +waiting for replies to pending requests (pipelining). Typically, the +HTTP server closes a connection when it isn't used for a certain time (a +configurable timeout interval). When the server receives the +back-to-back requests, it sends the objects back-to-back. The default +mode of HTTP uses persistent connections with pipelining. Most recently, +HTTP/2 \[RFC 7540\] builds on HTTP 1.1 by allowing multiple requests and +replies to be interleaved in the same connection, and a mechanism for +prioritizing HTTP message requests and replies within this connection. +We'll quantitatively compare the performance of non-persistent and +persistent connections in the homework problems of Chapters 2 and 3. You +are also encouraged to see \[Heidemann 1997; Nielsen 1997; RFC 7540\]. + +2.2.3 HTTP Message Format The HTTP specifications \[RFC 1945; RFC 2616; +RFC 7540\] include the definitions of the HTTP message formats. There +are two types of HTTP messages, request messages and response messages, +both of which are discussed below. HTTP Request Message + + Below we provide a typical HTTP request message: + +GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu Connection: +close User-agent: Mozilla/5.0 Accept-language: fr + +We can learn a lot by taking a close look at this simple request +message. First of all, we see that the message is written in ordinary +ASCII text, so that your ordinary computer-literate human being can read +it. Second, we see that the message consists of five lines, each +followed by a carriage return and a line feed. The last line is followed +by an additional carriage return and line feed. Although this particular +request message has five lines, a request message can have many more +lines or as few as one line. The first line of an HTTP request message +is called the request line; the subsequent lines are called the header +lines. The request line has three fields: the method field, the URL +field, and the HTTP version field. The method field can take on several +different values, including GET, POST, HEAD, PUT, and DELETE . The great +majority of HTTP request messages use the GET method. The GET method is +used when the browser requests an object, with the requested object +identified in the URL field. In this example, the browser is requesting +the object /somedir/page.html . The version is selfexplanatory; in this +example, the browser implements version HTTP/1.1. Now let's look at the +header lines in the example. The header line Host: www.someschool.edu +specifies the host on which the object resides. You might think that +this header line is unnecessary, as there is already a TCP connection in +place to the host. But, as we'll see in Section 2.2.5, the information +provided by the host header line is required by Web proxy caches. By +including the Connection: close header line, the browser is telling the +server that it doesn't want to bother with persistent connections; it +wants the server to close the connection after sending the requested +object. The Useragent: header line specifies the user agent, that is, +the browser type that is making the request to the server. Here the user +agent is Mozilla/5.0, a Firefox browser. This header line is useful +because the server can actually send different versions of the same +object to different types of user agents. (Each of the versions is +addressed by the same URL.) Finally, the Accept-language: header +indicates that the user prefers to receive a French version of the +object, if such an object exists on the server; otherwise, the server +should send its default version. The Accept-language: header is just one +of many content negotiation headers available in HTTP. Having looked at +an example, let's now look at the general format of a request message, +as shown in Figure 2.8. We see that the general format closely follows +our earlier example. You may have noticed, + + however, that after the header lines (and the additional carriage return +and line feed) there is an "entity body." The entity body is empty with +the GET method, but is used with the POST method. An HTTP client often +uses the POST method when the user fills out a form---for example, when +a user provides search words to a search engine. With a POST message, +the user is still requesting a Web page from the server, but the +specific contents of the Web page + +Figure 2.8 General format of an HTTP request message + +depend on what the user entered into the form fields. If the value of +the method field is POST , then the entity body contains what the user +entered into the form fields. We would be remiss if we didn't mention +that a request generated with a form does not necessarily use the POST +method. Instead, HTML forms often use the GET method and include the +inputted data (in the form fields) in the requested URL. For example, if +a form uses the GET method, has two fields, and the inputs to the two +fields are monkeys and bananas , then the URL will have the structure +www.somesite.com/animalsearch?monkeys&bananas . In your day-to-day Web +surfing, you have probably noticed extended URLs of this sort. The HEAD +method is similar to the GET method. When a server receives a request +with the HEAD method, it responds with an HTTP message but it leaves out +the requested object. Application developers often use the HEAD method +for debugging. The PUT method is often used in conjunction with Web +publishing tools. It allows a user to upload an object to a specific +path (directory) on a specific Web server. The PUT method is also used +by applications that need to upload objects to Web servers. The DELETE +method allows a user, or an application, to delete an object on a Web +server. HTTP Response Message + + Below we provide a typical HTTP response message. This response message +could be the response to the example request message just discussed. + +HTTP/1.1 200 OK Connection: close Date: Tue, 18 Aug 2015 15:44:04 GMT +Server: Apache/2.2.3 (CentOS) Last-Modified: Tue, 18 Aug 2015 15:11:03 +GMT Content-Length: 6821 Content-Type: text/html (data data data data +data ...) + +Let's take a careful look at this response message. It has three +sections: an initial status line, six header lines, and then the entity +body. The entity body is the meat of the message---it contains the +requested object itself (represented by data data data data data ... ). +The status line has three fields: the protocol version field, a status +code, and a corresponding status message. In this example, the status +line indicates that the server is using HTTP/1.1 and that everything is +OK (that is, the server has found, and is sending, the requested +object). Now let's look at the header lines. The server uses the +Connection: close header line to tell the client that it is going to +close the TCP connection after sending the message. The Date: header +line indicates the time and date when the HTTP response was created and +sent by the server. Note that this is not the time when the object was +created or last modified; it is the time when the server retrieves the +object from its file system, inserts the object into the response +message, and sends the response message. The Server: header line +indicates that the message was generated by an Apache Web server; it is +analogous to the User-agent: header line in the HTTP request message. +The LastModified: header line indicates the time and date when the +object was created or last modified. The Last-Modified: header, which we +will soon cover in more detail, is critical for object caching, both in +the local client and in network cache servers (also known as proxy +servers). The Content-Length: header line indicates the number of bytes +in the object being sent. The Content-Type: header line indicates that +the object in the entity body is HTML text. (The object type is +officially indicated by the Content-Type: header and not by the file +extension.) Having looked at an example, let's now examine the general +format of a response message, which is shown in Figure 2.9. This general +format of the response message matches the previous example of a +response message. Let's say a few additional words about status codes +and their phrases. The status + + code and associated phrase indicate the result of the request. Some +common status codes and associated phrases include: 200 OK: Request +succeeded and the information is returned in the response. 301 Moved +Permanently: Requested object has been permanently moved; the new URL is +specified in Location : header of the response message. The client +software will automatically retrieve the new URL. 400 Bad Request: This +is a generic error code indicating that the request could not be +understood by the server. + +Figure 2.9 General format of an HTTP response message + +404 Not Found: The requested document does not exist on this server. 505 +HTTP Version Not Supported: The requested HTTP protocol version is not +supported by the server. How would you like to see a real HTTP response +message? This is highly recommended and very easy to do! First Telnet +into your favorite Web server. Then type in a one-line request message +for some object that is housed on the server. For example, if you have +access to a command prompt, type: + +Using Wireshark to investigate the HTTP protocol + + telnet gaia.cs.umass.edu 80 GET /kurose_ross/interactive/index.php +HTTP/1.1 Host: gaia.cs.umass.edu + +(Press the carriage return twice after typing the last line.) This opens +a TCP connection to port 80 of the host gaia.cs.umass.edu and then sends +the HTTP request message. You should see a response message that +includes the base HTML file for the interactive homework problems for +this textbook. If you'd rather just see the HTTP message lines and not +receive the object itself, replace GET with HEAD . In this section we +discussed a number of header lines that can be used within HTTP request +and response messages. The HTTP specification defines many, many more +header lines that can be inserted by browsers, Web servers, and network +cache servers. We have covered only a small number of the totality of +header lines. We'll cover a few more below and another small number when +we discuss network Web caching in Section 2.2.5. A highly readable and +comprehensive discussion of the HTTP protocol, including its headers and +status codes, is given in \[Krishnamurthy 2001\]. How does a browser +decide which header lines to include in a request message? How does a +Web server decide which header lines to include in a response message? A +browser will generate header lines as a function of the browser type and +version (for example, an HTTP/1.0 browser will not generate any 1.1 +header lines), the user configuration of the browser (for example, +preferred language), and whether the browser currently has a cached, but +possibly out-of-date, version of the object. Web servers behave +similarly: There are different products, versions, and configurations, +all of which influence which header lines are included in response +messages. + +2.2.4 User-Server Interaction: Cookies We mentioned above that an HTTP +server is stateless. This simplifies server design and has permitted +engineers to develop high-performance Web servers that can handle +thousands of simultaneous TCP connections. However, it is often +desirable for a Web site to identify users, either because the server +wishes to restrict user access or because it wants to serve content as a +function of the user identity. For these purposes, HTTP uses cookies. +Cookies, defined in \[RFC 6265\], allow sites to keep track of users. +Most major commercial Web sites use cookies today. As shown in Figure +2.10, cookie technology has four components: (1) a cookie header line in +the HTTP response message; (2) a cookie header line in the HTTP request +message; (3) a cookie file kept on the + + user's end system and managed by the user's browser; and (4) a back-end +database at the Web site. Using Figure 2.10, let's walk through an +example of how cookies work. Suppose Susan, who always accesses the Web +using Internet Explorer from her home PC, contacts Amazon.com for the +first time. Let us suppose that in the past she has already visited the +eBay site. When the request comes into the Amazon Web server, the server +creates a unique identification number and creates an entry in its +backend database that is indexed by the identification number. The +Amazon Web server then responds to Susan's browser, including in the +HTTP response a Set-cookie: header, which contains the identification +number. For example, the header line might be: + +Set-cookie: 1678 + +When Susan's browser receives the HTTP response message, it sees the +Set-cookie: header. The browser then appends a line to the special +cookie file that it manages. This line includes the hostname of the +server and the identification number in the Set-cookie: header. Note +that the cookie file already has an entry for eBay, since Susan has +visited that site in the past. As Susan continues to browse the Amazon +site, each time she requests a Web page, her browser consults her cookie +file, extracts her identification number for this site, and puts a +cookie header line that + + Figure 2.10 Keeping user state with cookies + +includes the identification number in the HTTP request. Specifically, +each of her HTTP requests to the Amazon server includes the header line: + +Cookie: 1678 + +In this manner, the Amazon server is able to track Susan's activity at +the Amazon site. Although the Amazon Web site does not necessarily know +Susan's name, it knows exactly which pages user 1678 visited, in which +order, and at what times! Amazon uses cookies to provide its shopping +cart service--- Amazon can maintain a list of all of Susan's intended +purchases, so that she can pay for them + + collectively at the end of the session. If Susan returns to Amazon's +site, say, one week later, her browser will continue to put the header +line Cookie: 1678 in the request messages. Amazon also recommends +products to Susan based on Web pages she has visited at Amazon in the +past. If Susan also registers herself with Amazon--- providing full +name, e-mail address, postal address, and credit card +information---Amazon can then include this information in its database, +thereby associating Susan's name with her identification number (and all +of the pages she has visited at the site in the past!). This is how +Amazon and other e-commerce sites provide "one-click shopping"---when +Susan chooses to purchase an item during a subsequent visit, she doesn't +need to re-enter her name, credit card number, or address. From this +discussion we see that cookies can be used to identify a user. The first +time a user visits a site, the user can provide a user identification +(possibly his or her name). During the subsequent sessions, the browser +passes a cookie header to the server, thereby identifying the user to +the server. Cookies can thus be used to create a user session layer on +top of stateless HTTP. For example, when a user logs in to a Web-based +e-mail application (such as Hotmail), the browser sends cookie +information to the server, permitting the server to identify the user +throughout the user's session with the application. Although cookies +often simplify the Internet shopping experience for the user, they are +controversial because they can also be considered as an invasion of +privacy. As we just saw, using a combination of cookies and +user-supplied account information, a Web site can learn a lot about a +user and potentially sell this information to a third party. Cookie +Central \[Cookie Central 2016\] includes extensive information on the +cookie controversy. + +2.2.5 Web Caching A Web cache---also called a proxy server---is a +network entity that satisfies HTTP requests on the behalf of an origin +Web server. The Web cache has its own disk storage and keeps copies of +recently requested objects in this storage. As shown in Figure 2.11, a +user's browser can be configured so that all of the user's HTTP requests +are first directed to the Web cache. Once a browser is configured, each +browser request for an object is first directed to the Web cache. As an +example, suppose a browser is requesting the object +http://www.someschool.edu/campus.gif . Here is what happens: + +1. The browser establishes a TCP connection to the Web cache and sends + an HTTP request for the object to the Web cache. + +2. The Web cache checks to see if it has a copy of the object stored + locally. If it does, the Web cache returns the object within an HTTP + response message to the client browser. + + Figure 2.11 Clients requesting objects through a Web cache + +3. If the Web cache does not have the object, the Web cache opens a TCP + connection to the origin server, that is, to www.someschool.edu . + The Web cache then sends an HTTP request for the object into the + cache-to-server TCP connection. After receiving this request, the + origin server sends the object within an HTTP response to the Web + cache. + +4. When the Web cache receives the object, it stores a copy in its + local storage and sends a copy, within an HTTP response message, to + the client browser (over the existing TCP connection between the + client browser and the Web cache). Note that a cache is both a + server and a client at the same time. When it receives requests from + and sends responses to a browser, it is a server. When it sends + requests to and receives responses from an origin server, it is a + client. Typically a Web cache is purchased and installed by an ISP. + For example, a university might install a cache on its campus + network and configure all of the campus browsers to point to the + cache. Or a major residential ISP (such as Comcast) might install + one or more caches in its network and preconfigure its shipped + browsers to point to the installed caches. Web caching has seen + deployment in the Internet for two reasons. First, a Web cache can + substantially reduce the response time for a client request, + particularly if the bottleneck bandwidth between the client and the + origin server is much less than the bottleneck bandwidth between the + client and the cache. If there is a high-speed connection between + the client and the cache, as there often is, and if the cache has + the requested object, then the cache will be able to deliver the + object rapidly to the client. Second, as we will soon illustrate + with an example, Web caches can substantially reduce traffic on an + institution's access link to the Internet. By reducing traffic, the + institution (for example, a company or a university) does not have + to upgrade bandwidth as quickly, thereby reducing costs. + Furthermore, Web caches can + + substantially reduce Web traffic in the Internet as a whole, thereby +improving performance for all applications. To gain a deeper +understanding of the benefits of caches, let's consider an example in +the context of Figure 2.12. This figure shows two networks---the +institutional network and the rest of the public Internet. The +institutional network is a high-speed LAN. A router in the institutional +network and a router in the Internet are connected by a 15 Mbps link. +The origin servers are attached to the Internet but are located all over +the globe. Suppose that the average object size is 1 Mbits and that the +average request rate from the institution's browsers to the origin +servers is 15 requests per second. Suppose that the HTTP request +messages are negligibly small and thus create no traffic in the networks +or in the access link (from institutional router to Internet router). +Also suppose that the amount of time it takes from when the router on +the Internet side of the access link in Figure 2.12 forwards an HTTP +request (within an IP datagram) until it receives the response +(typically within many IP datagrams) is two seconds on average. +Informally, we refer to this last delay as the "Internet delay." + +Figure 2.12 Bottleneck between an institutional network and the Internet + +The total response time---that is, the time from the browser's request +of an object until its receipt of the object---is the sum of the LAN +delay, the access delay (that is, the delay between the two routers), +and + + the Internet delay. Let's now do a very crude calculation to estimate +this delay. The traffic intensity on the LAN (see Section 1.4.2) is (15 +requests/sec)⋅(1 Mbits/request)/(100 Mbps)=0.15 whereas the traffic +intensity on the access link (from the Internet router to institution +router) is (15 requests/sec)⋅(1 Mbits/request)/(15 Mbps)=1 A traffic +intensity of 0.15 on a LAN typically results in, at most, tens of +milliseconds of delay; hence, we can neglect the LAN delay. However, as +discussed in Section 1.4.2, as the traffic intensity approaches 1 (as is +the case of the access link in Figure 2.12), the delay on a link becomes +very large and grows without bound. Thus, the average response time to +satisfy requests is going to be on the order of minutes, if not more, +which is unacceptable for the institution's users. Clearly something +must be done. One possible solution is to increase the access rate from +15 Mbps to, say, 100 Mbps. This will lower the traffic intensity on the +access link to 0.15, which translates to negligible delays between the +two routers. In this case, the total response time will roughly be two +seconds, that is, the Internet delay. But this solution also means that +the institution must upgrade its access link from 15 Mbps to 100 Mbps, a +costly proposition. Now consider the alternative solution of not +upgrading the access link but instead installing a Web cache in the +institutional network. This solution is illustrated in Figure 2.13. Hit +rates---the fraction of requests that are satisfied by a cache--- +typically range from 0.2 to 0.7 in practice. For illustrative purposes, +let's suppose that the cache provides a hit rate of 0.4 for this +institution. Because the clients and the cache are connected to the same +high-speed LAN, 40 percent of the requests will be satisfied almost +immediately, say, within 10 milliseconds, by the cache. Nevertheless, +the remaining 60 percent of the requests still need to be satisfied by +the origin servers. But with only 60 percent of the requested objects +passing through the access link, the traffic intensity on the access +link is reduced from 1.0 to 0.6. Typically, a traffic intensity less +than 0.8 corresponds to a small delay, say, tens of milliseconds, on a +15 Mbps link. This delay is negligible compared with the two-second +Internet delay. Given these considerations, average delay therefore is +0.4⋅(0.01 seconds)+0.6⋅(2.01 seconds) which is just slightly greater +than 1.2 seconds. Thus, this second solution provides an even lower +response time than the first solution, and it doesn't require the +institution + + Figure 2.13 Adding a cache to the institutional network + +to upgrade its link to the Internet. The institution does, of course, +have to purchase and install a Web cache. But this cost is low---many +caches use public-domain software that runs on inexpensive PCs. Through +the use of Content Distribution Networks (CDNs), Web caches are +increasingly playing an important role in the Internet. A CDN company +installs many geographically distributed caches throughout the Internet, +thereby localizing much of the traffic. There are shared CDNs (such as +Akamai and Limelight) and dedicated CDNs (such as Google and Netflix). +We will discuss CDNs in more detail in Section 2.6. The Conditional GET +Although caching can reduce user-perceived response times, it introduces +a new problem---the copy of an object residing in the cache may be +stale. In other words, the object housed in the Web server may have been +modified since the copy was cached at the client. Fortunately, HTTP has +a mechanism that allows a cache to verify that its objects are up to +date. This mechanism is called the conditional GET. + + An HTTP request message is a so-called conditional GET message if (1) +the request message uses the GET method and (2) the request message +includes an If-Modified-Since: header line. To illustrate how the +conditional GET operates, let's walk through an example. First, on the +behalf of a requesting browser, a proxy cache sends a request message to +a Web server: + +GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecuisine.com + +Second, the Web server sends a response message with the requested +object to the cache: + +HTTP/1.1 200 OK Date: Sat, 3 Oct 2015 15:39:29 Server: Apache/1.3.0 +(Unix) Last-Modified: Wed, 9 Sep 2015 09:23:24 Content-Type: image/gif +(data data data data data ...) + +The cache forwards the object to the requesting browser but also caches +the object locally. Importantly, the cache also stores the last-modified +date along with the object. Third, one week later, another browser +requests the same object via the cache, and the object is still in the +cache. Since this object may have been modified at the Web server in the +past week, the cache performs an up-to-date check by issuing a +conditional GET. Specifically, the cache sends: + +GET /fruit/kiwi.gif HTTP/1.1 Host: www.exotiquecuisine.com +If-modified-since: Wed, 9 Sep 2015 09:23:24 + +Note that the value of the If-modified-since: header line is exactly +equal to the value of the Last-Modified: header line that was sent by +the server one week ago. This conditional GET is telling the server to +send the object only if the object has been modified since the specified +date. Suppose the object has not been modified since 9 Sep 2015 +09:23:24. Then, fourth, the Web server sends a response message to the +cache: + + HTTP/1.1 304 Not Modified Date: Sat, 10 Oct 2015 15:39:29 Server: +Apache/1.3.0 (Unix) (empty entity body) + +We see that in response to the conditional GET, the Web server still +sends a response message but does not include the requested object in +the response message. Including the requested object would only waste +bandwidth and increase user-perceived response time, particularly if the +object is large. Note that this last response message has 304 Not +Modified in the status line, which tells the cache that it can go ahead +and forward its (the proxy cache's) cached copy of the object to the +requesting browser. This ends our discussion of HTTP, the first Internet +protocol (an application-layer protocol) that we've studied in detail. +We've seen the format of HTTP messages and the actions taken by the Web +client and server as these messages are sent and received. We've also +studied a bit of the Web's application infrastructure, including caches, +cookies, and back-end databases, all of which are tied in some way to +the HTTP protocol. + + 2.3 Electronic Mail in the Internet Electronic mail has been around +since the beginning of the Internet. It was the most popular application +when the Internet was in its infancy \[Segaller 1998\], and has become +more elaborate and powerful over the years. It remains one of the +Internet's most important and utilized applications. As with ordinary +postal mail, e-mail is an asynchronous communication medium---people +send and read messages when it is convenient for them, without having to +coordinate with other people's schedules. In contrast with postal mail, +electronic mail is fast, easy to distribute, and inexpensive. Modern +e-mail has many powerful features, including messages with attachments, +hyperlinks, HTML-formatted text, and embedded photos. In this section, +we examine the application-layer protocols that are at the heart of +Internet e-mail. But before we jump into an in-depth discussion of these +protocols, let's take a high-level view of the Internet mail system and +its key components. Figure 2.14 presents a high-level view of the +Internet mail system. We see from this diagram that it has three major +components: user agents, mail servers, and the Simple Mail Transfer +Protocol (SMTP). We now describe each of these components in the context +of a sender, Alice, sending an e-mail message to a recipient, Bob. User +agents allow users to read, reply to, forward, save, and compose +messages. Microsoft Outlook and Apple Mail are examples of user agents +for e-mail. When Alice is finished composing her message, her user agent +sends the message to her mail server, where the message is placed in the +mail server's outgoing message queue. When Bob wants to read a message, +his user agent retrieves the message from his mailbox in his mail +server. Mail servers form the core of the e-mail infrastructure. Each +recipient, such as Bob, has a mailbox located in one of the mail +servers. Bob's mailbox manages and + + Figure 2.14 A high-level view of the Internet e-mail system + +maintains the messages that have been sent to him. A typical message +starts its journey in the sender's user agent, travels to the sender's +mail server, and travels to the recipient's mail server, where it is +deposited in the recipient's mailbox. When Bob wants to access the +messages in his mailbox, the mail server containing his mailbox +authenticates Bob (with usernames and passwords). Alice's mail server +must also deal with failures in Bob's mail server. If Alice's server +cannot deliver mail to Bob's server, Alice's server holds the message in +a message queue and attempts to transfer the message later. Reattempts +are often done every 30 minutes or so; if there is no success after +several days, the server removes the message and notifies the sender +(Alice) with an e-mail message. SMTP is the principal application-layer +protocol for Internet electronic mail. It uses the reliable data +transfer service of TCP to transfer mail from the sender's mail server +to the recipient's mail server. As with most application-layer +protocols, SMTP has two sides: a client side, which executes on the +sender's mail server, and a server side, which executes on the +recipient's mail server. Both the client and server sides of SMTP run on +every mail server. When a mail server sends mail to other mail servers, +it acts as an SMTP client. When a mail server receives mail from other +mail servers, it acts as an SMTP server. + + 2.3.1 SMTP SMTP, defined in RFC 5321, is at the heart of Internet +electronic mail. As mentioned above, SMTP transfers messages from +senders' mail servers to the recipients' mail servers. SMTP is much +older than HTTP. (The original SMTP RFC dates back to 1982, and SMTP was +around long before that.) Although SMTP has numerous wonderful +qualities, as evidenced by its ubiquity in the Internet, it is +nevertheless a legacy technology that possesses certain archaic +characteristics. For example, it restricts the body (not just the +headers) of all mail messages to simple 7-bit ASCII. This restriction +made sense in the early 1980s when transmission capacity was scarce and +no one was e-mailing large attachments or large image, audio, or video +files. But today, in the multimedia era, the 7-bit ASCII restriction is +a bit of a pain ---it requires binary multimedia data to be encoded to +ASCII before being sent over SMTP; and it requires the corresponding +ASCII message to be decoded back to binary after SMTP transport. Recall +from Section 2.2 that HTTP does not require multimedia data to be ASCII +encoded before transfer. To illustrate the basic operation of SMTP, +let's walk through a common scenario. Suppose Alice wants to send Bob a +simple ASCII message. + +1. Alice invokes her user agent for e-mail, provides Bob's e-mail + address (for example, bob@someschool.edu ), composes a message, and + instructs the user agent to send the message. + +2. Alice's user agent sends the message to her mail server, where it is + placed in a message queue. + +3. The client side of SMTP, running on Alice's mail server, sees the + message in the message queue. It opens a TCP connection to an SMTP + server, running on Bob's mail server. + +4. After some initial SMTP handshaking, the SMTP client sends Alice's + message into the TCP connection. + +5. At Bob's mail server, the server side of SMTP receives the message. + Bob's mail server then places the message in Bob's mailbox. + +6. Bob invokes his user agent to read the message at his convenience. + The scenario is summarized in Figure 2.15. It is important to + observe that SMTP does not normally use intermediate mail servers + for sending mail, even when the two mail servers are located at + opposite ends of the world. If Alice's server is in Hong Kong and + Bob's server is in St. Louis, the TCP + + Figure 2.15 Alice sends a message to Bob + +connection is a direct connection between the Hong Kong and St. Louis +servers. In particular, if Bob's mail server is down, the message +remains in Alice's mail server and waits for a new attempt---the message +does not get placed in some intermediate mail server. Let's now take a +closer look at how SMTP transfers a message from a sending mail server +to a receiving mail server. We will see that the SMTP protocol has many +similarities with protocols that are used for face-to-face human +interaction. First, the client SMTP (running on the sending mail server +host) has TCP establish a connection to port 25 at the server SMTP +(running on the receiving mail server host). If the server is down, the +client tries again later. Once this connection is established, the +server and client perform some application-layer handshaking---just as +humans often introduce themselves before transferring information from +one to another, SMTP clients and servers introduce themselves before +transferring information. During this SMTP handshaking phase, the SMTP +client indicates the email address of the sender (the person who +generated the message) and the e-mail address of the recipient. Once the +SMTP client and server have introduced themselves to each other, the +client sends the message. SMTP can count on the reliable data transfer +service of TCP to get the message to the server without errors. The +client then repeats this process over the same TCP connection if it has +other messages to send to the server; otherwise, it instructs TCP to +close the connection. Let's next take a look at an example transcript of +messages exchanged between an SMTP client (C) and an SMTP server (S). +The hostname of the client is crepes.fr and the hostname of the server +is hamburger.edu . The ASCII text lines prefaced with C: are exactly the +lines the client sends into its TCP socket, and the ASCII text lines +prefaced with S: are exactly the lines the server sends into its TCP +socket. The following transcript begins as soon as the TCP connection is +established. + +S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, +pleased to meet you + + C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr ... Sender ok +C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient +ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do +you like ketchup? C: How about pickles? C: . S: 250 Message accepted +for delivery C: QUIT S: 221 hamburger.edu closing connection + +In the example above, the client sends a message (" Do you like ketchup? +How about pickles? ") from mail server crepes.fr to mail server +hamburger.edu . As part of the dialogue, the client issued five +commands: HELO (an abbreviation for HELLO), MAIL FROM , RCPT TO , DATA , +and QUIT . These commands are self-explanatory. The client also sends a +line consisting of a single period, which indicates the end of the +message to the server. (In ASCII jargon, each message ends with +CRLF.CRLF , where CR and LF stand for carriage return and line feed, +respectively.) The server issues replies to each command, with each +reply having a reply code and some (optional) Englishlanguage +explanation. We mention here that SMTP uses persistent connections: If +the sending mail server has several messages to send to the same +receiving mail server, it can send all of the messages over the same TCP +connection. For each message, the client begins the process with a new +MAIL FROM: crepes.fr , designates the end of message with an isolated +period, and issues QUIT only after all messages have been sent. It is +highly recommended that you use Telnet to carry out a direct dialogue +with an SMTP server. To do this, issue + +telnet serverName 25 + +where serverName is the name of a local mail server. When you do this, +you are simply establishing a TCP connection between your local host and +the mail server. After typing this line, you should immediately receive +the 220 reply from the server. Then issue the SMTP commands HELO , MAIL +FROM , RCPT TO , DATA , CRLF.CRLF , and QUIT at the appropriate times. +It is also highly recommended that you do Programming Assignment 3 at +the end of this chapter. In that assignment, you'll build a simple user +agent that implements the client side of SMTP. It will allow you to send +an e- + + mail message to an arbitrary recipient via a local mail server. + +2.3.2 Comparison with HTTP Let's now briefly compare SMTP with HTTP. +Both protocols are used to transfer files from one host to another: HTTP +transfers files (also called objects) from a Web server to a Web client +(typically a browser); SMTP transfers files (that is, e-mail messages) +from one mail server to another mail server. When transferring the +files, both persistent HTTP and SMTP use persistent connections. Thus, +the two protocols have common characteristics. However, there are +important differences. First, HTTP is mainly a pull protocol---someone +loads information on a Web server and users use HTTP to pull the +information from the server at their convenience. In particular, the TCP +connection is initiated by the machine that wants to receive the file. +On the other hand, SMTP is primarily a push protocol---the sending mail +server pushes the file to the receiving mail server. In particular, the +TCP connection is initiated by the machine that wants to send the file. +A second difference, which we alluded to earlier, is that SMTP requires +each message, including the body of each message, to be in 7-bit ASCII +format. If the message contains characters that are not 7-bit ASCII (for +example, French characters with accents) or contains binary data (such +as an image file), then the message has to be encoded into 7-bit ASCII. +HTTP data does not impose this restriction. A third important difference +concerns how a document consisting of text and images (along with +possibly other media types) is handled. As we learned in Section 2.2, +HTTP encapsulates each object in its own HTTP response message. SMTP +places all of the message's objects into one message. + +2.3.3 Mail Message Formats When Alice writes an ordinary snail-mail +letter to Bob, she may include all kinds of peripheral header +information at the top of the letter, such as Bob's address, her own +return address, and the date. Similarly, when an e-mail message is sent +from one person to another, a header containing peripheral information +precedes the body of the message itself. This peripheral information is +contained in a series of header lines, which are defined in RFC 5322. +The header lines and the body of the message are separated by a blank +line (that is, by CRLF ). RFC 5322 specifies the exact format for mail +header lines as well as their semantic interpretations. As with HTTP, +each header line contains readable text, consisting of a keyword +followed by a colon followed by a value. Some of the keywords are +required and others are optional. Every header must have a From: header +line and a To: header line; a header may include a Subject: header line +as well as other optional header lines. It is important to note that +these header lines are different from the SMTP commands we studied in +Section 2.4.1 (even though + + they contain some common words such as "from" and "to"). The commands in +that section were part of the SMTP handshaking protocol; the header +lines examined in this section are part of the mail message itself. A +typical message header looks like this: + +From: alice@crepes.fr To: bob@hamburger.edu Subject: Searching for the +meaning of life. + +After the message header, a blank line follows; then the message body +(in ASCII) follows. You should use Telnet to send a message to a mail +server that contains some header lines, including the Subject: header +line. To do this, issue telnet serverName 25, as discussed in Section +2.4.1. + +2.3.4 Mail Access Protocols Once SMTP delivers the message from Alice's +mail server to Bob's mail server, the message is placed in Bob's +mailbox. Throughout this discussion we have tacitly assumed that Bob +reads his mail by logging onto the server host and then executing a mail +reader that runs on that host. Up until the early 1990s this was the +standard way of doing things. But today, mail access uses a +client-server architecture---the typical user reads e-mail with a client +that executes on the user's end system, for example, on an office PC, a +laptop, or a smartphone. By executing a mail client on a local PC, users +enjoy a rich set of features, including the ability to view multimedia +messages and attachments. Given that Bob (the recipient) executes his +user agent on his local PC, it is natural to consider placing a mail +server on his local PC as well. With this approach, Alice's mail server +would dialogue directly with Bob's PC. There is a problem with this +approach, however. Recall that a mail server manages mailboxes and runs +the client and server sides of SMTP. If Bob's mail server were to reside +on his local PC, then Bob's PC would have to remain always on, and +connected to the Internet, in order to receive new mail, which can +arrive at any time. This is impractical for many Internet users. +Instead, a typical user runs a user agent on the local PC but accesses +its mailbox stored on an always-on shared mail server. This mail server +is shared with other users and is typically maintained by the user's ISP +(for example, university or company). Now let's consider the path an +e-mail message takes when it is sent from Alice to Bob. We just learned +that at some point along the path the e-mail message needs to be +deposited in Bob's mail server. This could be done simply by having +Alice's user agent send the message directly to Bob's mail server. And + + this could be done with SMTP---indeed, SMTP has been designed for +pushing e-mail from one host to another. However, typically the sender's +user agent does not dialogue directly with the recipient's mail server. +Instead, as shown in Figure 2.16, Alice's user agent uses SMTP to push +the e-mail message into her mail server, then Alice's mail server uses +SMTP (as an SMTP client) to relay the e-mail message to Bob's mail +server. Why the two-step procedure? Primarily because without relaying +through Alice's mail server, Alice's user agent doesn't have any +recourse to an unreachable destination + +Figure 2.16 E-mail protocols and their communicating entities + +mail server. By having Alice first deposit the e-mail in her own mail +server, Alice's mail server can repeatedly try to send the message to +Bob's mail server, say every 30 minutes, until Bob's mail server becomes +operational. (And if Alice's mail server is down, then she has the +recourse of complaining to her system administrator!) The SMTP RFC +defines how the SMTP commands can be used to relay a message across +multiple SMTP servers. But there is still one missing piece to the +puzzle! How does a recipient like Bob, running a user agent on his local +PC, obtain his messages, which are sitting in a mail server within Bob's +ISP? Note that Bob's user agent can't use SMTP to obtain the messages +because obtaining the messages is a pull operation, whereas SMTP is a +push protocol. The puzzle is completed by introducing a special mail +access protocol that transfers messages from Bob's mail server to his +local PC. There are currently a number of popular mail access protocols, +including Post Office Protocol---Version 3 (POP3), Internet Mail Access +Protocol (IMAP), and HTTP. Figure 2.16 provides a summary of the +protocols that are used for Internet mail: SMTP is used to transfer mail +from the sender's mail server to the recipient's mail server; SMTP is +also used to transfer mail from the sender's user agent to the sender's +mail server. A mail access protocol, such as POP3, is used to transfer +mail from the recipient's mail server to the recipient's user agent. +POP3 POP3 is an extremely simple mail access protocol. It is defined in +\[RFC 1939\], which is short and quite readable. Because the protocol is +so simple, its functionality is rather limited. POP3 begins when the +user agent (the client) opens a TCP connection to the mail server (the +server) on port 110. With the TCP + + connection established, POP3 progresses through three phases: +authorization, transaction, and update. During the first phase, +authorization, the user agent sends a username and a password (in the +clear) to authenticate the user. During the second phase, transaction, +the user agent retrieves messages; also during this phase, the user +agent can mark messages for deletion, remove deletion marks, and obtain +mail statistics. The third phase, update, occurs after the client has +issued the quit command, ending the POP3 session; at this time, the mail +server deletes the messages that were marked for deletion. In a POP3 +transaction, the user agent issues commands, and the server responds to +each command with a reply. There are two possible responses: +OK +(sometimes followed by server-to-client data), used by the server to +indicate that the previous command was fine; and -ERR , used by the +server to indicate that something was wrong with the previous command. +The authorization phase has two principal commands: user +`<username>`{=html} and pass `<password>`{=html} . To illustrate these +two commands, we suggest that you Telnet directly into a POP3 server, +using port 110, and issue these commands. Suppose that mailServer is the +name of your mail server. You will see something like: + +telnet mailServer 110 +OK POP3 server ready user bob +OK pass hungry +OK +user successfully logged on + +If you misspell a command, the POP3 server will reply with an -ERR +message. Now let's take a look at the transaction phase. A user agent +using POP3 can often be configured (by the user) to "download and +delete" or to "download and keep." The sequence of commands issued by a +POP3 user agent depends on which of these two modes the user agent is +operating in. In the downloadand-delete mode, the user agent will issue +the list , retr , and dele commands. As an example, suppose the user has +two messages in his or her mailbox. In the dialogue below, C: (standing +for client) is the user agent and S: (standing for server) is the mail +server. The transaction will look something like: + +C: list S: 1 498 S: 2 912 + + S: . C: retr 1 S: (blah blah ... S: ................. S: ..........blah) +S: . C: dele 1 C: retr 2 S: (blah blah ... S: ................. S: +..........blah) S: . C: dele 2 C: quit S: +OK POP3 server signing off + +The user agent first asks the mail server to list the size of each of +the stored messages. The user agent then retrieves and deletes each +message from the server. Note that after the authorization phase, the +user agent employed only four commands: list , retr , dele , and quit . +The syntax for these commands is defined in RFC 1939. After processing +the quit command, the POP3 server enters the update phase and removes +messages 1 and 2 from the mailbox. A problem with this +download-and-delete mode is that the recipient, Bob, may be nomadic and +may want to access his mail messages from multiple machines, for +example, his office PC, his home PC, and his portable computer. The +download-and-delete mode partitions Bob's mail messages over these three +machines; in particular, if Bob first reads a message on his office PC, +he will not be able to reread the message from his portable at home +later in the evening. In the download-and-keep mode, the user agent +leaves the messages on the mail server after downloading them. In this +case, Bob can reread messages from different machines; he can access a +message from work and access it again later in the week from home. +During a POP3 session between a user agent and the mail server, the POP3 +server maintains some state information; in particular, it keeps track +of which user messages have been marked deleted. However, the POP3 +server does not carry state information across POP3 sessions. This lack +of state information across sessions greatly simplifies the +implementation of a POP3 server. IMAP With POP3 access, once Bob has +downloaded his messages to the local machine, he can create mail + + folders and move the downloaded messages into the folders. Bob can then +delete messages, move messages across folders, and search for messages +(by sender name or subject). But this paradigm--- namely, folders and +messages in the local machine---poses a problem for the nomadic user, +who would prefer to maintain a folder hierarchy on a remote server that +can be accessed from any computer. This is not possible with POP3---the +POP3 protocol does not provide any means for a user to create remote +folders and assign messages to folders. To solve this and other +problems, the IMAP protocol, defined in \[RFC 3501\], was invented. Like +POP3, IMAP is a mail access protocol. It has many more features than +POP3, but it is also significantly more complex. (And thus the client +and server side implementations are significantly more complex.) An IMAP +server will associate each message with a folder; when a message first +arrives at the server, it is associated with the recipient's INBOX +folder. The recipient can then move the message into a new, user-created +folder, read the message, delete the message, and so on. The IMAP +protocol provides commands to allow users to create folders and move +messages from one folder to another. IMAP also provides commands that +allow users to search remote folders for messages matching specific +criteria. Note that, unlike POP3, an IMAP server maintains user state +information across IMAP sessions---for example, the names of the folders +and which messages are associated with which folders. Another important +feature of IMAP is that it has commands that permit a user agent to +obtain components of messages. For example, a user agent can obtain just +the message header of a message or just one part of a multipart MIME +message. This feature is useful when there is a low-bandwidth connection +(for example, a slow-speed modem link) between the user agent and its +mail server. With a low-bandwidth connection, the user may not want to +download all of the messages in its mailbox, particularly avoiding long +messages that might contain, for example, an audio or video clip. +Web-Based E-Mail More and more users today are sending and accessing +their e-mail through their Web browsers. Hotmail introduced Web-based +access in the mid 1990s. Now Web-based e-mail is also provided by +Google, Yahoo!, as well as just about every major university and +corporation. With this service, the user agent is an ordinary Web +browser, and the user communicates with its remote mailbox via HTTP. +When a recipient, such as Bob, wants to access a message in his mailbox, +the e-mail message is sent from Bob's mail server to Bob's browser using +the HTTP protocol rather than the POP3 or IMAP protocol. When a sender, +such as Alice, wants to send an e-mail message, the e-mail message is +sent from her browser to her mail server over HTTP rather than over +SMTP. Alice's mail server, however, still sends messages to, and +receives messages from, other mail servers using SMTP. + + 2.4 DNS---The Internet's Directory Service We human beings can be +identified in many ways. For example, we can be identified by the names +that appear on our birth certificates. We can be identified by our +social security numbers. We can be identified by our driver's license +numbers. Although each of these identifiers can be used to identify +people, within a given context one identifier may be more appropriate +than another. For example, the computers at the IRS (the infamous +tax-collecting agency in the United States) prefer to use fixed-length +social security numbers rather than birth certificate names. On the +other hand, ordinary people prefer the more mnemonic birth certificate +names rather than social security numbers. (Indeed, can you imagine +saying, "Hi. My name is 132-67-9875. Please meet my husband, +178-87-1146.") Just as humans can be identified in many ways, so too can +Internet hosts. One identifier for a host is its hostname. +Hostnames---such as www.facebook.com, www.google.com , gaia.cs.umass.edu +---are mnemonic and are therefore appreciated by humans. However, +hostnames provide little, if any, information about the location within +the Internet of the host. (A hostname such as www.eurecom.fr , which +ends with the country code .fr , tells us that the host is probably in +France, but doesn't say much more.) Furthermore, because hostnames can +consist of variable-length alphanumeric characters, they would be +difficult to process by routers. For these reasons, hosts are also +identified by so-called IP addresses. We discuss IP addresses in some +detail in Chapter 4, but it is useful to say a few brief words about +them now. An IP address consists of four bytes and has a rigid +hierarchical structure. An IP address looks like 121.7.106.83 , where +each period separates one of the bytes expressed in decimal notation +from 0 to 255. An IP address is hierarchical because as we scan the +address from left to right, we obtain more and more specific information +about where the host is located in the Internet (that is, within which +network, in the network of networks). Similarly, when we scan a postal +address from bottom to top, we obtain more and more specific information +about where the addressee is located. + +2.4.1 Services Provided by DNS We have just seen that there are two ways +to identify a host---by a hostname and by an IP address. People prefer +the more mnemonic hostname identifier, while routers prefer +fixed-length, hierarchically structured IP addresses. In order to +reconcile these preferences, we need a directory service that translates +hostnames to IP addresses. This is the main task of the Internet's +domain name system (DNS). The DNS is (1) a distributed database +implemented in a hierarchy of DNS servers, and (2) an + + application-layer protocol that allows hosts to query the distributed +database. The DNS servers are often UNIX machines running the Berkeley +Internet Name Domain (BIND) software \[BIND 2016\]. The DNS protocol +runs over UDP and uses port 53. DNS is commonly employed by other +application-layer protocols---including HTTP and SMTP to translate +user-supplied hostnames to IP addresses. As an example, consider what +happens when a browser (that is, an HTTP client), running on some user's +host, requests the URL www.someschool.edu/index.html . In order for the +user's host to be able to send an HTTP request message to the Web server +www.someschool.edu , the user's host must first obtain the IP address of +www.someschool.edu . This is done as follows. + +1. The same user machine runs the client side of the DNS application. + +2. The browser extracts the hostname, www.someschool.edu , from the URL + and passes the hostname to the client side of the DNS application. + +3. The DNS client sends a query containing the hostname to a DNS + server. + +4. The DNS client eventually receives a reply, which includes the IP + address for the hostname. + +5. Once the browser receives the IP address from DNS, it can initiate a + TCP connection to the HTTP server process located at port 80 at that + IP address. We see from this example that DNS adds an additional + delay---sometimes substantial---to the Internet applications that + use it. Fortunately, as we discuss below, the desired IP address is + often cached in a "nearby" DNS server, which helps to reduce DNS + network traffic as well as the average DNS delay. DNS provides a few + other important services in addition to translating hostnames to IP + addresses: Host aliasing. A host with a complicated hostname can + have one or more alias names. For example, a hostname such as + relay1.west-coast.enterprise.com could have, say, two aliases such + as enterprise.com and www.enterprise.com . In this case, the + hostname relay1.west-coast.enterprise.com is said to be a canonical + hostname. Alias hostnames, when present, are typically more mnemonic + than canonical hostnames. DNS can be invoked by an application to + obtain the canonical hostname for a supplied alias hostname as well + as the IP address of the host. Mail server aliasing. For obvious + reasons, it is highly desirable that e-mail addresses be mnemonic. + For example, if Bob has an account with Yahoo Mail, Bob's e-mail + address might be as simple as bob@yahoo.mail . However, the hostname + of the Yahoo mail server is more complicated and much less mnemonic + than simply yahoo.com (for example, the canonical hostname might be + something like relay1.west-coast.yahoo.com ). DNS can be invoked by + a mail application to obtain the canonical hostname for a supplied + alias hostname as well as the IP address of the host. In fact, the + MX record (see below) permits a company's mail server and Web server + to have identical (aliased) hostnames; for example, a company's Web + server and mail server can both be called + + enterprise.com . Load distribution. DNS is also used to perform load +distribution among replicated servers, such as replicated Web servers. +Busy sites, such as cnn.com , are replicated over multiple servers, with +each server running on a different end system and each having a +different IP address. For replicated Web servers, a set of IP addresses +is thus associated with one canonical hostname. The DNS database +contains this set of IP addresses. When clients make a DNS query for a +name mapped to a set of addresses, the server responds with the entire +set of IP addresses, but rotates the ordering of the addresses within +each reply. Because a client typically sends its HTTP request message to +the IP address that is listed first in the set, DNS rotation distributes +the traffic among the replicated servers. DNS rotation is also used for +e-mail so that multiple mail servers can have the same alias name. Also, +content distribution companies such as Akamai have used DNS in more +sophisticated ways \[Dilley 2002\] to provide Web content distribution +(see Section 2.6.3). The DNS is specified in RFC 1034 and RFC 1035, and +updated in several additional RFCs. It is a complex system, and we only +touch upon key aspects of its + +PRINCIPLES IN PRACTICE DNS: CRITICAL NETWORK FUNCTIONS VIA THE +CLIENT-SERVER PARADIGM Like HTTP, FTP, and SMTP, the DNS protocol is an +application-layer protocol since it (1) runs between communicating end +systems using the client-server paradigm and (2) relies on an underlying +end-to-end transport protocol to transfer DNS messages between +communicating end systems. In another sense, however, the role of the +DNS is quite different from Web, file transfer, and e-mail applications. +Unlike these applications, the DNS is not an application with which a +user directly interacts. Instead, the DNS provides a core Internet +function---namely, translating hostnames to their underlying IP +addresses, for user applications and other software in the Internet. We +noted in Section 1.2 that much of the complexity in the Internet +architecture is located at the "edges" of the network. The DNS, which +implements the critical name-toaddress translation process using clients +and servers located at the edge of the network, is yet another example +of that design philosophy. + +operation here. The interested reader is referred to these RFCs and the +book by Albitz and Liu \[Albitz 1993\]; see also the retrospective paper +\[Mockapetris 1988\], which provides a nice description of the what and +why of DNS, and \[Mockapetris 2005\]. + +2.4.2 Overview of How DNS Works We now present a high-level overview of +how DNS works. Our discussion will focus on the hostname-to- + + IP-address translation service. Suppose that some application (such as a +Web browser or a mail reader) running in a user's host needs to +translate a hostname to an IP address. The application will invoke the +client side of DNS, specifying the hostname that needs to be translated. +(On many UNIX-based machines, gethostbyname() is the function call that +an application calls in order to perform the translation.) DNS in the +user's host then takes over, sending a query message into the network. +All DNS query and reply messages are sent within UDP datagrams to port +53. After a delay, ranging from milliseconds to seconds, DNS in the +user's host receives a DNS reply message that provides the desired +mapping. This mapping is then passed to the invoking application. Thus, +from the perspective of the invoking application in the user's host, DNS +is a black box providing a simple, straightforward translation service. +But in fact, the black box that implements the service is complex, +consisting of a large number of DNS servers distributed around the +globe, as well as an application-layer protocol that specifies how the +DNS servers and querying hosts communicate. A simple design for DNS +would have one DNS server that contains all the mappings. In this +centralized design, clients simply direct all queries to the single DNS +server, and the DNS server responds directly to the querying clients. +Although the simplicity of this design is attractive, it is +inappropriate for today's Internet, with its vast (and growing) number +of hosts. The problems with a centralized design include: A single point +of failure. If the DNS server crashes, so does the entire Internet! +Traffic volume. A single DNS server would have to handle all DNS queries +(for all the HTTP requests and e-mail messages generated from hundreds +of millions of hosts). Distant centralized database. A single DNS server +cannot be "close to" all the querying clients. If we put the single DNS +server in New York City, then all queries from Australia must travel to +the other side of the globe, perhaps over slow and congested links. This +can lead to significant delays. Maintenance. The single DNS server would +have to keep records for all Internet hosts. Not only would this +centralized database be huge, but it would have to be updated frequently +to account for every new host. In summary, a centralized database in a +single DNS server simply doesn't scale. Consequently, the DNS is +distributed by design. In fact, the DNS is a wonderful example of how a +distributed database can be implemented in the Internet. A Distributed, +Hierarchical Database In order to deal with the issue of scale, the DNS +uses a large number of servers, organized in a hierarchical fashion and +distributed around the world. No single DNS server has all of the +mappings for all of the hosts in the Internet. Instead, the mappings are +distributed across the DNS servers. To a first approximation, there are +three classes of DNS servers---root DNS servers, top-level domain (TLD) +DNS + + servers, and authoritative DNS servers---organized in a hierarchy as +shown in Figure 2.17. To understand how these three classes of servers +interact, suppose a DNS client wants to determine the IP address for the +hostname www.amazon.com . To a first + +Figure 2.17 Portion of the hierarchy of DNS servers + +approximation, the following events will take place. The client first +contacts one of the root servers, which returns IP addresses for TLD +servers for the top-level domain com . The client then contacts one of +these TLD servers, which returns the IP address of an authoritative +server for amazon.com . Finally, the client contacts one of the +authoritative servers for amazon.com , which returns the IP address for +the hostname www.amazon.com . We'll soon examine this DNS lookup process +in more detail. But let's first take a closer look at these three +classes of DNS servers: Root DNS servers. There are over 400 root name +servers scattered all over the world. Figure 2.18 shows the countries +that have root names servers, with countries having more than ten darkly +shaded. These root name servers are managed by 13 different +organizations. The full list of root name servers, along with the +organizations that manage them and their IP addresses can be found at +\[Root Servers 2016\]. Root name servers provide the IP addresses of the +TLD servers. Top-level domain (TLD) servers. For each of the top-level +domains --- top-level domains such as com, org, net, edu, and gov, and +all of the country top-level domains such as uk, fr, ca, and jp --- +there is TLD server (or server cluster). The company Verisign Global +Registry Services maintains the TLD servers for the com top-level +domain, and the company Educause maintains the TLD servers for the edu +top-level domain. The network infrastructure supporting a TLD can be +large and complex; see \[Osterweil 2012\] for a nice overview of the +Verisign network. See \[TLD list 2016\] for a list of all top-level +domains. TLD servers provide the IP addresses for authoritative DNS +servers. + + Figure 2.18 DNS root servers in 2016 + +Authoritative DNS servers. Every organization with publicly accessible +hosts (such as Web servers and mail servers) on the Internet must +provide publicly accessible DNS records that map the names of those +hosts to IP addresses. An organization's authoritative DNS server houses +these DNS records. An organization can choose to implement its own +authoritative DNS server to hold these records; alternatively, the +organization can pay to have these records stored in an authoritative +DNS server of some service provider. Most universities and large +companies implement and maintain their own primary and secondary +(backup) authoritative DNS server. The root, TLD, and authoritative DNS +servers all belong to the hierarchy of DNS servers, as shown in Figure +2.17. There is another important type of DNS server called the local DNS +server. A local DNS server does not strictly belong to the hierarchy of +servers but is nevertheless central to the DNS architecture. Each +ISP---such as a residential ISP or an institutional ISP---has a local +DNS server (also called a default name server). When a host connects to +an ISP, the ISP provides the host with the IP addresses of one or more +of its local DNS servers (typically through DHCP, which is discussed in +Chapter 4). You can easily determine the IP address of your local DNS +server by accessing network status windows in Windows or UNIX. A host's +local DNS server is typically "close to" the host. For an institutional +ISP, the local DNS server may be on the same LAN as the host; for a +residential ISP, it is typically separated from the host by no more than +a few routers. When a host makes a DNS query, the query is sent to the +local DNS server, which acts a proxy, forwarding the query into the DNS +server hierarchy, as we'll discuss in more detail below. Let's take a +look at a simple example. Suppose the host cse.nyu.edu desires the IP +address of gaia.cs.umass.edu . Also suppose that NYU's ocal DNS server +for cse.nyu.edu is called + + dns.nyu.edu and that an authoritative DNS server for gaia.cs.umass.edu +is called dns.umass.edu . As shown in Figure 2.19, the host cse.nyu.edu +first sends a DNS query message to its local DNS server, dns.nyu.edu . +The query message contains the hostname to be translated, namely, +gaia.cs.umass.edu . The local DNS server forwards the query message to a +root DNS server. The root DNS server takes note of the edu suffix and +returns to the local DNS server a list of IP addresses for TLD servers +responsible for edu . The local DNS server then resends the query +message to one of these TLD servers. The TLD server takes note of the +umass.edu suffix and responds with the IP address of the authoritative +DNS server for the University of Massachusetts, namely, dns.umass.edu . +Finally, the local DNS server resends the query message directly to +dns.umass.edu , which responds with the IP address of gaia.cs.umass.edu +. Note that in this example, in order to obtain the mapping for one +hostname, eight DNS messages were sent: four query messages and four +reply messages! We'll soon see how DNS caching reduces this query +traffic. Our previous example assumed that the TLD server knows the +authoritative DNS server for the hostname. In general this not always +true. Instead, the TLD server + +Figure 2.19 Interaction of the various DNS servers + + may know only of an intermediate DNS server, which in turn knows the +authoritative DNS server for the hostname. For example, suppose again +that the University of Massachusetts has a DNS server for the +university, called dns.umass.edu . Also suppose that each of the +departments at the University of Massachusetts has its own DNS server, +and that each departmental DNS server is authoritative for all hosts in +the department. In this case, when the intermediate DNS server, +dns.umass.edu , receives a query for a host with a hostname ending with +cs.umass.edu , it returns to dns.nyu.edu the IP address of +dns.cs.umass.edu , which is authoritative for all hostnames ending with +cs.umass.edu . The local DNS server dns.nyu.edu then sends the query to +the authoritative DNS server, which returns the desired mapping to the +local DNS server, which in turn returns the mapping to the requesting +host. In this case, a total of 10 DNS messages are sent! The example +shown in Figure 2.19 makes use of both recursive queries and iterative +queries. The query sent from cse.nyu.edu to dns.nyu.edu is a recursive +query, since the query asks dns.nyu.edu to obtain the mapping on its +behalf. But the subsequent three queries are iterative since all of the +replies are directly returned to dns.nyu.edu . In theory, any DNS query +can be iterative or recursive. For example, Figure 2.20 shows a DNS +query chain for which all of the queries are recursive. In practice, the +queries typically follow the pattern in Figure 2.19: The query from the +requesting host to the local DNS server is recursive, and the remaining +queries are iterative. DNS Caching Our discussion thus far has ignored +DNS caching, a critically important feature of the DNS system. In truth, +DNS extensively exploits DNS caching in order to improve the delay +performance and to reduce the number of DNS messages + + Figure 2.20 Recursive queries in DNS + +ricocheting around the Internet. The idea behind DNS caching is very +simple. In a query chain, when a DNS server receives a DNS reply +(containing, for example, a mapping from a hostname to an IP address), +it can cache the mapping in its local memory. For example, in Figure +2.19, each time the local DNS server dns.nyu.edu receives a reply from +some DNS server, it can cache any of the information contained in the +reply. If a hostname/IP address pair is cached in a DNS server and +another query arrives to the DNS server for the same hostname, the DNS +server can provide the desired IP address, even if it is not +authoritative for the hostname. Because hosts and mappings between +hostnames and IP addresses are by no means permanent, DNS servers +discard cached information after a period of time (often set to two +days). As an example, suppose that a host apricot.nyu.edu queries +dns.nyu.edu for the IP address for the hostname cnn.com . Furthermore, +suppose that a few hours later, another NYU host, say, kiwi.nyu.edu , +also queries dns.nyu.edu with the same hostname. Because of caching, the +local DNS server will be able to immediately return the IP address of +cnn.com to this second requesting + + host without having to query any other DNS servers. A local DNS server +can also cache the IP addresses of TLD servers, thereby allowing the +local DNS server to bypass the root DNS servers in a query chain. In +fact, because of caching, root servers are bypassed for all but a very +small fraction of DNS queries. + +2.4.3 DNS Records and Messages The DNS servers that together implement +the DNS distributed database store resource records (RRs), including RRs +that provide hostname-to-IP address mappings. Each DNS reply message +carries one or more resource records. In this and the following +subsection, we provide a brief overview of DNS resource records and +messages; more details can be found in \[Albitz 1993\] or in the DNS +RFCs \[RFC 1034; RFC 1035\]. A resource record is a four-tuple that +contains the following fields: + +(Name, Value, Type, TTL) + +TTL is the time to live of the resource record; it determines when a +resource should be removed from a cache. In the example records given +below, we ignore the TTL field. The meaning of Name and Value depend on +Type : If Type=A , then Name is a hostname and Value is the IP address +for the hostname. Thus, a Type A record provides the standard +hostname-to-IP address mapping. As an example, (relay1.bar.foo.com, +145.37.93.126, A) is a Type A record. If Type=NS , then Name is a domain +(such as foo.com ) and Value is the hostname of an authoritative DNS +server that knows how to obtain the IP addresses for hosts in the +domain. This record is used to route DNS queries further along in the +query chain. As an example, (foo.com, dns.foo.com, NS) is a Type NS +record. If Type=CNAME , then Value is a canonical hostname for the alias +hostname Name . This record can provide querying hosts the canonical +name for a hostname. As an example, (foo.com, relay1.bar.foo.com, CNAME) +is a CNAME record. If Type=MX , then Value is the canonical name of a +mail server that has an alias hostname Name . As an example, (foo.com, +mail.bar.foo.com, MX) is an MX record. MX records allow the hostnames of +mail servers to have simple aliases. Note that by using the MX record, a +company can have the same aliased name for its mail server and for one +of its other servers (such as its Web server). To obtain the canonical +name for the mail server, a DNS client would query for an MX + + record; to obtain the canonical name for the other server, the DNS +client would query for the CNAME record. If a DNS server is +authoritative for a particular hostname, then the DNS server will +contain a Type A record for the hostname. (Even if the DNS server is not +authoritative, it may contain a Type A record in its cache.) If a server +is not authoritative for a hostname, then the server will contain a Type +NS record for the domain that includes the hostname; it will also +contain a Type A record that provides the IP address of the DNS server +in the Value field of the NS record. As an example, suppose an edu TLD +server is not authoritative for the host gaia.cs.umass.edu . Then this +server will contain a record for a domain that includes the host +gaia.cs.umass.edu , for example, (umass.edu, dns.umass.edu, NS) . The +edu TLD server would also contain a Type A record, which maps the DNS +server dns.umass.edu to an IP address, for example, (dns.umass.edu, +128.119.40.111, A) . DNS Messages Earlier in this section, we referred +to DNS query and reply messages. These are the only two kinds of DNS +messages. Furthermore, both query and reply messages have the same +format, as shown in Figure 2.21.The semantics of the various fields in a +DNS message are as follows: The first 12 bytes is the header section, +which has a number of fields. The first field is a 16-bit number that +identifies the query. This identifier is copied into the reply message +to a query, allowing the client to match received replies with sent +queries. There are a number of flags in the flag field. A 1-bit +query/reply flag indicates whether the message is a query (0) or a reply +(1). A 1-bit authoritative flag is + + Figure 2.21 DNS message format + +set in a reply message when a DNS server is an authoritative server for +a queried name. A 1-bit recursion-desired flag is set when a client +(host or DNS server) desires that the DNS server perform recursion when +it doesn't have the record. A 1-bit recursion-available field is set in +a reply if the DNS server supports recursion. In the header, there are +also four number-of fields. These fields indicate the number of +occurrences of the four types of data sections that follow the header. +The question section contains information about the query that is being +made. This section includes (1) a name field that contains the name that +is being queried, and (2) a type field that indicates the type of +question being asked about the name---for example, a host address +associated with a name (Type A) or the mail server for a name (Type MX). +In a reply from a DNS server, the answer section contains the resource +records for the name that was originally queried. Recall that in each +resource record there is the Type (for example, A, NS, CNAME, and MX), +the Value , and the TTL . A reply can return multiple RRs in the answer, +since a hostname can have multiple IP addresses (for example, for +replicated Web servers, as discussed earlier in this section). The +authority section contains records of other authoritative servers. The +additional section contains other helpful records. For example, the +answer field in a reply to an MX query contains a resource record +providing the canonical hostname of a mail server. The additional +section contains a Type A record providing the IP address for the +canonical hostname of the mail server. How would you like to send a DNS +query message directly from the host you're working on to some DNS +server? This can easily be done with the nslookup program, which is +available from most Windows and UNIX platforms. For example, from a +Windows host, open the Command Prompt and invoke the nslookup program by +simply typing "nslookup." After invoking nslookup, you can send a DNS +query to any DNS server (root, TLD, or authoritative). After receiving +the reply message from the DNS server, nslookup will display the records +included in the reply (in a human-readable format). As an alternative to +running nslookup from your own host, you can visit one of many Web sites +that allow you to remotely employ nslookup. (Just type "nslookup" into a +search engine and you'll be brought to one of these sites.) The DNS +Wireshark lab at the end of this chapter will allow you to explore the +DNS in much more detail. Inserting Records into the DNS Database The +discussion above focused on how records are retrieved from the DNS +database. You might be wondering how records get into the database in +the first place. Let's look at how this is done in the context of a +specific example. Suppose you have just created an exciting new startup +company called Network Utopia. The first thing you'll surely want to do +is register the domain name + + networkutopia.com at a registrar. A registrar is a commercial entity +that verifies the uniqueness of the domain name, enters the domain name +into the DNS database (as discussed below), and collects a small fee +from you for its services. Prior to 1999, a single registrar, Network +Solutions, had a monopoly on domain name registration for com , net , +and org domains. But now there are many registrars competing for +customers, and the Internet Corporation for Assigned Names and Numbers +(ICANN) accredits the various registrars. A complete list of accredited +registrars is available at http:// www.internic.net . When you register +the domain name networkutopia.com with some registrar, you also need to +provide the registrar with the names and IP addresses of your primary +and secondary authoritative DNS servers. Suppose the names and IP +addresses are dns1.networkutopia.com , dns2.networkutopia.com , +212.2.212.1, and 212.212.212.2. For each of these two authoritative DNS +servers, the registrar would then make sure that a Type NS and a Type A +record are entered into the TLD com servers. Specifically, for the +primary authoritative server for networkutopia.com , the registrar would +insert the following two resource records into the DNS system: + +(networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, +212.212.212.1, A) + +You'll also have to make sure that the Type A resource record for your +Web server www.networkutopia.com and the Type MX resource record for +your mail server mail.networkutopia.com are entered into your +authoritative DNS FOCUS ON SECURITY DNS VULNERABILITIES We have seen +that DNS is a critical component of the Internet infrastructure, with +many important services---including the Web and e-mail---simply +incapable of functioning without it. We therefore naturally ask, how can +DNS be attacked? Is DNS a sitting duck, waiting to be knocked out of +service, while taking most Internet applications down with it? The first +type of attack that comes to mind is a DDoS bandwidth-flooding attack +(see Section 1.6) against DNS servers. For example, an attacker could +attempt to send to each DNS root server a deluge of packets, so many +that the majority of legitimate DNS queries never get answered. Such a +large-scale DDoS attack against DNS root servers actually took place on +October 21, 2002. In this attack, the attackers leveraged a botnet to +send truck loads of ICMP ping messages to each of the 13 DNS root IP +addresses. (ICMP messages are discussed in + + Section 5.6. For now, it suffices to know that ICMP packets are special +types of IP datagrams.) Fortunately, this large-scale attack caused +minimal damage, having little or no impact on users' Internet +experience. The attackers did succeed at directing a deluge of packets +at the root servers. But many of the DNS root servers were protected by +packet filters, configured to always block all ICMP ping messages +directed at the root servers. These protected servers were thus spared +and functioned as normal. Furthermore, most local DNS servers cache the +IP addresses of top-level-domain servers, allowing the query process to +often bypass the DNS root servers. A potentially more effective DDoS +attack against DNS would be send a deluge of DNS queries to +top-level-domain servers, for example, to all the top-level-domain +servers that handle the .com domain. It would be harder to filter DNS +queries directed to DNS servers; and top-level-domain servers are not as +easily bypassed as are root servers. But the severity of such an attack +would be partially mitigated by caching in local DNS servers. DNS could +potentially be attacked in other ways. In a man-in-the-middle attack, +the attacker intercepts queries from hosts and returns bogus replies. In +the DNS poisoning attack, the attacker sends bogus replies to a DNS +server, tricking the server into accepting bogus records into its cache. +Either of these attacks could be used, for example, to redirect an +unsuspecting Web user to the attacker's Web site. These attacks, +however, are difficult to implement, as they require intercepting +packets or throttling servers \[Skoudis 2006\]. In summary, DNS has +demonstrated itself to be surprisingly robust against attacks. To date, +there hasn't been an attack that has successfully impeded the DNS +service. + +servers. (Until recently, the contents of each DNS server were +configured statically, for example, from a configuration file created by +a system manager. More recently, an UPDATE option has been added to the +DNS protocol to allow data to be dynamically added or deleted from the +database via DNS messages. \[RFC 2136\] and \[RFC 3007\] specify DNS +dynamic updates.) Once all of these steps are completed, people will be +able to visit your Web site and send e-mail to the employees at your +company. Let's conclude our discussion of DNS by verifying that this +statement is true. This verification also helps to solidify what we have +learned about DNS. Suppose Alice in Australia wants to view the Web page +www.networkutopia.com . As discussed earlier, her host will first send a +DNS query to her local DNS server. The local DNS server will then +contact a TLD com server. (The local DNS server will also have to +contact a root DNS server if the address of a TLD com server is not +cached.) This TLD server contains the Type NS and Type A resource +records listed above, because the registrar had these resource records +inserted into all of the TLD com servers. The TLD com server sends a +reply to Alice's local DNS server, with the reply containing the two +resource records. The local DNS server then sends a DNS query to +212.212.212.1 , asking for the Type A record corresponding to +www.networkutopia.com . This record provides the IP address of the +desired Web server, say, 212.212.71.4 , which the local DNS server +passes back to Alice's host. Alice's browser can now + + initiate a TCP connection to the host 212.212.71.4 and send an HTTP +request over the connection. Whew! There's a lot more going on than what +meets the eye when one surfs the Web! + + 2.5 Peer-to-Peer File Distribution The applications described in this +chapter thus far---including the Web, e-mail, and DNS---all employ +client-server architectures with significant reliance on always-on +infrastructure servers. Recall from Section 2.1.1 that with a P2P +architecture, there is minimal (or no) reliance on always-on +infrastructure servers. Instead, pairs of intermittently connected +hosts, called peers, communicate directly with each other. The peers are +not owned by a service provider, but are instead desktops and laptops +controlled by users. In this section we consider a very natural P2P +application, namely, distributing a large file from a single server to a +large number of hosts (called peers). The file might be a new version of +the Linux operating system, a software patch for an existing operating +system or application, an MP3 music file, or an MPEG video file. In +client-server file distribution, the server must send a copy of the file +to each of the peers---placing an enormous burden on the server and +consuming a large amount of server bandwidth. In P2P file distribution, +each peer can redistribute any portion of the file it has received to +any other peers, thereby assisting the server in the distribution +process. As of 2016, the most popular P2P file distribution protocol is +BitTorrent. Originally developed by Bram Cohen, there are now many +different independent BitTorrent clients conforming to the BitTorrent +protocol, just as there are a number of Web browser clients that conform +to the HTTP protocol. In this subsection, we first examine the +selfscalability of P2P architectures in the context of file +distribution. We then describe BitTorrent in some detail, highlighting +its most important characteristics and features. Scalability of P2P +Architectures To compare client-server architectures with peer-to-peer +architectures, and illustrate the inherent selfscalability of P2P, we +now consider a simple quantitative model for distributing a file to a +fixed set of peers for both architecture types. As shown in Figure 2.22, +the server and the peers are connected to the Internet with access +links. Denote the upload rate of the server's access link by us, the +upload rate of the ith peer's access link by ui, and the download rate +of the ith peer's access link by di. Also denote the size of the file to +be distributed (in bits) by F and the number of peers that want to +obtain a copy of the file by N. The distribution time is the time it +takes to get + + Figure 2.22 An illustrative file distribution problem + +a copy of the file to all N peers. In our analysis of the distribution +time below, for both client-server and P2P architectures, we make the +simplifying (and generally accurate \[Akella 2003\]) assumption that the +Internet core has abundant bandwidth, implying that all of the +bottlenecks are in access networks. We also suppose that the server and +clients are not participating in any other network applications, so that +all of their upload and download access bandwidth can be fully devoted +to distributing this file. Let's first determine the distribution time +for the client-server architecture, which we denote by Dcs. In the +client-server architecture, none of the peers aids in distributing the +file. We make the following observations: The server must transmit one +copy of the file to each of the N peers. Thus the server must transmit +NF bits. Since the server's upload rate is us, the time to distribute +the file must be at least NF/us. Let dmin denote the download rate of +the peer with the lowest download rate, that is, dmin=min{d1,dp,. . +.,dN}. The peer with the lowest download rate cannot obtain all F bits +of the file in less than F/dmin seconds. Thus the minimum distribution +time is at least F/dmin. Putting these two observations together, we +obtain Dcs≥max{NFus,Fdmin}. + + This provides a lower bound on the minimum distribution time for the +client-server architecture. In the homework problems you will be asked +to show that the server can schedule its transmissions so that the lower +bound is actually achieved. So let's take this lower bound provided +above as the actual distribution time, that is, Dcs=max{NFus,Fdmin} + +(2.1) + +We see from Equation 2.1 that for N large enough, the client-server +distribution time is given by NF/us. Thus, the distribution time +increases linearly with the number of peers N. So, for example, if the +number of peers from one week to the next increases a thousand-fold from +a thousand to a million, the time required to distribute the file to all +peers increases by 1,000. Let's now go through a similar analysis for +the P2P architecture, where each peer can assist the server in +distributing the file. In particular, when a peer receives some file +data, it can use its own upload capacity to redistribute the data to +other peers. Calculating the distribution time for the P2P architecture +is somewhat more complicated than for the client-server architecture, +since the distribution time depends on how each peer distributes +portions of the file to the other peers. Nevertheless, a simple +expression for the minimal distribution time can be obtained \[Kumar +2006\]. To this end, we first make the following observations: At the +beginning of the distribution, only the server has the file. To get this +file into the community of peers, the server must send each bit of the +file at least once into its access link. Thus, the minimum distribution +time is at least F/us. (Unlike the client-server scheme, a bit sent once +by the server may not have to be sent by the server again, as the peers +may redistribute the bit among themselves.) As with the client-server +architecture, the peer with the lowest download rate cannot obtain all F +bits of the file in less than F/dmin seconds. Thus the minimum +distribution time is at least F/dmin. Finally, observe that the total +upload capacity of the system as a whole is equal to the upload rate of +the server plus the upload rates of each of the individual peers, that +is, utotal=us+u1+⋯+uN. The system must deliver (upload) F bits to each +of the N peers, thus delivering a total of NF bits. This cannot be done +at a rate faster than utotal. Thus, the minimum distribution time is +also at least NF/(us+u1+⋯+uN). Putting these three observations +together, we obtain the minimum distribution time for P2P, denoted by +DP2P. DP2P≥max{Fus,Fdmin,NFus+∑i=1Nui} + +(2.2) + +Equation 2.2 provides a lower bound for the minimum distribution time +for the P2P architecture. It turns out that if we imagine that each peer +can redistribute a bit as soon as it receives the bit, then there is a + + redistribution scheme that actually achieves this lower bound \[Kumar +2006\]. (We will prove a special case of this result in the homework.) +In reality, where chunks of the file are redistributed rather than +individual bits, Equation 2.2 serves as a good approximation of the +actual minimum distribution time. Thus, let's take the lower bound +provided by Equation 2.2 as the actual minimum distribution time, that +is, DP2P=max{Fus,Fdmin,NFus+∑i=1Nui} + +(2.3) + +Figure 2.23 compares the minimum distribution time for the client-server +and P2P architectures assuming that all peers have the same upload rate +u. In Figure 2.23, we have set F/u=1 hour, us=10u, and dmin≥us. Thus, a +peer can transmit the entire file in one hour, the server transmission +rate is 10 times the peer upload rate, + +Figure 2.23 Distribution time for P2P and client-server architectures + +and (for simplicity) the peer download rates are set large enough so as +not to have an effect. We see from Figure 2.23 that for the +client-server architecture, the distribution time increases linearly and +without bound as the number of peers increases. However, for the P2P +architecture, the minimal distribution time is not only always less than +the distribution time of the client-server architecture; it is also less +than one hour for any number of peers N. Thus, applications with the P2P +architecture can be self-scaling. This scalability is a direct +consequence of peers being redistributors as well as consumers of bits. +BitTorrent BitTorrent is a popular P2P protocol for file distribution +\[Chao 2011\]. In BitTorrent lingo, the collection of + + all peers participating in the distribution of a particular file is +called a torrent. Peers in a torrent download equal-size chunks of the +file from one another, with a typical chunk size of 256 KBytes. When a +peer first joins a torrent, it has no chunks. Over time it accumulates +more and more chunks. While it downloads chunks it also uploads chunks +to other peers. Once a peer has acquired the entire file, it may +(selfishly) leave the torrent, or (altruistically) remain in the torrent +and continue to upload chunks to other peers. Also, any peer may leave +the torrent at any time with only a subset of chunks, and later rejoin +the torrent. Let's now take a closer look at how BitTorrent operates. +Since BitTorrent is a rather complicated protocol and system, we'll only +describe its most important mechanisms, sweeping some of the details +under the rug; this will allow us to see the forest through the trees. +Each torrent has an infrastructure node called a tracker. + +Figure 2.24 File distribution with BitTorrent + +When a peer joins a torrent, it registers itself with the tracker and +periodically informs the tracker that it is still in the torrent. In +this manner, the tracker keeps track of the peers that are participating +in the torrent. A given torrent may have fewer than ten or more than a +thousand peers participating at any instant of time. + + As shown in Figure 2.24, when a new peer, Alice, joins the torrent, the +tracker randomly selects a subset of peers (for concreteness, say 50) +from the set of participating peers, and sends the IP addresses of these +50 peers to Alice. Possessing this list of peers, Alice attempts to +establish concurrent TCP connections with all the peers on this list. +Let's call all the peers with which Alice succeeds in establishing a TCP +connection "neighboring peers." (In Figure 2.24, Alice is shown to have +only three neighboring peers. Normally, she would have many more.) As +time evolves, some of these peers may leave and other peers (outside the +initial 50) may attempt to establish TCP connections with Alice. So a +peer's neighboring peers will fluctuate over time. At any given time, +each peer will have a subset of chunks from the file, with different +peers having different subsets. Periodically, Alice will ask each of her +neighboring peers (over the TCP connections) for the list of the chunks +they have. If Alice has L different neighbors, she will obtain L lists +of chunks. With this knowledge, Alice will issue requests (again over +the TCP connections) for chunks she currently does not have. So at any +given instant of time, Alice will have a subset of chunks and will know +which chunks her neighbors have. With this information, Alice will have +two important decisions to make. First, which chunks should she request +first from her neighbors? And second, to which of her neighbors should +she send requested chunks? In deciding which chunks to request, Alice +uses a technique called rarest first. The idea is to determine, from +among the chunks she does not have, the chunks that are the rarest among +her neighbors (that is, the chunks that have the fewest repeated copies +among her neighbors) and then request those rarest chunks first. In this +manner, the rarest chunks get more quickly redistributed, aiming to +(roughly) equalize the numbers of copies of each chunk in the torrent. +To determine which requests she responds to, BitTorrent uses a clever +trading algorithm. The basic idea is that Alice gives priority to the +neighbors that are currently supplying her data at the highest rate. +Specifically, for each of her neighbors, Alice continually measures the +rate at which she receives bits and determines the four peers that are +feeding her bits at the highest rate. She then reciprocates by sending +chunks to these same four peers. Every 10 seconds, she recalculates the +rates and possibly modifies the set of four peers. In BitTorrent lingo, +these four peers are said to be unchoked. Importantly, every 30 seconds, +she also picks one additional neighbor at random and sends it chunks. +Let's call the randomly chosen peer Bob. In BitTorrent lingo, Bob is +said to be optimistically unchoked. Because Alice is sending data to +Bob, she may become one of Bob's top four uploaders, in which case Bob +would start to send data to Alice. If the rate at which Bob sends data +to Alice is high enough, Bob could then, in turn, become one of Alice's +top four uploaders. In other words, every 30 seconds, Alice will +randomly choose a new trading partner and initiate trading with that +partner. If the two peers are satisfied with the trading, they will put +each other in their top four lists and continue trading with each other +until one of the peers finds a better partner. The effect is that peers +capable of uploading at compatible rates tend to find each other. The +random neighbor selection also allows new peers to get chunks, so that +they can have something to trade. All other neighboring peers besides +these five peers + + (four "top" peers and one probing peer) are "choked," that is, they do +not receive any chunks from Alice. BitTorrent has a number of +interesting mechanisms that are not discussed here, including pieces +(minichunks), pipelining, random first selection, endgame mode, and +anti-snubbing \[Cohen 2003\]. The incentive mechanism for trading just +described is often referred to as tit-for-tat \[Cohen 2003\]. It has +been shown that this incentive scheme can be circumvented \[Liogkas +2006; Locher 2006; Piatek 2007\]. Nevertheless, the BitTorrent ecosystem +is wildly successful, with millions of simultaneous peers actively +sharing files in hundreds of thousands of torrents. If BitTorrent had +been designed without tit-fortat (or a variant), but otherwise exactly +the same, BitTorrent would likely not even exist now, as the majority of +the users would have been freeriders \[Saroiu 2002\]. We close our +discussion on P2P by briefly mentioning another application of P2P, +namely, Distributed Hast Table (DHT). A distributed hash table is a +simple database, with the database records being distributed over the +peers in a P2P system. DHTs have been widely implemented (e.g., in +BitTorrent) and have been the subject of extensive research. An overview +is provided in a Video Note in the companion website. + +Walking though distributed hash tables + + 2.6 Video Streaming and Content Distribution Networks Streaming +prerecorded video now accounts for the majority of the traffic in +residential ISPs in North America. In particular, the Netflix and +YouTube services alone consumed a whopping 37% and 16%, respectively, of +residential ISP traffic in 2015 \[Sandvine 2015\]. In this section we +will provide an overview of how popular video streaming services are +implemented in today's Internet. We will see they are implemented using +application-level protocols and servers that function in some ways like +a cache. In Chapter 9, devoted to multimedia networking, we will further +examine Internet video as well as other Internet multimedia services. + +2.6.1 Internet Video In streaming stored video applications, the +underlying medium is prerecorded video, such as a movie, a television +show, a prerecorded sporting event, or a prerecorded user-generated +video (such as those commonly seen on YouTube). These prerecorded videos +are placed on servers, and users send requests to the servers to view +the videos on demand. Many Internet companies today provide streaming +video, including, Netflix, YouTube (Google), Amazon, and Youku. But +before launching into a discussion of video streaming, we should first +get a quick feel for the video medium itself. A video is a sequence of +images, typically being displayed at a constant rate, for example, at 24 +or 30 images per second. An uncompressed, digitally encoded image +consists of an array of pixels, with each pixel encoded into a number of +bits to represent luminance and color. An important characteristic of +video is that it can be compressed, thereby trading off video quality +with bit rate. Today's off-the-shelf compression algorithms can compress +a video to essentially any bit rate desired. Of course, the higher the +bit rate, the better the image quality and the better the overall user +viewing experience. From a networking perspective, perhaps the most +salient characteristic of video is its high bit rate. Compressed +Internet video typically ranges from 100 kbps for low-quality video to +over 3 Mbps for streaming high-definition movies; 4K streaming envisions +a bitrate of more than 10 Mbps. This can translate to huge amount of +traffic and storage, particularly for high-end video. For example, a +single 2 Mbps video with a duration of 67 minutes will consume 1 +gigabyte of storage and traffic. By far, the most important performance +measure for streaming video is average end-to-end throughput. In order +to provide continuous playout, the network must provide an average +throughput to the streaming application that is at least as large as the +bit rate of the compressed video. + + We can also use compression to create multiple versions of the same +video, each at a different quality level. For example, we can use +compression to create, say, three versions of the same video, at rates +of 300 kbps, 1 Mbps, and 3 Mbps. Users can then decide which version +they want to watch as a function of their current available bandwidth. +Users with high-speed Internet connections might choose the 3 Mbps +version; users watching the video over 3G with a smartphone might choose +the 300 kbps version. + +2.6.2 HTTP Streaming and DASH In HTTP streaming, the video is simply +stored at an HTTP server as an ordinary file with a specific URL. When a +user wants to see the video, the client establishes a TCP connection +with the server and issues an HTTP GET request for that URL. The server +then sends the video file, within an HTTP response message, as quickly +as the underlying network protocols and traffic conditions will allow. +On the client side, the bytes are collected in a client application +buffer. Once the number of bytes in this buffer exceeds a predetermined +threshold, the client application begins playback---specifically, the +streaming video application periodically grabs video frames from the +client application buffer, decompresses the frames, and displays them on +the user's screen. Thus, the video streaming application is displaying +video as it is receiving and buffering frames corresponding to latter +parts of the video. Although HTTP streaming, as described in the +previous paragraph, has been extensively deployed in practice (for +example, by YouTube since its inception), it has a major shortcoming: +All clients receive the same encoding of the video, despite the large +variations in the amount of bandwidth available to a client, both across +different clients and also over time for the same client. This has led +to the development of a new type of HTTP-based streaming, often referred +to as Dynamic Adaptive Streaming over HTTP (DASH). In DASH, the video is +encoded into several different versions, with each version having a +different bit rate and, correspondingly, a different quality level. The +client dynamically requests chunks of video segments of a few seconds in +length. When the amount of available bandwidth is high, the client +naturally selects chunks from a high-rate version; and when the +available bandwidth is low, it naturally selects from a low-rate +version. The client selects different chunks one at a time with HTTP GET +request messages \[Akhshabi 2011\]. DASH allows clients with different +Internet access rates to stream in video at different encoding rates. +Clients with low-speed 3G connections can receive a low bit-rate (and +low-quality) version, and clients with fiber connections can receive a +high-quality version. DASH also allows a client to adapt to the +available bandwidth if the available end-to-end bandwidth changes during +the session. This feature is particularly important for mobile users, +who typically see their bandwidth availability fluctuate as they move +with respect to the base stations. With DASH, each video version is +stored in the HTTP server, each with a different URL. The HTTP + + server also has a manifest file, which provides a URL for each version +along with its bit rate. The client first requests the manifest file and +learns about the various versions. The client then selects one chunk at +a time by specifying a URL and a byte range in an HTTP GET request +message for each chunk. While downloading chunks, the client also +measures the received bandwidth and runs a rate determination algorithm +to select the chunk to request next. Naturally, if the client has a lot +of video buffered and if the measured receive bandwidth is high, it will +choose a chunk from a high-bitrate version. And naturally if the client +has little video buffered and the measured received bandwidth is low, it +will choose a chunk from a low-bitrate version. DASH therefore allows +the client to freely switch among different quality levels. + +2.6.3 Content Distribution Networks Today, many Internet video companies +are distributing on-demand multi-Mbps streams to millions of users on a +daily basis. YouTube, for example, with a library of hundreds of +millions of videos, distributes hundreds of millions of video streams to +users around the world every day. Streaming all this traffic to +locations all over the world while providing continuous playout and high +interactivity is clearly a challenging task. For an Internet video +company, perhaps the most straightforward approach to providing +streaming video service is to build a single massive data center, store +all of its videos in the data center, and stream the videos directly +from the data center to clients worldwide. But there are three major +problems with this approach. First, if the client is far from the data +center, server-to-client packets will cross many communication links and +likely pass through many ISPs, with some of the ISPs possibly located on +different continents. If one of these links provides a throughput that +is less than the video consumption rate, the end-to-end throughput will +also be below the consumption rate, resulting in annoying freezing +delays for the user. (Recall from Chapter 1 that the end-to-end +throughput of a stream is governed by the throughput at the bottleneck +link.) The likelihood of this happening increases as the number of links +in the end-to-end path increases. A second drawback is that a popular +video will likely be sent many times over the same communication links. +Not only does this waste network bandwidth, but the Internet video +company itself will be paying its provider ISP (connected to the data +center) for sending the same bytes into the Internet over and over +again. A third problem with this solution is that a single data center +represents a single point of failure---if the data center or its links +to the Internet goes down, it would not be able to distribute any video +streams. In order to meet the challenge of distributing massive amounts +of video data to users distributed around the world, almost all major +video-streaming companies make use of Content Distribution Networks +(CDNs). A CDN manages servers in multiple geographically distributed +locations, stores copies of the videos (and other types of Web content, +including documents, images, and audio) in its servers, and attempts to +direct each user request to a CDN location that will provide the best +user experience. The + + CDN may be a private CDN, that is, owned by the content provider itself; +for example, Google's CDN distributes YouTube videos and other types of +content. The CDN may alternatively be a third-party CDN that distributes +content on behalf of multiple content providers; Akamai, Limelight and +Level-3 all operate third-party CDNs. A very readable overview of modern +CDNs is \[Leighton 2009; Nygren 2010\]. CDNs typically adopt one of two +different server placement philosophies \[Huang 2008\]: Enter Deep. One +philosophy, pioneered by Akamai, is to enter deep into the access +networks of Internet Service Providers, by deploying server clusters in +access ISPs all over the world. (Access networks are described in +Section 1.3.) Akamai takes this approach with clusters in approximately +1,700 locations. The goal is to get close to end users, thereby +improving user-perceived delay and throughput by decreasing the number +of links and routers between the end user and the CDN server from which +it receives content. Because of this highly distributed design, the task +of maintaining and managing the clusters becomes challenging. Bring +Home. A second design philosophy, taken by Limelight and many other CDN +companies, is to bring the ISPs home by building large clusters at a +smaller number (for example, tens) of sites. Instead of getting inside +the access ISPs, these CDNs typically place their clusters in Internet +Exchange Points (IXPs) (see Section 1.3). Compared with the enter-deep +design philosophy, the bring-home design typically results in lower +maintenance and management overhead, possibly at the expense of higher +delay and lower throughput to end users. Once its clusters are in place, +the CDN replicates content across its clusters. The CDN may not want to +place a copy of every video in each cluster, since some videos are +rarely viewed or are only popular in some countries. In fact, many CDNs +do not push videos to their clusters but instead use a simple pull +strategy: If a client requests a video from a cluster that is not +storing the video, then the cluster retrieves the video (from a central +repository or from another cluster) and stores a copy locally while +streaming the video to the client at the same time. Similar Web caching +(see Section 2.2.5), when a cluster's storage becomes full, it removes +videos that are not frequently requested. CDN Operation Having +identified the two major approaches toward deploying a CDN, let's now +dive down into the nuts and bolts of how a CDN operates. When a browser +in a user's + +CASE STUDY GOOGLE'S NETWORK INFRASTRUCTURE To support its vast array of +cloud services---including search, Gmail, calendar, YouTube video, maps, +documents, and social networks---Google has deployed an extensive +private network and CDN infrastructure. Google's CDN infrastructure has +three tiers of server clusters: + + Fourteen "mega data centers," with eight in North America, four in +Europe, and two in Asia \[Google Locations 2016\], with each data center +having on the order of 100,000 servers. These mega data centers are +responsible for serving dynamic (and often personalized) content, +including search results and Gmail messages. An estimated 50 clusters in +IXPs scattered throughout the world, with each cluster consisting on the +order of 100--500 servers \[Adhikari 2011a\]. These clusters are +responsible for serving static content, including YouTube videos +\[Adhikari 2011a\]. Many hundreds of "enter-deep" clusters located +within an access ISP. Here a cluster typically consists of tens of +servers within a single rack. These enter-deep servers perform TCP +splitting (see Section 3.7) and serve static content \[Chen 2011\], +including the static portions of Web pages that embody search results. +All of these data centers and cluster locations are networked together +with Google's own private network. When a user makes a search query, +often the query is first sent over the local ISP to a nearby enter-deep +cache, from where the static content is retrieved; while providing the +static content to the client, the nearby cache also forwards the query +over Google's private network to one of the mega data centers, from +where the personalized search results are retrieved. For a YouTube +video, the video itself may come from one of the bring-home caches, +whereas portions of the Web page surrounding the video may come from the +nearby enter-deep cache, and the advertisements surrounding the video +come from the data centers. In summary, except for the local ISPs, the +Google cloud services are largely provided by a network infrastructure +that is independent of the public Internet. + +host is instructed to retrieve a specific video (identified by a URL), +the CDN must intercept the request so that it can (1) determine a +suitable CDN server cluster for that client at that time, and (2) +redirect the client's request to a server in that cluster. We'll shortly +discuss how a CDN can determine a suitable cluster. But first let's +examine the mechanics behind intercepting and redirecting a request. +Most CDNs take advantage of DNS to intercept and redirect requests; an +interesting discussion of such a use of the DNS is \[Vixie 2009\]. Let's +consider a simple example to illustrate how the DNS is typically +involved. Suppose a content provider, NetCinema, employs the third-party +CDN company, KingCDN, to distribute its videos to its customers. On the +NetCinema Web pages, each of its videos is assigned a URL that includes +the string "video" and a unique identifier for the video itself; for +example, Transformers 7 might be assigned +http://video.netcinema.com/6Y7B23V. Six steps then occur, as shown in +Figure 2.25: + +1. The user visits the Web page at NetCinema. +2. When the user clicks on the link http://video.netcinema.com/6Y7B23V, + the user's host sends a DNS query for video.netcinema.com. + + 3. The user's Local DNS Server (LDNS) relays the DNS query to an +authoritative DNS server for NetCinema, which observes the string +"video" in the hostname video.netcinema.com. To "hand over" the DNS +query to KingCDN, instead of returning an IP address, the NetCinema +authoritative DNS server returns to the LDNS a hostname in the KingCDN's +domain, for example, a1105.kingcdn.com. + +4. From this point on, the DNS query enters into KingCDN's private DNS + infrastructure. The user's LDNS then sends a second query, now for + a1105.kingcdn.com, and KingCDN's DNS system eventually returns the + IP addresses of a KingCDN content server to the LDNS. It is thus + here, within the KingCDN's DNS system, that the CDN server from + which the client will receive its content is specified. + +Figure 2.25 DNS redirects a user's request to a CDN server + +5. The LDNS forwards the IP address of the content-serving CDN node to + the user's host. +6. Once the client receives the IP address for a KingCDN content + server, it establishes a direct TCP connection with the server at + that IP address and issues an HTTP GET request for the video. If + DASH is used, the server will first send to the client a manifest + file with a list of URLs, one for each version of the video, and the + client will dynamically select chunks from the different versions. + Cluster Selection Strategies At the core of any CDN deployment is a + cluster selection strategy, that is, a mechanism for dynamically + directing clients to a server cluster or a data center within the + CDN. As we just saw, the + + CDN learns the IP address of the client's LDNS server via the client's +DNS lookup. After learning this IP address, the CDN needs to select an +appropriate cluster based on this IP address. CDNs generally employ +proprietary cluster selection strategies. We now briefly survey a few +approaches, each of which has its own advantages and disadvantages. One +simple strategy is to assign the client to the cluster that is +geographically closest. Using commercial geo-location databases (such as +Quova \[Quova 2016\] and Max-Mind \[MaxMind 2016\]), each LDNS IP +address is mapped to a geographic location. When a DNS request is +received from a particular LDNS, the CDN chooses the geographically +closest cluster, that is, the cluster that is the fewest kilometers from +the LDNS "as the bird flies." Such a solution can work reasonably well +for a large fraction of the clients \[Agarwal 2009\]. However, for some +clients, the solution may perform poorly, since the geographically +closest cluster may not be the closest cluster in terms of the length or +number of hops of the network path. Furthermore, a problem inherent with +all DNS-based approaches is that some end-users are configured to use +remotely located LDNSs \[Shaikh 2001; Mao 2002\], in which case the LDNS +location may be far from the client's location. Moreover, this simple +strategy ignores the variation in delay and available bandwidth over +time of Internet paths, always assigning the same cluster to a +particular client. In order to determine the best cluster for a client +based on the current traffic conditions, CDNs can instead perform +periodic real-time measurements of delay and loss performance between +their clusters and clients. For instance, a CDN can have each of its +clusters periodically send probes (for example, ping messages or DNS +queries) to all of the LDNSs around the world. One drawback of this +approach is that many LDNSs are configured to not respond to such +probes. + +2.6.4 Case Studies: Netflix, YouTube, and Kankan We conclude our +discussion of streaming stored video by taking a look at three highly +successful largescale deployments: Netflix, YouTube, and Kankan. We'll +see that each of these systems take a very different approach, yet +employ many of the underlying principles discussed in this section. +Netflix Generating 37% of the downstream traffic in residential ISPs in +North America in 2015, Netflix has become the leading service provider +for online movies and TV series in the United States \[Sandvine 2015\]. +As we discuss below, Netflix video distribution has two major +components: the Amazon cloud and its own private CDN infrastructure. +Netflix has a Web site that handles numerous functions, including user +registration and login, billing, movie catalogue for browsing and +searching, and a movie recommendation system. As shown in Figure + + 2.26, this Web site (and its associated backend databases) run entirely +on Amazon servers in the Amazon cloud. Additionally, the Amazon cloud +handles the following critical functions: Content ingestion. Before +Netflix can distribute a movie to its customers, it must first ingest +and process the movie. Netflix receives studio master versions of movies +and uploads them to hosts in the Amazon cloud. Content processing. The +machines in the Amazon cloud create many different formats for each +movie, suitable for a diverse array of client video players running on +desktop computers, smartphones, and game consoles connected to +televisions. A different version is created for each of these formats +and at multiple bit rates, allowing for adaptive streaming over HTTP +using DASH. Uploading versions to its CDN. Once all of the versions of a +movie have been created, the hosts in the Amazon cloud upload the +versions to its CDN. + +Figure 2.26 Netflix video streaming platform + +When Netflix first rolled out its video streaming service in 2007, it +employed three third-party CDN companies to distribute its video +content. Netflix has since created its own private CDN, from which it +now streams all of its videos. (Netflix still uses Akamai to distribute +its Web pages, however.) To create its own CDN, Netflix has installed +server racks both in IXPs and within residential ISPs themselves. +Netflix currently has server racks in over 50 IXP locations; see +\[Netflix Open Connect 2016\] for a current list of IXPs housing Netflix +racks. There are also hundreds of ISP locations housing Netflix racks; +also see \[Netflix Open Connect 2016\], where Netflix provides to +potential ISP partners instructions about installing a (free) Netflix +rack for their networks. Each server in the rack has several 10 Gbps + + Ethernet ports and over 100 terabytes of storage. The number of servers +in a rack varies: IXP installations often have tens of servers and +contain the entire Netflix streaming video library, including multiple +versions of the videos to support DASH; local IXPs may only have one +server and contain only the most popular videos. Netflix does not use +pull-caching (Section 2.2.5) to populate its CDN servers in the IXPs and +ISPs. Instead, Netflix distributes by pushing the videos to its CDN +servers during offpeak hours. For those locations that cannot hold the +entire library, Netflix pushes only the most popular videos, which are +determined on a day-to-day basis. The Netflix CDN design is described in +some detail in the YouTube videos \[Netflix Video 1\] and \[Netflix +Video 2\]. Having described the components of the Netflix architecture, +let's take a closer look at the interaction between the client and the +various servers that are involved in movie delivery. As indicated +earlier, the Web pages for browsing the Netflix video library are served +from servers in the Amazon cloud. When a user selects a movie to play, +the Netflix software, running in the Amazon cloud, first determines +which of its CDN servers have copies of the movie. Among the servers +that have the movie, the software then determines the "best" server for +that client request. If the client is using a residential ISP that has a +Netflix CDN server rack installed in that ISP, and this rack has a copy +of the requested movie, then a server in this rack is typically +selected. If not, a server at a nearby IXP is typically selected. Once +Netflix determines the CDN server that is to deliver the content, it +sends the client the IP address of the specific server as well as a +manifest file, which has the URLs for the different versions of the +requested movie. The client and that CDN server then directly interact +using a proprietary version of DASH. Specifically, as described in +Section 2.6.2, the client uses the byte-range header in HTTP GET request +messages, to request chunks from the different versions of the movie. +Netflix uses chunks that are approximately four-seconds long \[Adhikari +2012\]. While the chunks are being downloaded, the client measures the +received throughput and runs a rate-determination algorithm to determine +the quality of the next chunk to request. Netflix embodies many of the +key principles discussed earlier in this section, including adaptive +streaming and CDN distribution. However, because Netflix uses its own +private CDN, which distributes only video (and not Web pages), Netflix +has been able to simplify and tailor its CDN design. In particular, +Netflix does not need to employ DNS redirect, as discussed in Section +2.6.3, to connect a particular client to a CDN server; instead, the +Netflix software (running in the Amazon cloud) directly tells the client +to use a particular CDN server. Furthermore, the Netflix CDN uses push +caching rather than pull caching (Section 2.2.5): content is pushed into +the servers at scheduled times at off-peak hours, rather than +dynamically during cache misses. YouTube With 300 hours of video +uploaded to YouTube every minute and several billion video views per day +\[YouTube 2016\], YouTube is indisputably the world's largest +video-sharing site. YouTube began its + + service in April 2005 and was acquired by Google in November 2006. +Although the Google/YouTube design and protocols are proprietary, +through several independent measurement efforts we can gain a basic +understanding about how YouTube operates \[Zink 2009; Torres 2011; +Adhikari 2011a\]. As with Netflix, YouTube makes extensive use of CDN +technology to distribute its videos \[Torres 2011\]. Similar to Netflix, +Google uses its own private CDN to distribute YouTube videos, and has +installed server clusters in many hundreds of different IXP and ISP +locations. From these locations and directly from its huge data centers, +Google distributes YouTube videos \[Adhikari 2011a\]. Unlike Netflix, +however, Google uses pull caching, as described in Section 2.2.5, and +DNS redirect, as described in Section 2.6.3. Most of the time, Google's +cluster-selection strategy directs the client to the cluster for which +the RTT between client and cluster is the lowest; however, in order to +balance the load across clusters, sometimes the client is directed (via +DNS) to a more distant cluster \[Torres 2011\]. YouTube employs HTTP +streaming, often making a small number of different versions available +for a video, each with a different bit rate and corresponding quality +level. YouTube does not employ adaptive streaming (such as DASH), but +instead requires the user to manually select a version. In order to save +bandwidth and server resources that would be wasted by repositioning or +early termination, YouTube uses the HTTP byte range request to limit the +flow of transmitted data after a target amount of video is prefetched. +Several million videos are uploaded to YouTube every day. Not only are +YouTube videos streamed from server to client over HTTP, but YouTube +uploaders also upload their videos from client to server over HTTP. +YouTube processes each video it receives, converting it to a YouTube +video format and creating multiple versions at different bit rates. This +processing takes place entirely within Google data centers. (See the +case study on Google's network infrastructure in Section 2.6.3.) Kankan +We just saw that dedicated servers, operated by private CDNs, stream +Netflix and YouTube videos to clients. Netflix and YouTube have to pay +not only for the server hardware but also for the bandwidth the servers +use to distribute the videos. Given the scale of these services and the +amount of bandwidth they are consuming, such a CDN deployment can be +costly. We conclude this section by describing an entirely different +approach for providing video on demand over the Internet at a large +scale---one that allows the service provider to significantly reduce its +infrastructure and bandwidth costs. As you might suspect, this approach +uses P2P delivery instead of (or along with) client-server delivery. +Since 2011, Kankan (owned and operated by Xunlei) has been deploying P2P +video delivery with great success, with tens of millions of users every +month \[Zhang 2015\]. At a high level, P2P video streaming is very +similar to BitTorrent file downloading. When a peer wants to + + see a video, it contacts a tracker to discover other peers in the system +that have a copy of that video. This requesting peer then requests +chunks of the video in parallel from the other peers that have the +video. Different from downloading with BitTorrent, however, requests are +preferentially made for chunks that are to be played back in the near +future in order to ensure continuous playback \[Dhungel 2012\]. +Recently, Kankan has migrated to a hybrid CDN-P2P streaming system +\[Zhang 2015\]. Specifically, Kankan now deploys a few hundred servers +within China and pushes video content to these servers. This Kankan CDN +plays a major role in the start-up stage of video streaming. In most +cases, the client requests the beginning of the content from CDN +servers, and in parallel requests content from peers. When the total P2P +traffic is sufficient for video playback, the client will cease +streaming from the CDN and only stream from peers. But if the P2P +streaming traffic becomes insufficient, the client will restart CDN +connections and return to the mode of hybrid CDN-P2P streaming. In this +manner, Kankan can ensure short initial start-up delays while minimally +relying on costly infrastructure servers and bandwidth. + + 2.7 Socket Programming: Creating Network Applications Now that we've +looked at a number of important network applications, let's explore how +network application programs are actually created. Recall from Section +2.1 that a typical network application consists of a pair of +programs---a client program and a server program---residing in two +different end systems. When these two programs are executed, a client +process and a server process are created, and these processes +communicate with each other by reading from, and writing to, sockets. +When creating a network application, the developer's main task is +therefore to write the code for both the client and server programs. +There are two types of network applications. One type is an +implementation whose operation is specified in a protocol standard, such +as an RFC or some other standards document; such an application is +sometimes referred to as "open," since the rules specifying its +operation are known to all. For such an implementation, the client and +server programs must conform to the rules dictated by the RFC. For +example, the client program could be an implementation of the client +side of the HTTP protocol, described in Section 2.2 and precisely +defined in RFC 2616; similarly, the server program could be an +implementation of the HTTP server protocol, also precisely defined in +RFC 2616. If one developer writes code for the client program and +another developer writes code for the server program, and both +developers carefully follow the rules of the RFC, then the two programs +will be able to interoperate. Indeed, many of today's network +applications involve communication between client and server programs +that have been created by independent developers---for example, a Google +Chrome browser communicating with an Apache Web server, or a BitTorrent +client communicating with BitTorrent tracker. The other type of network +application is a proprietary network application. In this case the +client and server programs employ an application-layer protocol that has +not been openly published in an RFC or elsewhere. A single developer (or +development team) creates both the client and server programs, and the +developer has complete control over what goes in the code. But because +the code does not implement an open protocol, other independent +developers will not be able to develop code that interoperates with the +application. In this section, we'll examine the key issues in developing +a client-server application, and we'll "get our hands dirty" by looking +at code that implements a very simple client-server application. During +the development phase, one of the first decisions the developer must +make is whether the application is to run over TCP or over UDP. Recall +that TCP is connection oriented and provides a reliable byte-stream +channel through which data flows between two end systems. UDP is +connectionless and sends independent packets of data from one end system +to the other, without any guarantees about delivery. + + Recall also that when a client or server program implements a protocol +defined by an RFC, it should use the well-known port number associated +with the protocol; conversely, when developing a proprietary +application, the developer must be careful to avoid using such +well-known port numbers. (Port numbers were briefly discussed in Section +2.1. They are covered in more detail in Chapter 3.) We introduce UDP and +TCP socket programming by way of a simple UDP application and a simple +TCP application. We present the simple UDP and TCP applications in +Python 3. We could have written the code in Java, C, or C++, but we +chose Python mostly because Python clearly exposes the key socket +concepts. With Python there are fewer lines of code, and each line can +be explained to the novice programmer without difficulty. But there's no +need to be frightened if you are not familiar with Python. You should be +able to easily follow the code if you have experience programming in +Java, C, or C++. If you are interested in client-server programming with +Java, you are encouraged to see the Companion Website for this textbook; +in fact, you can find there all the examples in this section (and +associated labs) in Java. For readers who are interested in +client-server programming in C, there are several good references +available \[Donahoo 2001; Stevens 1997; Frost 1994; Kurose 1996\]; our +Python examples below have a similar look and feel to C. + +2.7.1 Socket Programming with UDP In this subsection, we'll write simple +client-server programs that use UDP; in the following section, we'll +write similar programs that use TCP. Recall from Section 2.1 that +processes running on different machines communicate with each other by +sending messages into sockets. We said that each process is analogous to +a house and the process's socket is analogous to a door. The application +resides on one side of the door in the house; the transport-layer +protocol resides on the other side of the door in the outside world. The +application developer has control of everything on the application-layer +side of the socket; however, it has little control of the +transport-layer side. Now let's take a closer look at the interaction +between two communicating processes that use UDP sockets. Before the +sending process can push a packet of data out the socket door, when +using UDP, it must first attach a destination address to the packet. +After the packet passes through the sender's socket, the Internet will +use this destination address to route the packet through the Internet to +the socket in the receiving process. When the packet arrives at the +receiving socket, the receiving process will retrieve the packet through +the socket, and then inspect the packet's contents and take appropriate +action. So you may be now wondering, what goes into the destination +address that is attached to the packet? + + As you might expect, the destination host's IP address is part of the +destination address. By including the destination IP address in the +packet, the routers in the Internet will be able to route the packet +through the Internet to the destination host. But because a host may be +running many network application processes, each with one or more +sockets, it is also necessary to identify the particular socket in the +destination host. When a socket is created, an identifier, called a port +number, is assigned to it. So, as you might expect, the packet's +destination address also includes the socket's port number. In summary, +the sending process attaches to the packet a destination address, which +consists of the destination host's IP address and the destination +socket's port number. Moreover, as we shall soon see, the sender's +source address---consisting of the IP address of the source host and the +port number of the source socket---are also attached to the packet. +However, attaching the source address to the packet is typically not +done by the UDP application code; instead it is automatically done by +the underlying operating system. We'll use the following simple +client-server application to demonstrate socket programming for both UDP +and TCP: + +1. The client reads a line of characters (data) from its keyboard and + sends the data to the server. +2. The server receives the data and converts the characters to + uppercase. +3. The server sends the modified data to the client. +4. The client receives the modified data and displays the line on its + screen. Figure 2.27 highlights the main socket-related activity of + the client and server that communicate over the UDP transport + service. Now let's get our hands dirty and take a look at the + client-server program pair for a UDP implementation of this simple + application. We also provide a detailed, line-by-line analysis after + each program. We'll begin with the UDP client, which will send a + simple application-level message to the server. In order for + + Figure 2.27 The client-server application using UDP + +the server to be able to receive and reply to the client's message, it +must be ready and running---that is, it must be running as a process +before the client sends its message. The client program is called +UDPClient.py, and the server program is called UDPServer.py. In order to +emphasize the key issues, we intentionally provide code that is minimal. +"Good code" would certainly have a few more auxiliary lines, in +particular for handling error cases. For this application, we have +arbitrarily chosen 12000 for the server port number. UDPClient.py Here +is the code for the client side of the application: + +from socket import \* serverName = 'hostname' serverPort = 12000 + + clientSocket = socket(AF_INET, SOCK_DGRAM) message = raw_input('Input +lowercase sentence:') clientSocket.sendto(message.encode(),(serverName, +serverPort)) modifiedMessage, serverAddress = +clientSocket.recvfrom(2048) print(modifiedMessage.decode()) +clientSocket.close() + +Now let's take a look at the various lines of code in UDPClient.py. + +from socket import \* + +The socket module forms the basis of all network communications in +Python. By including this line, we will be able to create sockets within +our program. + +serverName = 'hostname' serverPort = 12000 + +The first line sets the variable serverName to the string 'hostname'. +Here, we provide a string containing either the IP address of the server +(e.g., "128.138.32.126") or the hostname of the server (e.g., +"cis.poly.edu"). If we use the hostname, then a DNS lookup will +automatically be performed to get the IP address.) The second line sets +the integer variable serverPort to 12000. + +clientSocket = socket(AF_INET, SOCK_DGRAM) + +This line creates the client's socket, called clientSocket . The first +parameter indicates the address family; in particular, AF_INET indicates +that the underlying network is using IPv4. (Do not worry about this +now---we will discuss IPv4 in Chapter 4.) The second parameter indicates +that the socket is of type SOCK_DGRAM , which means it is a UDP socket +(rather than a TCP socket). Note that we are not specifying the port +number of the client socket when we create it; we are instead letting +the operating system do this for us. Now that the client process's door +has been created, we will want to create a message to send through the +door. + +message = raw_input('Input lowercase sentence:') + + raw_input() is a built-in function in Python. When this command is +executed, the user at the client is prompted with the words "Input +lowercase sentence:" The user then uses her keyboard to input a line, +which is put into the variable message . Now that we have a socket and a +message, we will want to send the message through the socket to the +destination host. + +clientSocket.sendto(message.encode(),(serverName, serverPort)) + +In the above line, we first convert the message from string type to byte +type, as we need to send bytes into a socket; this is done with the +encode() method. The method sendto() attaches the destination address ( +serverName, serverPort ) to the message and sends the resulting packet +into the process's socket, clientSocket . (As mentioned earlier, the +source address is also attached to the packet, although this is done +automatically rather than explicitly by the code.) Sending a +client-to-server message via a UDP socket is that simple! After sending +the packet, the client waits to receive data from the server. + +modifiedMessage, serverAddress = clientSocket.recvfrom(2048) + +With the above line, when a packet arrives from the Internet at the +client's socket, the packet's data is put into the variable +modifiedMessage and the packet's source address is put into the variable +serverAddress . The variable serverAddress contains both the server's IP +address and the server's port number. The program UDPClient doesn't +actually need this server address information, since it already knows +the server address from the outset; but this line of Python provides the +server address nevertheless. The method recvfrom also takes the buffer +size 2048 as input. (This buffer size works for most purposes.) + +print(modifiedMessage.decode()) + +This line prints out modifiedMessage on the user's display, after +converting the message from bytes to string. It should be the original +line that the user typed, but now capitalized. + +clientSocket.close() + + This line closes the socket. The process then terminates. UDPServer.py +Let's now take a look at the server side of the application: + +from socket import \* serverPort = 12000 serverSocket = socket(AF_INET, +SOCK_DGRAM) serverSocket.bind(('', serverPort)) print("The server is +ready to receive") while True: message, clientAddress = +serverSocket.recvfrom(2048) modifiedMessage = message.decode().upper() +serverSocket.sendto(modifiedMessage.encode(), clientAddress) + +Note that the beginning of UDPServer is similar to UDPClient. It also +imports the socket module, also sets the integer variable serverPort to +12000, and also creates a socket of type SOCK_DGRAM (a UDP socket). The +first line of code that is significantly different from UDPClient is: + +serverSocket.bind(('', serverPort)) + +The above line binds (that is, assigns) the port number 12000 to the +server's socket. Thus in UDPServer, the code (written by the application +developer) is explicitly assigning a port number to the socket. In this +manner, when anyone sends a packet to port 12000 at the IP address of +the server, that packet will be directed to this socket. UDPServer then +enters a while loop; the while loop will allow UDPServer to receive and +process packets from clients indefinitely. In the while loop, UDPServer +waits for a packet to arrive. + +message, clientAddress = serverSocket.recvfrom(2048) + +This line of code is similar to what we saw in UDPClient. When a packet +arrives at the server's socket, the packet's data is put into the +variable message and the packet's source address is put into the +variable clientAddress . The variable clientAddress contains both the +client's IP address and the client's port number. Here, UDPServer will +make use of this address information, as it provides a return + + address, similar to the return address with ordinary postal mail. With +this source address information, the server now knows to where it should +direct its reply. + +modifiedMessage = message.decode().upper() + +This line is the heart of our simple application. It takes the line sent +by the client and, after converting the message to a string, uses the +method upper() to capitalize it. + +serverSocket.sendto(modifiedMessage.encode(), clientAddress) + +This last line attaches the client's address (IP address and port +number) to the capitalized message (after converting the string to +bytes), and sends the resulting packet into the server's socket. (As +mentioned earlier, the server address is also attached to the packet, +although this is done automatically rather than explicitly by the code.) +The Internet will then deliver the packet to this client address. After +the server sends the packet, it remains in the while loop, waiting for +another UDP packet to arrive (from any client running on any host). To +test the pair of programs, you run UDPClient.py on one host and +UDPServer.py on another host. Be sure to include the proper hostname or +IP address of the server in UDPClient.py. Next, you execute +UDPServer.py, the compiled server program, in the server host. This +creates a process in the server that idles until it is contacted by some +client. Then you execute UDPClient.py, the compiled client program, in +the client. This creates a process in the client. Finally, to use the +application at the client, you type a sentence followed by a carriage +return. To develop your own UDP client-server application, you can begin +by slightly modifying the client or server programs. For example, +instead of converting all the letters to uppercase, the server could +count the number of times the letter s appears and return this number. +Or you can modify the client so that after receiving a capitalized +sentence, the user can continue to send more sentences to the server. + +2.7.2 Socket Programming with TCP Unlike UDP, TCP is a +connection-oriented protocol. This means that before the client and +server can start to send data to each other, they first need to +handshake and establish a TCP connection. One end of the TCP connection +is attached to the client socket and the other end is attached to a +server socket. When creating the TCP connection, we associate with it +the client socket address (IP address and port + + number) and the server socket address (IP address and port number). With +the TCP connection established, when one side wants to send data to the +other side, it just drops the data into the TCP connection via its +socket. This is different from UDP, for which the server must attach a +destination address to the packet before dropping it into the socket. +Now let's take a closer look at the interaction of client and server +programs in TCP. The client has the job of initiating contact with the +server. In order for the server to be able to react to the client's +initial contact, the server has to be ready. This implies two things. +First, as in the case of UDP, the TCP server must be running as a +process before the client attempts to initiate contact. Second, the +server program must have a special door---more precisely, a special +socket---that welcomes some initial contact from a client process +running on an arbitrary host. Using our house/door analogy for a +process/socket, we will sometimes refer to the client's initial contact +as "knocking on the welcoming door." With the server process running, +the client process can initiate a TCP connection to the server. This is +done in the client program by creating a TCP socket. When the client +creates its TCP socket, it specifies the address of the welcoming socket +in the server, namely, the IP address of the server host and the port +number of the socket. After creating its socket, the client initiates a +three-way handshake and establishes a TCP connection with the server. +The three-way handshake, which takes place within the transport layer, +is completely invisible to the client and server programs. During the +three-way handshake, the client process knocks on the welcoming door of +the server process. When the server "hears" the knocking, it creates a +new door---more precisely, a new socket that is dedicated to that +particular client. In our example below, the welcoming door is a TCP +socket object that we call serverSocket ; the newly created socket +dedicated to the client making the connection is called connectionSocket +. Students who are encountering TCP sockets for the first time sometimes +confuse the welcoming socket (which is the initial point of contact for +all clients wanting to communicate with the server), and each newly +created server-side connection socket that is subsequently created for +communicating with each client. From the application's perspective, the +client's socket and the server's connection socket are directly +connected by a pipe. As shown in Figure 2.28, the client process can +send arbitrary bytes into its socket, and TCP guarantees that the server +process will receive (through the connection socket) each byte in the +order sent. TCP thus provides a reliable service between the client and +server processes. Furthermore, just as people can go in and out the same +door, the client process not only sends bytes into but also receives +bytes from its socket; similarly, the server process not only receives +bytes from but also sends bytes into its connection socket. We use the +same simple client-server application to demonstrate socket programming +with TCP: The client sends one line of data to the server, the server +capitalizes the line and sends it back to the client. Figure 2.29 +highlights the main socket-related activity of the client and server +that communicate over + + the TCP transport service. + +Figure 2.28 The TCPServer process has two sockets + +TCPClient.py Here is the code for the client side of the application: + +from socket import \* serverName = 'servername' serverPort = 12000 +clientSocket = socket(AF_INET, SOCK_STREAM) +clientSocket.connect((serverName, serverPort)) sentence = +raw_input('Input lowercase sentence:') +clientSocket.send(sentence.encode()) modifiedSentence = +clientSocket.recv(1024) print('From Server: ', +modifiedSentence.decode()) clientSocket.close() + +Let's now take a look at the various lines in the code that differ +significantly from the UDP implementation. The first such line is the +creation of the client socket. + + clientSocket = socket(AF_INET, SOCK_STREAM) + +This line creates the client's socket, called clientSocket . The first +parameter again indicates that the underlying network is using IPv4. The +second parameter + +Figure 2.29 The client-server application using TCP + +indicates that the socket is of type SOCK_STREAM , which means it is a +TCP socket (rather than a UDP socket). Note that we are again not +specifying the port number of the client socket when we create it; we +are instead letting the operating system do this for us. Now the next +line of code is very different from what we saw in UDPClient: + + clientSocket.connect((serverName, serverPort)) + +Recall that before the client can send data to the server (or vice +versa) using a TCP socket, a TCP connection must first be established +between the client and server. The above line initiates the TCP +connection between the client and server. The parameter of the connect() +method is the address of the server side of the connection. After this +line of code is executed, the three-way handshake is performed and a TCP +connection is established between the client and server. + +sentence = raw_input('Input lowercase sentence:') + +As with UDPClient, the above obtains a sentence from the user. The +string sentence continues to gather characters until the user ends the +line by typing a carriage return. The next line of code is also very +different from UDPClient: + +clientSocket.send(sentence.encode()) + +The above line sends the sentence through the client's socket and into +the TCP connection. Note that the program does not explicitly create a +packet and attach the destination address to the packet, as was the case +with UDP sockets. Instead the client program simply drops the bytes in +the string sentence into the TCP connection. The client then waits to +receive bytes from the server. + +modifiedSentence = clientSocket.recv(2048) + +When characters arrive from the server, they get placed into the string +modifiedSentence . Characters continue to accumulate in modifiedSentence +until the line ends with a carriage return character. After printing the +capitalized sentence, we close the client's socket: + +clientSocket.close() + +This last line closes the socket and, hence, closes the TCP connection +between the client and the server. It causes TCP in the client to send a +TCP message to TCP in the server (see Section 3.5). + + TCPServer.py Now let's take a look at the server program. + +from socket import \* serverPort = 12000 serverSocket = socket(AF_INET, +SOCK_STREAM) serverSocket.bind(('', serverPort)) serverSocket.listen(1) +print('The server is ready to receive') while True: connectionSocket, +addr = serverSocket.accept() sentence = +connectionSocket.recv(1024).decode() capitalizedSentence = +sentence.upper() connectionSocket.send(capitalizedSentence.encode()) +connectionSocket.close() + +Let's now take a look at the lines that differ significantly from +UDPServer and TCPClient. As with TCPClient, the server creates a TCP +socket with: + +serverSocket=socket(AF_INET, SOCK_STREAM) + +Similar to UDPServer, we associate the server port number, serverPort , +with this socket: + +serverSocket.bind(('', serverPort)) + +But with TCP, serverSocket will be our welcoming socket. After +establishing this welcoming door, we will wait and listen for some +client to knock on the door: + +serverSocket.listen(1) + +This line has the server listen for TCP connection requests from the +client. The parameter specifies the maximum number of queued connections +(at least 1). + + connectionSocket, addr = serverSocket.accept() + +When a client knocks on this door, the program invokes the accept() +method for serverSocket, which creates a new socket in the server, +called connectionSocket , dedicated to this particular client. The +client and server then complete the handshaking, creating a TCP +connection between the client's clientSocket and the server's +connectionSocket . With the TCP connection established, the client and +server can now send bytes to each other over the connection. With TCP, +all bytes sent from one side not are not only guaranteed to arrive at +the other side but also guaranteed arrive in order. + +connectionSocket.close() + +In this program, after sending the modified sentence to the client, we +close the connection socket. But since serverSocket remains open, +another client can now knock on the door and send the server a sentence +to modify. This completes our discussion of socket programming in TCP. +You are encouraged to run the two programs in two separate hosts, and +also to modify them to achieve slightly different goals. You should +compare the UDP program pair with the TCP program pair and see how they +differ. You should also do many of the socket programming assignments +described at the ends of Chapter 2, 4, and 9. Finally, we hope someday, +after mastering these and more advanced socket programs, you will write +your own popular network application, become very rich and famous, and +remember the authors of this textbook! + + 2.8 Summary In this chapter, we've studied the conceptual and the +implementation aspects of network applications. We've learned about the +ubiquitous client-server architecture adopted by many Internet +applications and seen its use in the HTTP, SMTP, POP3, and DNS +protocols. We've studied these important applicationlevel protocols, and +their corresponding associated applications (the Web, file transfer, +e-mail, and DNS) in some detail. We've learned about the P2P +architecture and how it is used in many applications. We've also learned +about streaming video, and how modern video distribution systems +leverage CDNs. We've examined how the socket API can be used to build +network applications. We've walked through the use of sockets for +connection-oriented (TCP) and connectionless (UDP) end-to-end transport +services. The first step in our journey down the layered network +architecture is now complete! At the very beginning of this book, in +Section 1.1, we gave a rather vague, bare-bones definition of a +protocol: "the format and the order of messages exchanged between two or +more communicating entities, as well as the actions taken on the +transmission and/or receipt of a message or other event." The material +in this chapter, and in particular our detailed study of the HTTP, SMTP, +POP3, and DNS protocols, has now added considerable substance to this +definition. Protocols are a key concept in networking; our study of +application protocols has now given us the opportunity to develop a more +intuitive feel for what protocols are all about. In Section 2.1, we +described the service models that TCP and UDP offer to applications that +invoke them. We took an even closer look at these service models when we +developed simple applications that run over TCP and UDP in Section 2.7. +However, we have said little about how TCP and UDP provide these service +models. For example, we know that TCP provides a reliable data service, +but we haven't said yet how it does so. In the next chapter we'll take a +careful look at not only the what, but also the how and why of transport +protocols. Equipped with knowledge about Internet application structure +and application-level protocols, we're now ready to head further down +the protocol stack and examine the transport layer in Chapter 3. + + Homework Problems and Questions + +Chapter 2 Review Questions + +SECTION 2.1 R1. List five nonproprietary Internet applications and the +application-layer protocols that they use. R2. What is the difference +between network architecture and application architecture? R3. For a +communication session between a pair of processes, which process is the +client and which is the server? R4. For a P2P file-sharing application, +do you agree with the statement, "There is no notion of client and +server sides of a communication session"? Why or why not? R5. What +information is used by a process running on one host to identify a +process running on another host? R6. Suppose you wanted to do a +transaction from a remote client to a server as fast as possible. Would +you use UDP or TCP? Why? R7. Referring to Figure 2.4 , we see that none +of the applications listed in Figure 2.4 requires both no data loss and +timing. Can you conceive of an application that requires no data loss +and that is also highly time-sensitive? R8. List the four broad classes +of services that a transport protocol can provide. For each of the +service classes, indicate if either UDP or TCP (or both) provides such a +service. R9. Recall that TCP can be enhanced with SSL to provide +process-to-process security services, including encryption. Does SSL +operate at the transport layer or the application layer? If the +application developer wants TCP to be enhanced with SSL, what does the +developer have to do? + +SECTION 2.2--2.5 R10. What is meant by a handshaking protocol? R11. Why +do HTTP, SMTP, and POP3 run on top of TCP rather than on UDP? R12. +Consider an e-commerce site that wants to keep a purchase record for +each of its customers. Describe how this can be done with cookies. R13. +Describe how Web caching can reduce the delay in receiving a requested +object. Will Web caching reduce the delay for all objects requested by a +user or for only some of the objects? + + Why? R14. Telnet into a Web server and send a multiline request message. +Include in the request message the If-modified-since: header line to +force a response message with the 304 Not Modified status code. R15. +List several popular messaging apps. Do they use the same protocols as +SMS? R16. Suppose Alice, with a Web-based e-mail account (such as +Hotmail or Gmail), sends a message to Bob, who accesses his mail from +his mail server using POP3. Discuss how the message gets from Alice's +host to Bob's host. Be sure to list the series of application-layer +protocols that are used to move the message between the two hosts. R17. +Print out the header of an e-mail message you have recently received. +How many Received: header lines are there? Analyze each of the header +lines in the message. R18. From a user's perspective, what is the +difference between the download-and-delete mode and the +download-and-keep mode in POP3? R19. Is it possible for an +organization's Web server and mail server to have exactly the same alias +for a hostname (for example, foo.com )? What would be the type for the +RR that contains the hostname of the mail server? R20. Look over your +received e-mails, and examine the header of a message sent from a user +with a .edu e-mail address. Is it possible to determine from the header +the IP address of the host from which the message was sent? Do the same +for a message sent from a Gmail account. + +SECTION 2.5 R21. In BitTorrent, suppose Alice provides chunks to Bob +throughout a 30-second interval. Will Bob necessarily return the favor +and provide chunks to Alice in this same interval? Why or why not? R22. +Consider a new peer Alice that joins BitTorrent without possessing any +chunks. Without any chunks, she cannot become a top-four uploader for +any of the other peers, since she has nothing to upload. How then will +Alice get her first chunk? R23. What is an overlay network? Does it +include routers? What are the edges in the overlay network? + +SECTION 2.6 R24. CDNs typically adopt one of two different server +placement philosophies. Name and briefly describe them. R25. Besides +network-related considerations such as delay, loss, and bandwidth +performance, there are other important factors that go into designing a +CDN server selection strategy. What are they? + + SECTION 2.7 R26. In Section 2.7, the UDP server described needed only +one socket, whereas the TCP server needed two sockets. Why? If the TCP +server were to support n simultaneous connections, each from a different +client host, how many sockets would the TCP server need? R27. For the +client-server application over TCP described in Section 2.7 , why must +the server program be executed before the client program? For the +client-server application over UDP, why may the client program be +executed before the server program? + +Problems P1. True or false? + +a. A user requests a Web page that consists of some text and three + images. For this page, the client will send one request message and + receive four response messages. + +b. Two distinct Web pages (for example, www.mit.edu/research.html and + www.mit.edu/students.html ) can be sent over the same persistent + connection. + +c. With nonpersistent connections between browser and origin server, it + is possible for a single TCP segment to carry two distinct HTTP + request messages. + +d. The Date: header in the HTTP response message indicates when the + object in the response was last modified. + +e. HTTP response messages never have an empty message body. P2. SMS, + iMessage, and WhatsApp are all smartphone real-time messaging + systems. After doing some research on the Internet, for each of + these systems write one paragraph about the protocols they use. Then + write a paragraph explaining how they differ. P3. Consider an HTTP + client that wants to retrieve a Web document at a given URL. The IP + address of the HTTP server is initially unknown. What transport and + application-layer protocols besides HTTP are needed in this + scenario? P4. Consider the following string of ASCII characters that + were captured by Wireshark when the browser sent an HTTP GET message + (i.e., this is the actual content of an HTTP GET message). The + characters `<cr>`{=html}`<lf>`{=html} are carriage return and + line-feed characters (that is, the italized character string + `<cr>`{=html} in the text below represents the single + carriage-return character that was contained at that point in the + HTTP header). Answer the following questions, indicating where in + the HTTP GET message below you find the answer. GET + /cs453/index.html HTTP/1.1`<cr>`{=html}`<lf>`{=html}Host: gai + a.cs.umass.edu`<cr>`{=html}`<lf>`{=html}User-Agent: Mozilla/5.0 ( + Windows;U; Windows NT 5.1; en-US; rv:1.7.2) Gec ko/20040804 + Netscape/7.2 (ax) `<cr>`{=html}`<lf>`{=html}Accept:ex + + t/xml, application/xml, application/xhtml+xml, text /html;q=0.9, +text/plain;q=0.8, image/png,*/*;q=0.5 +`<cr>`{=html}`<lf>`{=html}Accept-Language: en-us, +en;q=0.5`<cr>`{=html}`<lf>`{=html}AcceptEncoding: zip, +deflate`<cr>`{=html}`<lf>`{=html}Accept-Charset: ISO -8859-1, +utf-8;q=0.7,\*;q=0.7`<cr>`{=html}`<lf>`{=html}Keep-Alive: +300`<cr>`{=html} +`<lf>`{=html}Connection:keep-alive`<cr>`{=html}`<lf>`{=html}`<cr>`{=html}`<lf>`{=html} + +a. What is the URL of the document requested by the browser? + +b. What version of HTTP is the browser running? + +c. Does the browser request a non-persistent or a persistent + connection? + +d. What is the IP address of the host on which the browser is running? + +e. What type of browser initiates this message? Why is the browser type + needed in an HTTP request message? P5. The text below shows the + reply sent from the server in response to the HTTP GET message in + the question above. Answer the following questions, indicating where + in the message below you find the answer. HTTP/1.1 200 + OK`<cr>`{=html}`<lf>`{=html}Date: Tue, 07 Mar 2008 + 12:39:45GMT`<cr>`{=html}`<lf>`{=html}Server: Apache/2.0.52 (Fedora) + `<cr>`{=html}`<lf>`{=html}Last-Modified: Sat, 10 Dec2005 18:27:46 + GMT`<cr>`{=html}`<lf>`{=html}ETag: + "526c3-f22-a88a4c80"`<cr>`{=html}`<lf>`{=html}AcceptRanges: + bytes`<cr>`{=html}`<lf>`{=html}Content-Length: + 3874`<cr>`{=html}`<lf>`{=html} Keep-Alive: + timeout=max=100`<cr>`{=html}`<lf>`{=html}Connection: + Keep-Alive`<cr>`{=html}`<lf>`{=html}Content-Type: text/html; + charset= + ISO-8859-1`<cr>`{=html}`<lf>`{=html}`<cr>`{=html}`<lf>`{=html}\<!doctype + html public "//w3c//dtd html 4.0 transitional//en"\>`<lf>`{=html} + + ```{=html} + <html> + ``` + `<lf>`{=html} + + ```{=html} + <head> + ``` + `<lf>`{=html} + + ```{=html} + <meta http-equiv=”Content-Type” + content=”text/html; charset=iso-8859-1”> + ``` + `<lf>`{=html} \<meta name="GENERATOR" content="Mozilla/4.79 \[en\] + (Windows NT 5.0; U) Netscape\]"\>`<lf>`{=html} + + ```{=html} + <title> + ``` + CMPSCI 453 / 591 / NTU-ST550ASpring 2005 homepage + + ```{=html} + </title> + ``` + `<lf>`{=html} + + ```{=html} + </head> + ``` + `<lf>`{=html} \<much more document text following here (not shown)\> + +f. Was the server able to successfully find the document or not? What + time was the document reply provided? + +g. When was the document last modified? + +h. How many bytes are there in the document being returned? + +i. What are the first 5 bytes of the document being returned? Did the + server agree to a + + persistent connection? P6. Obtain the HTTP/1.1 specification (RFC 2616). +Answer the following questions: + +a. Explain the mechanism used for signaling between the client and + server to indicate that a persistent connection is being closed. Can + the client, the server, or both signal the close of a connection? + +b. What encryption services are provided by HTTP? + +c. Can a client open three or more simultaneous connections with a + given server? + +d. Either a server or a client may close a transport connection between + them if either one detects the connection has been idle for some + time. Is it possible that one side starts closing a connection while + the other side is transmitting data via this connection? Explain. + P7. Suppose within your Web browser you click on a link to obtain a + Web page. The IP address for the associated URL is not cached in + your local host, so a DNS lookup is necessary to obtain the IP + address. Suppose that n DNS servers are visited before your host + receives the IP address from DNS; the successive visits incur an RTT + of RTT1,. . .,RTTn. Further suppose that the Web page associated + with the link contains exactly one object, consisting of a small + amount of HTML text. Let RTT0 denote the RTT between the local host + and the server containing the object. Assuming zero transmission + time of the object, how much time elapses from when the client + clicks on the link until the client receives the object? P8. + Referring to Problem P7, suppose the HTML file references eight very + small objects on the same server. Neglecting transmission times, how + much time elapses with + +e. Non-persistent HTTP with no parallel TCP connections? + +f. Non-persistent HTTP with the browser configured for 5 parallel + connections? + +g. Persistent HTTP? P9. Consider Figure 2.12 , for which there is an + institutional network connected to the Internet. Suppose that the + average object size is 850,000 bits and that the average request + rate from the institution's browsers to the origin servers is 16 + requests per second. Also suppose that the amount of time it takes + from when the router on the Internet side of the access link + forwards an HTTP request until it receives the response is three + seconds on average (see Section 2.2.5). Model the total average + response time as the sum of the average access delay (that is, the + delay from Internet router to institution router) and the average + Internet delay. For the average access delay, use Δ/(1−Δβ), where Δ + is the average time required to send an object over the access link + and b is the arrival rate of objects to the access link. + +h. Find the total average response time. + +i. Now suppose a cache is installed in the institutional LAN. Suppose + the miss rate is 0.4. Find the total response time. + + P10. Consider a short, 10-meter link, over which a sender can transmit +at a rate of 150 bits/sec in both directions. Suppose that packets +containing data are 100,000 bits long, and packets containing only +control (e.g., ACK or handshaking) are 200 bits long. Assume that N +parallel connections each get 1/N of the link bandwidth. Now consider +the HTTP protocol, and suppose that each downloaded object is 100 Kbits +long, and that the initial downloaded object contains 10 referenced +objects from the same sender. Would parallel downloads via parallel +instances of non-persistent HTTP make sense in this case? Now consider +persistent HTTP. Do you expect significant gains over the non-persistent +case? Justify and explain your answer. P11. Consider the scenario +introduced in the previous problem. Now suppose that the link is shared +by Bob with four other users. Bob uses parallel instances of +non-persistent HTTP, and the other four users use non-persistent HTTP +without parallel downloads. + +a. Do Bob's parallel connections help him get Web pages more quickly? + Why or why not? +b. If all five users open five parallel instances of non-persistent + HTTP, then would Bob's parallel connections still be beneficial? Why + or why not? P12. Write a simple TCP program for a server that + accepts lines of input from a client and prints the lines onto the + server's standard output. (You can do this by modifying the + TCPServer.py program in the text.) Compile and execute your program. + On any other machine that contains a Web browser, set the proxy + server in the browser to the host that is running your server + program; also configure the port number appropriately. Your browser + should now send its GET request messages to your server, and your + server should display the messages on its standard output. Use this + platform to determine whether your browser generates conditional GET + messages for objects that are locally cached. P13. What is the + difference between MAIL FROM : in SMTP and From : in the mail + message itself? P14. How does SMTP mark the end of a message body? + How about HTTP? Can HTTP use the same method as SMTP to mark the end + of a message body? Explain. P15. Read RFC 5321 for SMTP. What does + MTA stand for? Consider the following received spam e-mail (modified + from a real spam e-mail). Assuming only the originator of this spam + e-mail is malicious and all other hosts are honest, identify the + malacious host that has generated this spam e-mail. + +From - Fri Nov 07 13:41:30 2008 Return-Path: <tennis5@pp33head.com> +Received: from barmail.cs.umass.edu (barmail.cs.umass.edu +\[128.119.240.3\]) by cs.umass.edu (8.13.1/8.12.6) for +<hg@cs.umass.edu>; Fri, 7 Nov 2008 13:27:10 -0500 Received: from +asusus-4b96 (localhost \[127.0.0.1\]) by barmail.cs.umass.edu (Spam +Firewall) for <hg@cs.umass.edu>; Fri, 7 + + Nov 2008 13:27:07 -0500 (EST) Received: from asusus-4b96 +(\[58.88.21.177\]) by barmail.cs.umass.edu for <hg@cs.umass.edu>; Fri, +07 Nov 2008 13:27:07 -0500 (EST) Received: from \[58.88.21.177\] by +inbnd55.exchangeddd.com; Sat, 8 Nov 2008 01:27:07 +0700 From: "Jonny" +<tennis5@pp33head.com> To: <hg@cs.umass.edu> Subject: How to secure your +savings + +P16. Read the POP3 RFC, RFC 1939. What is the purpose of the UIDL POP3 +command? P17. Consider accessing your e-mail with POP3. + +a. Suppose you have configured your POP mail client to operate in the + download-anddelete mode. Complete the following transaction: + +C: list S: 1 498 S: 2 912 S: . C: retr 1 S: blah blah ... S: +..........blah S: . ? ? + +b. Suppose you have configured your POP mail client to operate in the + download-and-keep mode. Complete the following transaction: C: list + S: 1 498 S: 2 912 S: . C: retr 1 S: blah blah ... S: ..........blah + S: . ? + + ? + +c. Suppose you have configured your POP mail client to operate in the + download-and-keep mode. Using your transcript in part (b), suppose + you retrieve messages 1 and 2, exit POP, and then five minutes later + you again access POP to retrieve new e-mail. Suppose that in the + five-minute interval no new messages have been sent to you. Provide + a transcript of this second POP session. P18. + +d. What is a whois database? + +e. Use various whois databases on the Internet to obtain the names of + two DNS servers. Indicate which whois databases you used. + +f. Use nslookup on your local host to send DNS queries to three DNS + servers: your local DNS server and the two DNS servers you found in + part (b). Try querying for Type A, NS, and MX reports. Summarize + your findings. + +g. Use nslookup to find a Web server that has multiple IP addresses. + Does the Web server of your institution (school or company) have + multiple IP addresses? + +h. Use the ARIN whois database to determine the IP address range used + by your university. + +i. Describe how an attacker can use whois databases and the nslookup + tool to perform reconnaissance on an institution before launching an + attack. + +j. Discuss why whois databases should be publicly available. P19. In + this problem, we use the useful dig tool available on Unix and Linux + hosts to explore the hierarchy of DNS servers. Recall that in Figure + 2.19 , a DNS server in the DNS hierarchy delegates a DNS query to a + DNS server lower in the hierarchy, by sending back to the DNS client + the name of that lower-level DNS server. First read the man page for + dig, and then answer the following questions. + +k. Starting with a root DNS server (from one of the root servers + \[a-m\].root-servers.net), initiate a sequence of queries for the IP + address for your department's Web server by using dig. Show the list + of the names of DNS servers in the delegation chain in answering + your query. + +l. Repeat part (a) for several popular Web sites, such as google.com, + yahoo.com, or amazon.com. P20. Suppose you can access the caches in + the local DNS servers of your department. Can you propose a way to + roughly determine the Web servers (outside your department) that are + most popular among the users in your department? Explain. P21. + Suppose that your department has a local DNS server for all + computers in the department. + + You are an ordinary user (i.e., not a network/system administrator). Can +you determine if an external Web site was likely accessed from a +computer in your department a couple of seconds ago? Explain. P22. +Consider distributing a file of F=15 Gbits to N peers. The server has an +upload rate of us=30 Mbps, and each peer has a download rate of di=2 +Mbps and an upload rate of u. For N=10, 100, and 1,000 and u=300 Kbps, +700 Kbps, and 2 Mbps, prepare a chart giving the minimum distribution +time for each of the combinations of N and u for both client-server +distribution and P2P distribution. P23. Consider distributing a file of +F bits to N peers using a client-server architecture. Assume a fluid +model where the server can simultaneously transmit to multiple peers, +transmitting to each peer at different rates, as long as the combined +rate does not exceed us. + +a. Suppose that us/N≤dmin. Specify a distribution scheme that has a + distribution time of NF/us. + +b. Suppose that us/N≥dmin. Specify a distribution scheme that has a + distribution time of F/dmin. + +c. Conclude that the minimum distribution time is in general given by + max{NF/us, F/dmin}. P24. Consider distributing a file of F bits to N + peers using a P2P architecture. Assume a fluid model. For simplicity + assume that dmin is very large, so that peer download bandwidth is + never a bottleneck. + +d. Suppose that us≤(us+u1+...+uN)/N. Specify a distribution scheme that + has a distribution time of F/us. + +e. Suppose that us≥(us+u1+...+uN)/N. Specify a distribution scheme that + has a distribution time of NF/(us+u1+...+uN). + +f. Conclude that the minimum distribution time is in general given by + max{F/us, NF/(us+u1+...+uN)}. P25. Consider an overlay network with + N active peers, with each pair of peers having an active TCP + connection. Additionally, suppose that the TCP connections pass + through a total of M routers. How many nodes and edges are there in + the corresponding overlay network? P26. Suppose Bob joins a + BitTorrent torrent, but he does not want to upload any data to any + other peers (so called free-riding). + +g. Bob claims that he can receive a complete copy of the file that is + shared by the swarm. Is Bob's claim possible? Why or why not? + +h. Bob further claims that he can further make his "free-riding" more + efficient by using a collection of multiple computers (with distinct + IP addresses) in the computer lab in his department. How can he do + that? P27. Consider a DASH system for which there are N video + versions (at N different rates and qualities) and N audio versions + (at N different rates and qualities). Suppose we want to allow the + + player to choose at any time any of the N video versions and any of the +N audio versions. + +a. If we create files so that the audio is mixed in with the video, so + server sends only one media stream at given time, how many files + will the server need to store (each a different URL)? + +b. If the server instead sends the audio and video streams separately + and has the client synchronize the streams, how many files will the + server need to store? P28. Install and compile the Python programs + TCPClient and UDPClient on one host and TCPServer and UDPServer on + another host. + +c. Suppose you run TCPClient before you run TCPServer. What happens? + Why? + +d. Suppose you run UDPClient before you run UDPServer. What happens? + Why? + +e. What happens if you use different port numbers for the client and + server sides? P29. Suppose that in UDPClient.py, after we create the + socket, we add the line: clientSocket.bind(('', 5432)) + +Will it become necessary to change UDPServer.py? What are the port +numbers for the sockets in UDPClient and UDPServer? What were they +before making this change? P30. Can you configure your browser to open +multiple simultaneous connections to a Web site? What are the advantages +and disadvantages of having a large number of simultaneous TCP +connections? P31. We have seen that Internet TCP sockets treat the data +being sent as a byte stream but UDP sockets recognize message +boundaries. What are one advantage and one disadvantage of byte-oriented +API versus having the API explicitly recognize and preserve +application-defined message boundaries? P32. What is the Apache Web +server? How much does it cost? What functionality does it currently +have? You may want to look at Wikipedia to answer this question. + +Socket Programming Assignments The Companion Website includes six socket +programming assignments. The first four assignments are summarized +below. The fifth assignment makes use of the ICMP protocol and is +summarized at the end of Chapter 5. The sixth assignment employs +multimedia protocols and is summarized at the end of Chapter 9. It is +highly recommended that students complete several, if not all, of these +assignments. Students can find full details of these assignments, as +well as important snippets of the Python code, at the Web site +www.pearsonhighered.com/cs-resources. Assignment 1: Web Server + + In this assignment, you will develop a simple Web server in Python that +is capable of processing only one request. Specifically, your Web server +will (i) create a connection socket when contacted by a client +(browser); (ii) receive the HTTP request from this connection; (iii) +parse the request to determine the specific file being requested; (iv) +get the requested file from the server's file system; (v) create an HTTP +response message consisting of the requested file preceded by header +lines; and (vi) send the response over the TCP connection to the +requesting browser. If a browser requests a file that is not present in +your server, your server should return a "404 Not Found" error message. +In the Companion Website, we provide the skeleton code for your server. +Your job is to complete the code, run your server, and then test your +server by sending requests from browsers running on different hosts. If +you run your server on a host that already has a Web server running on +it, then you should use a different port than port 80 for your Web +server. Assignment 2: UDP Pinger In this programming assignment, you +will write a client ping program in Python. Your client will send a +simple ping message to a server, receive a corresponding pong message +back from the server, and determine the delay between when the client +sent the ping message and received the pong message. This delay is +called the Round Trip Time (RTT). The functionality provided by the +client and server is similar to the functionality provided by standard +ping program available in modern operating systems. However, standard +ping programs use the Internet Control Message Protocol (ICMP) (which we +will study in Chapter 5). Here we will create a nonstandard (but +simple!) UDP-based ping program. Your ping program is to send 10 ping +messages to the target server over UDP. For each message, your client is +to determine and print the RTT when the corresponding pong message is +returned. Because UDP is an unreliable protocol, a packet sent by the +client or server may be lost. For this reason, the client cannot wait +indefinitely for a reply to a ping message. You should have the client +wait up to one second for a reply from the server; if no reply is +received, the client should assume that the packet was lost and print a +message accordingly. In this assignment, you will be given the complete +code for the server (available in the Companion Website). Your job is to +write the client code, which will be very similar to the server code. It +is recommended that you first study carefully the server code. You can +then write your client code, liberally cutting and pasting lines from +the server code. Assignment 3: Mail Client The goal of this programming +assignment is to create a simple mail client that sends e-mail to any +recipient. Your client will need to establish a TCP connection with a +mail server (e.g., a Google mail server), dialogue with the mail server +using the SMTP protocol, send an e-mail message to a recipient + + (e.g., your friend) via the mail server, and finally close the TCP +connection with the mail server. For this assignment, the Companion +Website provides the skeleton code for your client. Your job is to +complete the code and test your client by sending e-mail to different +user accounts. You may also try sending through different servers (for +example, through a Google mail server and through your university mail +server). Assignment 4: Multi-Threaded Web Proxy In this assignment, you +will develop a Web proxy. When your proxy receives an HTTP request for +an object from a browser, it generates a new HTTP request for the same +object and sends it to the origin server. When the proxy receives the +corresponding HTTP response with the object from the origin server, it +creates a new HTTP response, including the object, and sends it to the +client. This proxy will be multi-threaded, so that it will be able to +handle multiple requests at the same time. For this assignment, the +Companion Website provides the skeleton code for the proxy server. Your +job is to complete the code, and then test it by having different +browsers request Web objects via your proxy. + +Wireshark Lab: HTTP Having gotten our feet wet with the Wireshark packet +sniffer in Lab 1, we're now ready to use Wireshark to investigate +protocols in operation. In this lab, we'll explore several aspects of +the HTTP protocol: the basic GET/reply interaction, HTTP message +formats, retrieving large HTML files, retrieving HTML files with +embedded URLs, persistent and non-persistent connections, and HTTP +authentication and security. As is the case with all Wireshark labs, the +full description of this lab is available at this book's Web site, +www.pearsonhighered.com/cs-resources. + +Wireshark Lab: DNS In this lab, we take a closer look at the client side +of the DNS, the protocol that translates Internet hostnames to IP +addresses. Recall from Section 2.5 that the client's role in the DNS is +relatively simple ---a client sends a query to its local DNS server and +receives a response back. Much can go on under the covers, invisible to +the DNS clients, as the hierarchical DNS servers communicate with each +other to either recursively or iteratively resolve the client's DNS +query. From the DNS client's standpoint, however, the protocol is quite +simple---a query is formulated to the local DNS server and a response is +received from that server. We observe DNS in action in this lab. + + As is the case with all Wireshark labs, the full description of this lab +is available at this book's Web site, +www.pearsonhighered.com/cs-resources. An Interview With... Marc +Andreessen Marc Andreessen is the co-creator of Mosaic, the Web browser +that popularized the World Wide Web in 1993. Mosaic had a clean, easily +understood interface and was the first browser to display images in-line +with text. In 1994, Marc Andreessen and Jim Clark founded Netscape, +whose browser was by far the most popular browser through the mid-1990s. +Netscape also developed the Secure Sockets Layer (SSL) protocol and many +Internet server products, including mail servers and SSL-based Web +servers. He is now a co-founder and general partner of venture capital +firm Andreessen Horowitz, overseeing portfolio development with holdings +that include Facebook, Foursquare, Groupon, Jawbone, Twitter, and Zynga. +He serves on numerous boards, including Bump, eBay, Glam Media, +Facebook, and Hewlett-Packard. He holds a BS in Computer Science from +the University of Illinois at Urbana-Champaign. + +How did you become interested in computing? Did you always know that you +wanted to work in information technology? The video game and personal +computing revolutions hit right when I was growing up---personal +computing was the new technology frontier in the late 70's and early +80's. And it wasn't just Apple and the IBM PC, but hundreds of new +companies like Commodore and Atari as well. I taught myself to program +out of a book called "Instant Freeze-Dried BASIC" at age 10, and got my +first computer (a TRS-80 Color Computer---look it up!) at age 12. Please +describe one or two of the most exciting projects you have worked on +during your career. + + What were the biggest challenges? Undoubtedly the most exciting project +was the original Mosaic web browser in '92--'93---and the biggest +challenge was getting anyone to take it seriously back then. At the +time, everyone thought the interactive future would be delivered as +"interactive television" by huge companies, not as the Internet by +startups. What excites you about the future of networking and the +Internet? What are your biggest concerns? The most exciting thing is the +huge unexplored frontier of applications and services that programmers +and entrepreneurs are able to explore---the Internet has unleashed +creativity at a level that I don't think we've ever seen before. My +biggest concern is the principle of unintended consequences---we don't +always know the implications of what we do, such as the Internet being +used by governments to run a new level of surveillance on citizens. Is +there anything in particular students should be aware of as Web +technology advances? The rate of change---the most important thing to +learn is how to learn---how to flexibly adapt to changes in the specific +technologies, and how to keep an open mind on the new opportunities and +possibilities as you move through your career. What people inspired you +professionally? Vannevar Bush, Ted Nelson, Doug Engelbart, Nolan +Bushnell, Bill Hewlett and Dave Packard, Ken Olsen, Steve Jobs, Steve +Wozniak, Andy Grove, Grace Hopper, Hedy Lamarr, Alan Turing, Richard +Stallman. What are your recommendations for students who want to pursue +careers in computing and information technology? Go as deep as you +possibly can on understanding how technology is created, and then +complement with learning how business works. Can technology solve the +world's problems? No, but we advance the standard of living of people +through economic growth, and most economic growth throughout history has +come from technology---so that's as good as it gets. + + Chapter 3 Transport Layer + +Residing between the application and network layers, the transport layer +is a central piece of the layered network architecture. It has the +critical role of providing communication services directly to the +application processes running on different hosts. The pedagogic approach +we take in this chapter is to alternate between discussions of +transport-layer principles and discussions of how these principles are +implemented in existing protocols; as usual, particular emphasis will be +given to Internet protocols, in particular the TCP and UDP +transport-layer protocols. We'll begin by discussing the relationship +between the transport and network layers. This sets the stage for +examining the first critical function of the transport layer---extending +the network layer's delivery service between two end systems to a +delivery service between two application-layer processes running on the +end systems. We'll illustrate this function in our coverage of the +Internet's connectionless transport protocol, UDP. We'll then return to +principles and confront one of the most fundamental problems in computer +networking---how two entities can communicate reliably over a medium +that may lose and corrupt data. Through a series of increasingly +complicated (and realistic!) scenarios, we'll build up an array of +techniques that transport protocols use to solve this problem. We'll +then show how these principles are embodied in TCP, the Internet's +connection-oriented transport protocol. We'll next move on to a second +fundamentally important problem in networking---controlling the +transmission rate of transport-layer entities in order to avoid, or +recover from, congestion within the network. We'll consider the causes +and consequences of congestion, as well as commonly used +congestion-control techniques. After obtaining a solid understanding of +the issues behind congestion control, we'll study TCP's approach to +congestion control. + + 3.1 Introduction and Transport-Layer Services In the previous two +chapters we touched on the role of the transport layer and the services +that it provides. Let's quickly review what we have already learned +about the transport layer. A transport-layer protocol provides for +logical communication between application processes running on different +hosts. By logical communication, we mean that from an application's +perspective, it is as if the hosts running the processes were directly +connected; in reality, the hosts may be on opposite sides of the planet, +connected via numerous routers and a wide range of link types. +Application processes use the logical communication provided by the +transport layer to send messages to each other, free from the worry of +the details of the physical infrastructure used to carry these messages. +Figure 3.1 illustrates the notion of logical communication. As shown in +Figure 3.1, transport-layer protocols are implemented in the end systems +but not in network routers. On the sending side, the transport layer +converts the application-layer messages it receives from a sending +application process into transport-layer packets, known as +transport-layer segments in Internet terminology. This is done by +(possibly) breaking the application messages into smaller chunks and +adding a transport-layer header to each chunk to create the +transport-layer segment. The transport layer then passes the segment to +the network layer at the sending end system, where the segment is +encapsulated within a network-layer packet (a datagram) and sent to the +destination. It's important to note that network routers act only on the +network-layer fields of the datagram; that is, they do not examine the +fields of the transport-layer segment encapsulated with the datagram. On +the receiving side, the network layer extracts the transport-layer +segment from the datagram and passes the segment up to the transport +layer. The transport layer then processes the received segment, making +the data in the segment available to the receiving application. More +than one transport-layer protocol may be available to network +applications. For example, the Internet has two protocols---TCP and UDP. +Each of these protocols provides a different set of transportlayer +services to the invoking application. + +3.1.1 Relationship Between Transport and Network Layers Recall that the +transport layer lies just above the network layer in the protocol stack. +Whereas a transport-layer protocol provides logical communication +between + + Figure 3.1 The transport layer provides logical rather than physical +communication between application processes + +processes running on different hosts, a network-layer protocol provides +logical-communication between hosts. This distinction is subtle but +important. Let's examine this distinction with the aid of a household +analogy. Consider two houses, one on the East Coast and the other on the +West Coast, with each house being home to a dozen kids. The kids in the +East Coast household are cousins of the kids in the West Coast + + household. The kids in the two households love to write to each +other---each kid writes each cousin every week, with each letter +delivered by the traditional postal service in a separate envelope. +Thus, each household sends 144 letters to the other household every +week. (These kids would save a lot of money if they had e-mail!) In each +of the households there is one kid---Ann in the West Coast house and +Bill in the East Coast house---responsible for mail collection and mail +distribution. Each week Ann visits all her brothers and sisters, +collects the mail, and gives the mail to a postal-service mail carrier, +who makes daily visits to the house. When letters arrive at the West +Coast house, Ann also has the job of distributing the mail to her +brothers and sisters. Bill has a similar job on the East Coast. In this +example, the postal service provides logical communication between the +two houses---the postal service moves mail from house to house, not from +person to person. On the other hand, Ann and Bill provide logical +communication among the cousins---Ann and Bill pick up mail from, and +deliver mail to, their brothers and sisters. Note that from the cousins' +perspective, Ann and Bill are the mail service, even though Ann and Bill +are only a part (the end-system part) of the end-to-end delivery +process. This household example serves as a nice analogy for explaining +how the transport layer relates to the network layer: application +messages = letters in envelopes processes = cousins hosts (also called +end systems) = houses transport-layer protocol = Ann and Bill +network-layer protocol = postal service (including mail carriers) +Continuing with this analogy, note that Ann and Bill do all their work +within their respective homes; they are not involved, for example, in +sorting mail in any intermediate mail center or in moving mail from one +mail center to another. Similarly, transport-layer protocols live in the +end systems. Within an end system, a transport protocol moves messages +from application processes to the network edge (that is, the network +layer) and vice versa, but it doesn't have any say about how the +messages are moved within the network core. In fact, as illustrated in +Figure 3.1, intermediate routers neither act on, nor recognize, any +information that the transport layer may have added to the application +messages. Continuing with our family saga, suppose now that when Ann and +Bill go on vacation, another cousin pair---say, Susan and +Harvey---substitute for them and provide the household-internal +collection and delivery of mail. Unfortunately for the two families, +Susan and Harvey do not do the collection and delivery in exactly the +same way as Ann and Bill. Being younger kids, Susan and Harvey pick up +and drop off the mail less frequently and occasionally lose letters +(which are sometimes chewed up by the family dog). Thus, the cousin-pair +Susan and Harvey do not provide the same set of services (that is, the +same service model) as Ann and Bill. In an analogous manner, a computer +network may make + + available multiple transport protocols, with each protocol offering a +different service model to applications. The possible services that Ann +and Bill can provide are clearly constrained by the possible services +that the postal service provides. For example, if the postal service +doesn't provide a maximum bound on how long it can take to deliver mail +between the two houses (for example, three days), then there is no way +that Ann and Bill can guarantee a maximum delay for mail delivery +between any of the cousin pairs. In a similar manner, the services that +a transport protocol can provide are often constrained by the service +model of the underlying network-layer protocol. If the network-layer +protocol cannot provide delay or bandwidth guarantees for +transport-layer segments sent between hosts, then the transport-layer +protocol cannot provide delay or bandwidth guarantees for application +messages sent between processes. Nevertheless, certain services can be +offered by a transport protocol even when the underlying network +protocol doesn't offer the corresponding service at the network layer. +For example, as we'll see in this chapter, a transport protocol can +offer reliable data transfer service to an application even when the +underlying network protocol is unreliable, that is, even when the +network protocol loses, garbles, or duplicates packets. As another +example (which we'll explore in Chapter 8 when we discuss network +security), a transport protocol can use encryption to guarantee that +application messages are not read by intruders, even when the network +layer cannot guarantee the confidentiality of transport-layer segments. + +3.1.2 Overview of the Transport Layer in the Internet Recall that the +Internet makes two distinct transport-layer protocols available to the +application layer. One of these protocols is UDP (User Datagram +Protocol), which provides an unreliable, connectionless service to the +invoking application. The second of these protocols is TCP (Transmission +Control Protocol), which provides a reliable, connection-oriented +service to the invoking application. When designing a network +application, the application developer must specify one of these two +transport protocols. As we saw in Section 2.7, the application developer +selects between UDP and TCP when creating sockets. To simplify +terminology, we refer to the transport-layer packet as a segment. We +mention, however, that the Internet literature (for example, the RFCs) +also refers to the transport-layer packet for TCP as a segment but often +refers to the packet for UDP as a datagram. But this same Internet +literature also uses the term datagram for the network-layer packet! For +an introductory book on computer networking such as this, we believe +that it is less confusing to refer to both TCP and UDP packets as +segments, and reserve the term datagram for the network-layer packet. + + Before proceeding with our brief introduction of UDP and TCP, it will be +useful to say a few words about the Internet's network layer. (We'll +learn about the network layer in detail in Chapters 4 and 5.) The +Internet's network-layer protocol has a name---IP, for Internet +Protocol. IP provides logical communication between hosts. The IP +service model is a best-effort delivery service. This means that IP +makes its "best effort" to deliver segments between communicating hosts, +but it makes no guarantees. In particular, it does not guarantee segment +delivery, it does not guarantee orderly delivery of segments, and it +does not guarantee the integrity of the data in the segments. For these +reasons, IP is said to be an unreliable service. We also mention here +that every host has at least one networklayer address, a so-called IP +address. We'll examine IP addressing in detail in Chapter 4; for this +chapter we need only keep in mind that each host has an IP address. +Having taken a glimpse at the IP service model, let's now summarize the +service models provided by UDP and TCP. The most fundamental +responsibility of UDP and TCP is to extend IP's delivery service between +two end systems to a delivery service between two processes running on +the end systems. Extending host-to-host delivery to process-to-process +delivery is called transport-layer multiplexing and demultiplexing. +We'll discuss transport-layer multiplexing and demultiplexing in the +next section. UDP and TCP also provide integrity checking by including +error-detection fields in their segments' headers. These two minimal +transport-layer services---process-to-process data delivery and error +checking---are the only two services that UDP provides! In particular, +like IP, UDP is an unreliable service---it does not guarantee that data +sent by one process will arrive intact (or at all!) to the destination +process. UDP is discussed in detail in Section 3.3. TCP, on the other +hand, offers several additional services to applications. First and +foremost, it provides reliable data transfer. Using flow control, +sequence numbers, acknowledgments, and timers (techniques we'll explore +in detail in this chapter), TCP ensures that data is delivered from +sending process to receiving process, correctly and in order. TCP thus +converts IP's unreliable service between end systems into a reliable +data transport service between processes. TCP also provides congestion +control. Congestion control is not so much a service provided to the +invoking application as it is a service for the Internet as a whole, a +service for the general good. Loosely speaking, TCP congestion control +prevents any one TCP connection from swamping the links and routers +between communicating hosts with an excessive amount of traffic. TCP +strives to give each connection traversing a congested link an equal +share of the link bandwidth. This is done by regulating the rate at +which the sending sides of TCP connections can send traffic into the +network. UDP traffic, on the other hand, is unregulated. An application +using UDP transport can send at any rate it pleases, for as long as it +pleases. A protocol that provides reliable data transfer and congestion +control is necessarily complex. We'll need several sections to cover the +principles of reliable data transfer and congestion control, and +additional sections to cover the TCP protocol itself. These topics are +investigated in Sections 3.4 through 3.8. The approach taken in this +chapter is to alternate between basic principles and the TCP protocol. +For example, we'll first discuss reliable data transfer in a general +setting and then discuss how TCP + + specifically provides reliable data transfer. Similarly, we'll first +discuss congestion control in a general setting and then discuss how TCP +performs congestion control. But before getting into all this good +stuff, let's first look at transport-layer multiplexing and +demultiplexing. + + 3.2 Multiplexing and Demultiplexing In this section, we discuss +transport-layer multiplexing and demultiplexing, that is, extending the +host-tohost delivery service provided by the network layer to a +process-to-process delivery service for applications running on the +hosts. In order to keep the discussion concrete, we'll discuss this +basic transport-layer service in the context of the Internet. We +emphasize, however, that a multiplexing/demultiplexing service is needed +for all computer networks. At the destination host, the transport layer +receives segments from the network layer just below. The transport layer +has the responsibility of delivering the data in these segments to the +appropriate application process running in the host. Let's take a look +at an example. Suppose you are sitting in front of your computer, and +you are downloading Web pages while running one FTP session and two +Telnet sessions. You therefore have four network application processes +running---two Telnet processes, one FTP process, and one HTTP process. +When the transport layer in your computer receives data from the network +layer below, it needs to direct the received data to one of these four +processes. Let's now examine how this is done. First recall from Section +2.7 that a process (as part of a network application) can have one or +more sockets, doors through which data passes from the network to the +process and through which data passes from the process to the network. +Thus, as shown in Figure 3.2, the transport layer in the receiving host +does not actually deliver data directly to a process, but instead to an +intermediary socket. Because at any given time there can be more than +one socket in the receiving host, each socket has a unique identifier. +The format of the identifier depends on whether the socket is a UDP or a +TCP socket, as we'll discuss shortly. Now let's consider how a receiving +host directs an incoming transport-layer segment to the appropriate +socket. Each transport-layer segment has a set of fields in the segment +for this purpose. At the receiving end, the transport layer examines +these fields to identify the receiving socket and then directs the +segment to that socket. This job of delivering the data in a +transport-layer segment to the correct socket is called demultiplexing. +The job of gathering data chunks at the source host from different +sockets, encapsulating each data chunk with header information (that +will later be used in demultiplexing) to create segments, and passing +the segments to the network layer is called multiplexing. Note that the +transport layer in the middle host + + Figure 3.2 Transport-layer multiplexing and demultiplexing + +in Figure 3.2 must demultiplex segments arriving from the network layer +below to either process P1 or P2 above; this is done by directing the +arriving segment's data to the corresponding process's socket. The +transport layer in the middle host must also gather outgoing data from +these sockets, form transportlayer segments, and pass these segments +down to the network layer. Although we have introduced multiplexing and +demultiplexing in the context of the Internet transport protocols, it's +important to realize that they are concerns whenever a single protocol +at one layer (at the transport layer or elsewhere) is used by multiple +protocols at the next higher layer. To illustrate the demultiplexing +job, recall the household analogy in the previous section. Each of the +kids is identified by his or her name. When Bill receives a batch of +mail from the mail carrier, he performs a demultiplexing operation by +observing to whom the letters are addressed and then hand delivering the +mail to his brothers and sisters. Ann performs a multiplexing operation +when she collects letters from her brothers and sisters and gives the +collected mail to the mail person. Now that we understand the roles of +transport-layer multiplexing and demultiplexing, let us examine how it +is actually done in a host. From the discussion above, we know that +transport-layer multiplexing requires (1) that sockets have unique +identifiers, and (2) that each segment have special fields that indicate +the socket to which the segment is to be delivered. These special +fields, illustrated in Figure 3.3, are the source port number field and +the destination port number field. (The UDP and TCP segments have other +fields as well, as discussed in the subsequent sections of this +chapter.) Each port number is a 16-bit number, ranging from 0 to 65535. +The port numbers ranging from 0 to 1023 are called well-known port +numbers and are restricted, which means that they are reserved for use +by well-known + + Figure 3.3 Source and destination port-number fields in a +transport-layer segment + +application protocols such as HTTP (which uses port number 80) and FTP +(which uses port number 21). The list of well-known port numbers is +given in RFC 1700 and is updated at http://www.iana.org \[RFC 3232\]. +When we develop a new application (such as the simple application +developed in Section 2.7), we must assign the application a port number. +It should now be clear how the transport layer could implement the +demultiplexing service: Each socket in the host could be assigned a port +number, and when a segment arrives at the host, the transport layer +examines the destination port number in the segment and directs the +segment to the corresponding socket. The segment's data then passes +through the socket into the attached process. As we'll see, this is +basically how UDP does it. However, we'll also see that +multiplexing/demultiplexing in TCP is yet more subtle. Connectionless +Multiplexing and Demultiplexing Recall from Section 2.7.1 that the +Python program running in a host can create a UDP socket with the line + +clientSocket = socket(AF_INET, SOCK_DGRAM) + +When a UDP socket is created in this manner, the transport layer +automatically assigns a port number to the socket. In particular, the +transport layer assigns a port number in the range 1024 to 65535 that is +currently not being used by any other UDP port in the host. +Alternatively, we can add a line into our Python program after we create +the socket to associate a specific port number (say, 19157) to this UDP +socket via the socket bind() method: + +clientSocket.bind(('', 19157)) + + If the application developer writing the code were implementing the +server side of a "well-known protocol," then the developer would have to +assign the corresponding well-known port number. Typically, the client +side of the application lets the transport layer automatically (and +transparently) assign the port number, whereas the server side of the +application assigns a specific port number. With port numbers assigned +to UDP sockets, we can now precisely describe UDP +multiplexing/demultiplexing. Suppose a process in Host A, with UDP port +19157, wants to send a chunk of application data to a process with UDP +port 46428 in Host B. The transport layer in Host A creates a +transport-layer segment that includes the application data, the source +port number (19157), the destination port number (46428), and two other +values (which will be discussed later, but are unimportant for the +current discussion). The transport layer then passes the resulting +segment to the network layer. The network layer encapsulates the segment +in an IP datagram and makes a best-effort attempt to deliver the segment +to the receiving host. If the segment arrives at the receiving Host B, +the transport layer at the receiving host examines the destination port +number in the segment (46428) and delivers the segment to its socket +identified by port 46428. Note that Host B could be running multiple +processes, each with its own UDP socket and associated port number. As +UDP segments arrive from the network, Host B directs (demultiplexes) +each segment to the appropriate socket by examining the segment's +destination port number. It is important to note that a UDP socket is +fully identified by a two-tuple consisting of a destination IP address +and a destination port number. As a consequence, if two UDP segments +have different source IP addresses and/or source port numbers, but have +the same destination IP address and destination port number, then the +two segments will be directed to the same destination process via the +same destination socket. You may be wondering now, what is the purpose +of the source port number? As shown in Figure 3.4, in the A-to-B segment +the source port number serves as part of a "return address"---when B +wants to send a segment back to A, the destination port in the B-to-A +segment will take its value from the source port value of the A-to-B +segment. (The complete return address is A's IP address and the source +port number.) As an example, recall the UDP server program studied in +Section 2.7. In UDPServer.py , the server uses the recvfrom() method to +extract the client-side (source) port number from the segment it +receives from the client; it then sends a new segment to the client, +with the extracted source port number serving as the destination port +number in this new segment. Connection-Oriented Multiplexing and +Demultiplexing In order to understand TCP demultiplexing, we have to +take a close look at TCP sockets and TCP connection establishment. One +subtle difference between a TCP socket and a UDP socket is that a TCP + + socket is identified by a four-tuple: (source IP address, source port +number, destination IP address, destination port number). Thus, when a +TCP segment arrives from the network to a host, the host uses all four +values to direct (demultiplex) the segment to the appropriate socket. + +Figure 3.4 The inversion of source and destination port numbers + +In particular, and in contrast with UDP, two arriving TCP segments with +different source IP addresses or source port numbers will (with the +exception of a TCP segment carrying the original connectionestablishment +request) be directed to two different sockets. To gain further insight, +let's reconsider the TCP client-server programming example in Section +2.7.2: The TCP server application has a "welcoming socket," that waits +for connection-establishment requests from TCP clients (see Figure 2.29) +on port number 12000. The TCP client creates a socket and sends a +connection establishment request segment with the lines: + +clientSocket = socket(AF_INET, SOCK_STREAM) +clientSocket.connect((serverName,12000)) + +A connection-establishment request is nothing more than a TCP segment +with destination port number 12000 and a special +connection-establishment bit set in the TCP header (discussed in Section +3.5). The segment also includes a source port number that was chosen by +the client. When the host operating system of the computer running the +server process receives the incoming + + connection-request segment with destination port 12000, it locates the +server process that is waiting to accept a connection on port number +12000. The server process then creates a new socket: connectionSocket, +addr = serverSocket.accept() + +Also, the transport layer at the server notes the following four values +in the connection-request segment: (1) the source port number in the +segment, (2) the IP address of the source host, (3) the destination port +number in the segment, and (4) its own IP address. The newly created +connection socket is identified by these four values; all subsequently +arriving segments whose source port, source IP address, destination +port, and destination IP address match these four values will be +demultiplexed to this socket. With the TCP connection now in place, the +client and server can now send data to each other. The server host may +support many simultaneous TCP connection sockets, with each socket +attached to a process, and with each socket identified by its own +four-tuple. When a TCP segment arrives at the host, all four fields +(source IP address, source port, destination IP address, destination +port) are used to direct (demultiplex) the segment to the appropriate +socket. + +FOCUS ON SECURITY Port Scanning We've seen that a server process waits +patiently on an open port for contact by a remote client. Some ports are +reserved for well-known applications (e.g., Web, FTP, DNS, and SMTP +servers); other ports are used by convention by popular applications +(e.g., the Microsoft 2000 SQL server listens for requests on UDP port +1434). Thus, if we determine that a port is open on a host, we may be +able to map that port to a specific application running on the host. +This is very useful for system administrators, who are often interested +in knowing which network applications are running on the hosts in their +networks. But attackers, in order to "case the joint," also want to know +which ports are open on target hosts. If a host is found to be running +an application with a known security flaw (e.g., a SQL server listening +on port 1434 was subject to a buffer overflow, allowing a remote user to +execute arbitrary code on the vulnerable host, a flaw exploited by the +Slammer worm \[CERT 2003--04\]), then that host is ripe for attack. +Determining which applications are listening on which ports is a +relatively easy task. Indeed there are a number of public domain +programs, called port scanners, that do just that. Perhaps the most +widely used of these is nmap, freely available at http://nmap.org and +included in most Linux distributions. For TCP, nmap sequentially scans +ports, looking for ports that are accepting TCP connections. For UDP, +nmap again sequentially scans ports, looking for UDP ports that respond +to transmitted UDP segments. In both cases, nmap returns a list of open, +closed, or unreachable ports. A host running nmap can attempt to scan +any target host anywhere in the + + Internet. We'll revisit nmap in Section 3.5.6, when we discuss TCP +connection management. + +Figure 3.5 Two clients, using the same destination port number (80) to +communicate with the same Web server application + +The situation is illustrated in Figure 3.5, in which Host C initiates +two HTTP sessions to server B, and Host A initiates one HTTP session to +B. Hosts A and C and server B each have their own unique IP address---A, +C, and B, respectively. Host C assigns two different source port numbers +(26145 and 7532) to its two HTTP connections. Because Host A is choosing +source port numbers independently of C, it might also assign a source +port of 26145 to its HTTP connection. But this is not a problem---server +B will still be able to correctly demultiplex the two connections having +the same source port number, since the two connections have different +source IP addresses. Web Servers and TCP Before closing this discussion, +it's instructive to say a few additional words about Web servers and how +they use port numbers. Consider a host running a Web server, such as an +Apache Web server, on port 80. When clients (for example, browsers) send +segments to the server, all segments will have destination port 80. In +particular, both the initial connection-establishment segments and the +segments carrying HTTP request messages will have destination port 80. +As we have just described, the server distinguishes the segments from +the different clients using source IP addresses and source port + + numbers. Figure 3.5 shows a Web server that spawns a new process for +each connection. As shown in Figure 3.5, each of these processes has its +own connection socket through which HTTP requests arrive and HTTP +responses are sent. We mention, however, that there is not always a +one-to-one correspondence between connection sockets and processes. In +fact, today's high-performing Web servers often use only one process, +and create a new thread with a new connection socket for each new client +connection. (A thread can be viewed as a lightweight subprocess.) If you +did the first programming assignment in Chapter 2, you built a Web +server that does just this. For such a server, at any given time there +may be many connection sockets (with different identifiers) attached to +the same process. If the client and server are using persistent HTTP, +then throughout the duration of the persistent connection the client and +server exchange HTTP messages via the same server socket. However, if +the client and server use non-persistent HTTP, then a new TCP connection +is created and closed for every request/response, and hence a new socket +is created and later closed for every request/response. This frequent +creating and closing of sockets can severely impact the performance of a +busy Web server (although a number of operating system tricks can be +used to mitigate the problem). Readers interested in the operating +system issues surrounding persistent and non-persistent HTTP are +encouraged to see \[Nielsen 1997; Nahum 2002\]. Now that we've discussed +transport-layer multiplexing and demultiplexing, let's move on and +discuss one of the Internet's transport protocols, UDP. In the next +section we'll see that UDP adds little more to the network-layer +protocol than a multiplexing/demultiplexing service. + + 3.3 Connectionless Transport: UDP In this section, we'll take a close +look at UDP, how it works, and what it does. We encourage you to refer +back to Section 2.1, which includes an overview of the UDP service +model, and to Section 2.7.1, which discusses socket programming using +UDP. To motivate our discussion about UDP, suppose you were interested +in designing a no-frills, bare-bones transport protocol. How might you +go about doing this? You might first consider using a vacuous transport +protocol. In particular, on the sending side, you might consider taking +the messages from the application process and passing them directly to +the network layer; and on the receiving side, you might consider taking +the messages arriving from the network layer and passing them directly +to the application process. But as we learned in the previous section, +we have to do a little more than nothing! At the very least, the +transport layer has to provide a multiplexing/demultiplexing service in +order to pass data between the network layer and the correct +application-level process. UDP, defined in \[RFC 768\], does just about +as little as a transport protocol can do. Aside from the +multiplexing/demultiplexing function and some light error checking, it +adds nothing to IP. In fact, if the application developer chooses UDP +instead of TCP, then the application is almost directly talking with IP. +UDP takes messages from the application process, attaches source and +destination port number fields for the multiplexing/demultiplexing +service, adds two other small fields, and passes the resulting segment +to the network layer. The network layer encapsulates the transport-layer +segment into an IP datagram and then makes a best-effort attempt to +deliver the segment to the receiving host. If the segment arrives at the +receiving host, UDP uses the destination port number to deliver the +segment's data to the correct application process. Note that with UDP +there is no handshaking between sending and receiving transport-layer +entities before sending a segment. For this reason, UDP is said to be +connectionless. DNS is an example of an application-layer protocol that +typically uses UDP. When the DNS application in a host wants to make a +query, it constructs a DNS query message and passes the message to UDP. +Without performing any handshaking with the UDP entity running on the +destination end system, the host-side UDP adds header fields to the +message and passes the resulting segment to the network layer. The +network layer encapsulates the UDP segment into a datagram and sends the +datagram to a name server. The DNS application at the querying host then +waits for a reply to its query. If it doesn't receive a reply (possibly +because the underlying network lost the query or the reply), it might +try resending the query, try sending the query to another name server, +or inform the invoking application that it can't get a reply. + + Now you might be wondering why an application developer would ever +choose to build an application over UDP rather than over TCP. Isn't TCP +always preferable, since TCP provides a reliable data transfer service, +while UDP does not? The answer is no, as some applications are better +suited for UDP for the following reasons: Finer application-level +control over what data is sent, and when. Under UDP, as soon as an +application process passes data to UDP, UDP will package the data inside +a UDP segment and immediately pass the segment to the network layer. +TCP, on the other hand, has a congestioncontrol mechanism that throttles +the transport-layer TCP sender when one or more links between the source +and destination hosts become excessively congested. TCP will also +continue to resend a segment until the receipt of the segment has been +acknowledged by the destination, regardless of how long reliable +delivery takes. Since real-time applications often require a minimum +sending rate, do not want to overly delay segment transmission, and can +tolerate some data loss, TCP's service model is not particularly well +matched to these applications' needs. As discussed below, these +applications can use UDP and implement, as part of the application, any +additional functionality that is needed beyond UDP's no-frills +segment-delivery service. No connection establishment. As we'll discuss +later, TCP uses a three-way handshake before it starts to transfer data. +UDP just blasts away without any formal preliminaries. Thus UDP does not +introduce any delay to establish a connection. This is probably the +principal reason why DNS runs over UDP rather than TCP---DNS would be +much slower if it ran over TCP. HTTP uses TCP rather than UDP, since +reliability is critical for Web pages with text. But, as we briefly +discussed in Section 2.2, the TCP connection-establishment delay in HTTP +is an important contributor to the delays associated with downloading +Web documents. Indeed, the QUIC protocol (Quick UDP Internet Connection, +\[Iyengar 2015\]), used in Google's Chrome browser, uses UDP as its +underlying transport protocol and implements reliability in an +application-layer protocol on top of UDP. No connection state. TCP +maintains connection state in the end systems. This connection state +includes receive and send buffers, congestion-control parameters, and +sequence and acknowledgment number parameters. We will see in Section +3.5 that this state information is needed to implement TCP's reliable +data transfer service and to provide congestion control. UDP, on the +other hand, does not maintain connection state and does not track any of +these parameters. For this reason, a server devoted to a particular +application can typically support many more active clients when the +application runs over UDP rather than TCP. Small packet header overhead. +The TCP segment has 20 bytes of header overhead in every segment, +whereas UDP has only 8 bytes of overhead. Figure 3.6 lists popular +Internet applications and the transport protocols that they use. As we +expect, email, remote terminal access, the Web, and file transfer run +over TCP---all these applications need the reliable data transfer +service of TCP. Nevertheless, many important applications run over UDP +rather than TCP. For example, UDP is used to carry network management +(SNMP; see Section 5.7) data. UDP is preferred to TCP in this case, +since network management applications must often run when the + + network is in a stressed state---precisely when reliable, +congestion-controlled data transfer is difficult to achieve. Also, as we +mentioned earlier, DNS runs over UDP, thereby avoiding TCP's +connectionestablishment delays. As shown in Figure 3.6, both UDP and TCP +are somtimes used today with multimedia applications, such as Internet +phone, real-time video conferencing, and streaming of stored audio and +video. We'll take a close look at these applications in Chapter 9. We +just mention now that all of these applications can tolerate a small +amount of packet loss, so that reliable data transfer is not absolutely +critical for the application's success. Furthermore, real-time +applications, like Internet phone and video conferencing, react very +poorly to TCP's congestion control. For these reasons, developers of +multimedia applications may choose to run their applications over UDP +instead of TCP. When packet loss rates are low, and with some +organizations blocking UDP traffic for security reasons (see Chapter 8), +TCP becomes an increasingly attractive protocol for streaming media +transport. + +Figure 3.6 Popular Internet applications and their underlying transport +protocols + +Although commonly done today, running multimedia applications over UDP +is controversial. As we mentioned above, UDP has no congestion control. +But congestion control is needed to prevent the network from entering a +congested state in which very little useful work is done. If everyone +were to start streaming high-bit-rate video without using any congestion +control, there would be so much packet overflow at routers that very few +UDP packets would successfully traverse the source-to-destination path. +Moreover, the high loss rates induced by the uncontrolled UDP senders +would cause the TCP senders (which, as we'll see, do decrease their +sending rates in the face of congestion) to dramatically decrease their +rates. Thus, the lack of congestion control in UDP can result in high +loss rates between a UDP sender and receiver, and the crowding out of +TCP sessions---a potentially serious problem \[Floyd + + 1999\]. Many researchers have proposed new mechanisms to force all +sources, including UDP sources, to perform adaptive congestion control +\[Mahdavi 1997; Floyd 2000; Kohler 2006: RFC 4340\]. Before discussing +the UDP segment structure, we mention that it is possible for an +application to have reliable data transfer when using UDP. This can be +done if reliability is built into the application itself (for example, +by adding acknowledgment and retransmission mechanisms, such as those +we'll study in the next section). We mentioned earlier that the QUIC +protocol \[Iyengar 2015\] used in Google's Chrome browser implements +reliability in an application-layer protocol on top of UDP. But this is +a nontrivial task that would keep an application developer busy +debugging for a long time. Nevertheless, building reliability directly +into the application allows the application to "have its cake and eat it +too. That is, application processes can communicate reliably without +being subjected to the transmission-rate constraints imposed by TCP's +congestion-control mechanism. + +3.3.1 UDP Segment Structure The UDP segment structure, shown in Figure +3.7, is defined in RFC 768. The application data occupies the data field +of the UDP segment. For example, for DNS, the data field contains either +a query message or a response message. For a streaming audio +application, audio samples fill the data field. The UDP header has only +four fields, each consisting of two bytes. As discussed in the previous +section, the port numbers allow the destination host to pass the +application data to the correct process running on the destination end +system (that is, to perform the demultiplexing function). The length +field specifies the number of bytes in the UDP segment (header plus +data). An explicit length value is needed since the size of the data +field may differ from one UDP segment to the next. The checksum is used +by the receiving host to check whether errors have been introduced into +the segment. In truth, the checksum is also calculated over a few of the +fields in the IP header in addition to the UDP segment. But we ignore +this detail in order to see the forest through the trees. We'll discuss +the checksum calculation below. Basic principles of error detection are +described in Section 6.2. The length field specifies the length of the +UDP segment, including the header, in bytes. + +3.3.2 UDP Checksum The UDP checksum provides for error detection. That +is, the checksum is used to determine whether bits within the UDP +segment have been altered (for example, by noise in the links or while +stored in a router) as it moved from source to destination. + + Figure 3.7 UDP segment structure + +UDP at the sender side performs the 1s complement of the sum of all the +16-bit words in the segment, with any overflow encountered during the +sum being wrapped around. This result is put in the checksum field of +the UDP segment. Here we give a simple example of the checksum +calculation. You can find details about efficient implementation of the +calculation in RFC 1071 and performance over real data in \[Stone 1998; +Stone 2000\]. As an example, suppose that we have the following three +16-bit words: 0110011001100000 0101010101010101 1000111100001100 The sum +of first two of these 16-bit words is 0110011001100000 0101010101010101 +1011101110110101 Adding the third word to the above sum gives +1011101110110101 1000111100001100 0100101011000010 Note that this last +addition had overflow, which was wrapped around. The 1s complement is +obtained by converting all the 0s to 1s and converting all the 1s to 0s. +Thus the 1s complement of the sum 0100101011000010 is 1011010100111101, +which becomes the checksum. At the receiver, all four 16- + + bit words are added, including the checksum. If no errors are introduced +into the packet, then clearly the sum at the receiver will be +1111111111111111. If one of the bits is a 0, then we know that errors +have been introduced into the packet. You may wonder why UDP provides a +checksum in the first place, as many link-layer protocols (including the +popular Ethernet protocol) also provide error checking. The reason is +that there is no guarantee that all the links between source and +destination provide error checking; that is, one of the links may use a +link-layer protocol that does not provide error checking. Furthermore, +even if segments are correctly transferred across a link, it's possible +that bit errors could be introduced when a segment is stored in a +router's memory. Given that neither link-by-link reliability nor +in-memory error detection is guaranteed, UDP must provide error +detection at the transport layer, on an end-end basis, if the endend +data transfer service is to provide error detection. This is an example +of the celebrated end-end principle in system design \[Saltzer 1984\], +which states that since certain functionality (error detection, in this +case) must be implemented on an end-end basis: "functions placed at the +lower levels may be redundant or of little value when compared to the +cost of providing them at the higher level." Because IP is supposed to +run over just about any layer-2 protocol, it is useful for the transport +layer to provide error checking as a safety measure. Although UDP +provides error checking, it does not do anything to recover from an +error. Some implementations of UDP simply discard the damaged segment; +others pass the damaged segment to the application with a warning. That +wraps up our discussion of UDP. We will soon see that TCP offers +reliable data transfer to its applications as well as other services +that UDP doesn't offer. Naturally, TCP is also more complex than UDP. +Before discussing TCP, however, it will be useful to step back and first +discuss the underlying principles of reliable data transfer. + + 3.4 Principles of Reliable Data Transfer In this section, we consider +the problem of reliable data transfer in a general context. This is +appropriate since the problem of implementing reliable data transfer +occurs not only at the transport layer, but also at the link layer and +the application layer as well. The general problem is thus of central +importance to networking. Indeed, if one had to identify a "top-ten" +list of fundamentally important problems in all of networking, this +would be a candidate to lead the list. In the next section we'll examine +TCP and show, in particular, that TCP exploits many of the principles +that we are about to describe. Figure 3.8 illustrates the framework for +our study of reliable data transfer. The service abstraction provided to +the upper-layer entities is that of a reliable channel through which +data can be transferred. With a reliable channel, no transferred data +bits are corrupted (flipped from 0 to 1, or vice versa) or lost, and all +are delivered in the order in which they were sent. This is precisely +the service model offered by TCP to the Internet applications that +invoke it. It is the responsibility of a reliable data transfer protocol +to implement this service abstraction. This task is made difficult by +the fact that the layer below the reliable data transfer protocol may be +unreliable. For example, TCP is a reliable data transfer protocol that +is implemented on top of an unreliable (IP) end-to-end network layer. +More generally, the layer beneath the two reliably communicating end +points might consist of a single physical link (as in the case of a +link-level data transfer protocol) or a global internetwork (as in the +case of a transport-level protocol). For our purposes, however, we can +view this lower layer simply as an unreliable point-to-point channel. In +this section, we will incrementally develop the sender and receiver +sides of a reliable data transfer protocol, considering increasingly +complex models of the underlying channel. For example, we'll consider +what protocol mechanisms are + + Figure 3.8 Reliable data transfer: Service model and service +implementation + + needed when the underlying channel can corrupt bits or lose entire +packets. One assumption we'll adopt throughout our discussion here is +that packets will be delivered in the order in which they were sent, +with some packets possibly being lost; that is, the underlying channel +will not reorder packets. Figure 3.8(b) illustrates the interfaces for +our data transfer protocol. The sending side of the data transfer +protocol will be invoked from above by a call to rdt_send() . It will +pass the data to be delivered to the upper layer at the receiving side. +(Here rdt stands for reliable data transfer protocol and \_send +indicates that the sending side of rdt is being called. The first step +in developing any protocol is to choose a good name!) On the receiving +side, rdt_rcv() will be called when a packet arrives from the receiving +side of the channel. When the rdt protocol wants to deliver data to the +upper layer, it will do so by calling deliver_data() . In the following +we use the terminology "packet" rather than transport-layer "segment." +Because the theory developed in this section applies to computer +networks in general and not just to the Internet transport layer, the +generic term "packet" is perhaps more appropriate here. In this section +we consider only the case of unidirectional data transfer, that is, data +transfer from the sending to the receiving side. The case of reliable +bidirectional (that is, full-duplex) data transfer is conceptually no +more difficult but considerably more tedious to explain. Although we +consider only unidirectional data transfer, it is important to note that +the sending and receiving sides of our protocol will nonetheless need to +transmit packets in both directions, as indicated in Figure 3.8. We will +see shortly that, in addition to exchanging packets containing the data +to be transferred, the sending and receiving sides of rdt will also need +to exchange control packets back and forth. Both the send and receive +sides of rdt send packets to the other side by a call to udt_send() +(where udt stands for unreliable data transfer). + +3.4.1 Building a Reliable Data Transfer Protocol We now step through a +series of protocols, each one becoming more complex, arriving at a +flawless, reliable data transfer protocol. Reliable Data Transfer over a +Perfectly Reliable Channel: rdt1.0 We first consider the simplest case, +in which the underlying channel is completely reliable. The protocol +itself, which we'll call rdt1.0 , is trivial. The finite-state machine +(FSM) definitions for the rdt1.0 sender and receiver are shown in Figure +3.9. The FSM in Figure 3.9(a) defines the operation of the sender, while +the FSM in Figure 3.9(b) defines the operation of the receiver. It is +important to note that there are separate FSMs for the sender and for +the receiver. The sender and receiver FSMs in Figure 3.9 each have just +one state. The arrows in the FSM description indicate the transition of +the protocol from one state to another. (Since each FSM in Figure 3.9 +has just one state, a transition is necessarily from the one state back +to itself; we'll see more complicated state diagrams shortly.) The event +causing + + the transition is shown above the horizontal line labeling the +transition, and the actions taken when the event occurs are shown below +the horizontal line. When no action is taken on an event, or no event +occurs and an action is taken, we'll use the symbol Λ below or above the +horizontal, respectively, to explicitly denote the lack of an action or +event. The initial state of the FSM is indicated by the dashed arrow. +Although the FSMs in Figure 3.9 have but one state, the FSMs we will see +shortly have multiple states, so it will be important to identify the +initial state of each FSM. The sending side of rdt simply accepts data +from the upper layer via the rdt_send(data) event, creates a packet +containing the data (via the action make_pkt(data) ) and sends the +packet into the channel. In practice, the rdt_send(data) event would +result from a procedure call (for example, to rdt_send() ) by the +upper-layer application. + +Figure 3.9 rdt1.0 -- A protocol for a completely reliable channel + +On the receiving side, rdt receives a packet from the underlying channel +via the rdt_rcv(packet) event, removes the data from the packet (via the +action extract (packet, data) ) and passes the data up to the upper +layer (via the action deliver_data(data) ). In practice, the +rdt_rcv(packet) event would result from a procedure call (for example, +to rdt_rcv() ) from the lower-layer protocol. In this simple protocol, +there is no difference between a unit of data and a packet. Also, all +packet flow is from the sender to receiver; with a perfectly reliable +channel there is no need for the receiver side to provide any feedback +to the sender since nothing can go wrong! Note that we have also assumed +that + + the receiver is able to receive data as fast as the sender happens to +send data. Thus, there is no need for the receiver to ask the sender to +slow down! Reliable Data Transfer over a Channel with Bit Errors: rdt2.0 +A more realistic model of the underlying channel is one in which bits in +a packet may be corrupted. Such bit errors typically occur in the +physical components of a network as a packet is transmitted, propagates, +or is buffered. We'll continue to assume for the moment that all +transmitted packets are received (although their bits may be corrupted) +in the order in which they were sent. Before developing a protocol for +reliably communicating over such a channel, first consider how people +might deal with such a situation. Consider how you yourself might +dictate a long message over the phone. In a typical scenario, the +message taker might say "OK" after each sentence has been heard, +understood, and recorded. If the message taker hears a garbled sentence, +you're asked to repeat the garbled sentence. This message-dictation +protocol uses both positive acknowledgments ("OK") and negative +acknowledgments ("Please repeat that."). These control messages allow +the receiver to let the sender know what has been received correctly, +and what has been received in error and thus requires repeating. In a +computer network setting, reliable data transfer protocols based on such +retransmission are known as ARQ (Automatic Repeat reQuest) protocols. +Fundamentally, three additional protocol capabilities are required in +ARQ protocols to handle the presence of bit errors: Error detection. +First, a mechanism is needed to allow the receiver to detect when bit +errors have occurred. Recall from the previous section that UDP uses the +Internet checksum field for exactly this purpose. In Chapter 6 we'll +examine error-detection and -correction techniques in greater detail; +these techniques allow the receiver to detect and possibly correct +packet bit errors. For now, we need only know that these techniques +require that extra bits (beyond the bits of original data to be +transferred) be sent from the sender to the receiver; these bits will be +gathered into the packet checksum field of the rdt2.0 data packet. +Receiver feedback. Since the sender and receiver are typically executing +on different end systems, possibly separated by thousands of miles, the +only way for the sender to learn of the receiver's view of the world (in +this case, whether or not a packet was received correctly) is for the +receiver to provide explicit feedback to the sender. The positive (ACK) +and negative (NAK) acknowledgment replies in the message-dictation +scenario are examples of such feedback. Our rdt2.0 protocol will +similarly send ACK and NAK packets back from the receiver to the sender. +In principle, these packets need only be one bit long; for example, a 0 +value could indicate a NAK and a value of 1 could indicate an ACK. +Retransmission. A packet that is received in error at the receiver will +be retransmitted by the sender. + + Figure 3.10 shows the FSM representation of rdt2.0 , a data transfer +protocol employing error detection, positive acknowledgments, and +negative acknowledgments. The send side of rdt2.0 has two states. In the +leftmost state, the send-side protocol is waiting for data to be passed +down from the upper layer. When the rdt_send(data) event occurs, the +sender will create a packet ( sndpkt ) containing the data to be sent, +along with a packet checksum (for example, as discussed in Section 3.3.2 +for the case of a UDP segment), and then send the packet via the +udt_send(sndpkt) operation. In the rightmost state, the sender protocol +is waiting for an ACK or a NAK packet from the receiver. If an ACK +packet is received + +Figure 3.10 rdt2.0 -- A protocol for a channel with bit errors + +(the notation rdt_rcv(rcvpkt) && isACK (rcvpkt) in Figure 3.10 +corresponds to this event), the sender knows that the most recently +transmitted packet has been received correctly and thus the protocol +returns to the state of waiting for data from the upper layer. If a NAK +is received, the protocol retransmits the last packet and waits for an +ACK or NAK to be returned by the receiver in response to + + the retransmitted data packet. It is important to note that when the +sender is in the wait-for-ACK-or-NAK state, it cannot get more data from +the upper layer; that is, the rdt_send() event can not occur; that will +happen only after the sender receives an ACK and leaves this state. +Thus, the sender will not send a new piece of data until it is sure that +the receiver has correctly received the current packet. Because of this +behavior, protocols such as rdt2.0 are known as stop-and-wait protocols. +The receiver-side FSM for rdt2.0 still has a single state. On packet +arrival, the receiver replies with either an ACK or a NAK, depending on +whether or not the received packet is corrupted. In Figure 3.10, the +notation rdt_rcv(rcvpkt) && corrupt(rcvpkt) corresponds to the event in +which a packet is received and is found to be in error. Protocol rdt2.0 +may look as if it works but, unfortunately, it has a fatal flaw. In +particular, we haven't accounted for the possibility that the ACK or NAK +packet could be corrupted! (Before proceeding on, you should think about +how this problem may be fixed.) Unfortunately, our slight oversight is +not as innocuous as it may seem. Minimally, we will need to add checksum +bits to ACK/NAK packets in order to detect such errors. The more +difficult question is how the protocol should recover from errors in ACK +or NAK packets. The difficulty here is that if an ACK or NAK is +corrupted, the sender has no way of knowing whether or not the receiver +has correctly received the last piece of transmitted data. Consider +three possibilities for handling corrupted ACKs or NAKs: For the first +possibility, consider what a human might do in the message-dictation +scenario. If the speaker didn't understand the "OK" or "Please repeat +that" reply from the receiver, the speaker would probably ask, "What did +you say?" (thus introducing a new type of sender-to-receiver packet to +our protocol). The receiver would then repeat the reply. But what if the +speaker's "What did you say?" is corrupted? The receiver, having no idea +whether the garbled sentence was part of the dictation or a request to +repeat the last reply, would probably then respond with "What did you +say?" And then, of course, that response might be garbled. Clearly, +we're heading down a difficult path. A second alternative is to add +enough checksum bits to allow the sender not only to detect, but also to +recover from, bit errors. This solves the immediate problem for a +channel that can corrupt packets but not lose them. A third approach is +for the sender simply to resend the current data packet when it receives +a garbled ACK or NAK packet. This approach, however, introduces +duplicate packets into the sender-to-receiver channel. The fundamental +difficulty with duplicate packets is that the receiver doesn't know +whether the ACK or NAK it last sent was received correctly at the +sender. Thus, it cannot know a priori whether an arriving packet +contains new data or is a retransmission! A simple solution to this new +problem (and one adopted in almost all existing data transfer protocols, +including TCP) is to add a new field to the data packet and have the +sender number its data packets by putting a sequence number into this +field. The receiver then need only check this sequence number to + + determine whether or not the received packet is a retransmission. For +this simple case of a stop-andwait protocol, a 1-bit sequence number +will suffice, since it will allow the receiver to know whether the +sender is resending the previously transmitted packet (the sequence +number of the received packet has the same sequence number as the most +recently received packet) or a new packet (the sequence number changes, +moving "forward" in modulo-2 arithmetic). Since we are currently +assuming a channel that does not lose packets, ACK and NAK packets do +not themselves need to indicate the sequence number of the packet they +are acknowledging. The sender knows that a received ACK or NAK packet +(whether garbled or not) was generated in response to its most recently +transmitted data packet. Figures 3.11 and 3.12 show the FSM description +for rdt2.1 , our fixed version of rdt2.0 . The rdt2.1 sender and +receiver FSMs each now have twice as many states as before. This is +because the protocol state must now reflect whether the packet currently +being sent (by the sender) or expected (at the receiver) should have a +sequence number of 0 or 1. Note that the actions in those states where a +0numbered packet is being sent or expected are mirror images of those +where a 1-numbered packet is being sent or expected; the only +differences have to do with the handling of the sequence number. +Protocol rdt2.1 uses both positive and negative acknowledgments from the +receiver to the sender. When an out-of-order packet is received, the +receiver sends a positive acknowledgment for the packet it has received. +When a corrupted packet + +Figure 3.11 rdt2.1 sender + + Figure 3.12 rdt2.1 receiver + +is received, the receiver sends a negative acknowledgment. We can +accomplish the same effect as a NAK if, instead of sending a NAK, we +send an ACK for the last correctly received packet. A sender that +receives two ACKs for the same packet (that is, receives duplicate ACKs) +knows that the receiver did not correctly receive the packet following +the packet that is being ACKed twice. Our NAK-free reliable data +transfer protocol for a channel with bit errors is rdt2.2 , shown in +Figures 3.13 and 3.14. One subtle change between rtdt2.1 and rdt2.2 is +that the receiver must now include the sequence number of the packet +being acknowledged by an ACK message (this is done by including the ACK +, 0 or ACK , 1 argument in make_pkt() in the receiver FSM), and the +sender must now check the sequence number of the packet being +acknowledged by a received ACK message (this is done by including the 0 +or 1 argument in isACK() in the sender FSM). Reliable Data Transfer over +a Lossy Channel with Bit Errors: rdt3.0 Suppose now that in addition to +corrupting bits, the underlying channel can lose packets as well, a +notuncommon event in today's computer networks (including the Internet). +Two additional concerns must now be addressed by the protocol: how to +detect packet loss and what to do when packet loss occurs. The use of +checksumming, sequence numbers, ACK packets, and retransmissions---the +techniques + + Figure 3.13 rdt2.2 sender + +already developed in rdt2.2 ---will allow us to answer the latter +concern. Handling the first concern will require adding a new protocol +mechanism. There are many possible approaches toward dealing with packet +loss (several more of which are explored in the exercises at the end of +the chapter). Here, we'll put the burden of detecting and recovering +from lost packets on the sender. Suppose that the sender transmits a +data packet and either that packet, or the receiver's ACK of that +packet, gets lost. In either case, no reply is forthcoming at the sender +from the receiver. If the sender is willing to wait long enough so that +it is certain that a packet has been lost, it can simply retransmit the +data packet. You should convince yourself that this protocol does indeed +work. But how long must the sender wait to be certain that something has +been lost? The sender must clearly wait at least as long as a round-trip +delay between the sender and receiver (which may include buffering at +intermediate routers) plus whatever amount of time is needed to process +a packet at the receiver. In many networks, this worst-case maximum +delay is very difficult even to estimate, much less know with certainty. +Moreover, the protocol should ideally recover from packet loss as soon +as possible; waiting for a worst-case delay could mean a long wait until +error recovery + + Figure 3.14 rdt2.2 receiver + +is initiated. The approach thus adopted in practice is for the sender to +judiciously choose a time value such that packet loss is likely, +although not guaranteed, to have happened. If an ACK is not received +within this time, the packet is retransmitted. Note that if a packet +experiences a particularly large delay, the sender may retransmit the +packet even though neither the data packet nor its ACK have been lost. +This introduces the possibility of duplicate data packets in the +sender-to-receiver channel. Happily, protocol rdt2.2 already has enough +functionality (that is, sequence numbers) to handle the case of +duplicate packets. From the sender's viewpoint, retransmission is a +panacea. The sender does not know whether a data packet was lost, an ACK +was lost, or if the packet or ACK was simply overly delayed. In all +cases, the action is the same: retransmit. Implementing a time-based +retransmission mechanism requires a countdown timer that can interrupt +the sender after a given amount of time has expired. The sender will +thus need to be able to (1) start the timer each time a packet (either a +first-time packet or a retransmission) is sent, (2) respond to a timer +interrupt (taking appropriate actions), and (3) stop the timer. Figure +3.15 shows the sender FSM for rdt3.0 , a protocol that reliably +transfers data over a channel that can corrupt or lose packets; in the +homework problems, you'll be asked to provide the receiver FSM for +rdt3.0 . Figure 3.16 shows how the protocol operates with no lost or +delayed packets and how it handles lost data packets. In Figure 3.16, +time moves forward from the top of the diagram toward the bottom of the + + Figure 3.15 rdt3.0 sender + +diagram; note that a receive time for a packet is necessarily later than +the send time for a packet as a result of transmission and propagation +delays. In Figures 3.16(b)--(d), the send-side brackets indicate the +times at which a timer is set and later times out. Several of the more +subtle aspects of this protocol are explored in the exercises at the end +of this chapter. Because packet sequence numbers alternate between 0 and +1, protocol rdt3.0 is sometimes known as the alternating-bit protocol. +We have now assembled the key elements of a data transfer protocol. +Checksums, sequence numbers, timers, and positive and negative +acknowledgment packets each play a crucial and necessary role in the +operation of the protocol. We now have a working reliable data transfer +protocol! + +Developing a protocol and FSM representation for a simple +application-layer protocol + + 3.4.2 Pipelined Reliable Data Transfer Protocols Protocol rdt3.0 is a +functionally correct protocol, but it is unlikely that anyone would be +happy with its performance, particularly in today's high-speed networks. +At the heart of rdt3.0 's performance problem is the fact that it is a +stop-and-wait protocol. + +Figure 3.16 Operation of rdt3.0 , the alternating-bit protocol + + Figure 3.17 Stop-and-wait versus pipelined protocol + +To appreciate the performance impact of this stop-and-wait behavior, +consider an idealized case of two hosts, one located on the West Coast +of the United States and the other located on the East Coast, as shown +in Figure 3.17. The speed-of-light round-trip propagation delay between +these two end systems, RTT, is approximately 30 milliseconds. Suppose +that they are connected by a channel with a transmission rate, R, of 1 +Gbps (109 bits per second). With a packet size, L, of 1,000 bytes (8,000 +bits) per packet, including both header fields and data, the time needed +to actually transmit the packet into the 1 Gbps link is dtrans=LR=8000 +bits/packet109 bits/sec=8 microseconds Figure 3.18(a) shows that with +our stop-and-wait protocol, if the sender begins sending the packet at +t=0, then at t=L/R=8 microseconds, the last bit enters the channel at +the sender side. The packet then makes its 15-msec cross-country +journey, with the last bit of the packet emerging at the receiver at +t=RTT/2+L/R= 15.008 msec. Assuming for simplicity that ACK packets are +extremely small (so that we can ignore their transmission time) and that +the receiver can send an ACK as soon as the last bit of a data packet is +received, the ACK emerges back at the sender at t=RTT+L/R=30.008 msec. +At this point, the sender can now transmit the next message. Thus, in +30.008 msec, the sender was sending for only 0.008 msec. If we define +the utilization of the sender (or the channel) as the fraction of time +the sender is actually busy sending bits into the channel, the analysis +in Figure 3.18(a) shows that the stop-andwait protocol has a rather +dismal sender utilization, Usender, of Usender=L/RRTT+L/R +=.00830.008=0.00027 + + Figure 3.18 Stop-and-wait and pipelined sending + +That is, the sender was busy only 2.7 hundredths of one percent of the +time! Viewed another way, the sender was able to send only 1,000 bytes +in 30.008 milliseconds, an effective throughput of only 267 kbps---even +though a 1 Gbps link was available! Imagine the unhappy network manager +who just paid a fortune for a gigabit capacity link but manages to get a +throughput of only 267 kilobits per second! This is a graphic example of +how network protocols can limit the capabilities provided by the +underlying network hardware. Also, we have neglected lower-layer +protocol-processing times at the sender and receiver, as well as the +processing and queuing delays that would occur at any intermediate +routers + + between the sender and receiver. Including these effects would serve +only to further increase the delay and further accentuate the poor +performance. The solution to this particular performance problem is +simple: Rather than operate in a stop-and-wait manner, the sender is +allowed to send multiple packets without waiting for acknowledgments, as +illustrated in Figure 3.17(b). Figure 3.18(b) shows that if the sender +is allowed to transmit three packets before having to wait for +acknowledgments, the utilization of the sender is essentially tripled. +Since the many in-transit sender-to-receiver packets can be visualized +as filling a pipeline, this technique is known as pipelining. Pipelining +has the following consequences for reliable data transfer protocols: The +range of sequence numbers must be increased, since each in-transit +packet (not counting retransmissions) must have a unique sequence number +and there may be multiple, in-transit, unacknowledged packets. The +sender and receiver sides of the protocols may have to buffer more than +one packet. Minimally, the sender will have to buffer packets that have +been transmitted but not yet acknowledged. Buffering of correctly +received packets may also be needed at the receiver, as discussed below. +The range of sequence numbers needed and the buffering requirements will +depend on the manner in which a data transfer protocol responds to lost, +corrupted, and overly delayed packets. Two basic approaches toward +pipelined error recovery can be identified: Go-Back-N and selective +repeat. + +3.4.3 Go-Back-N (GBN) In a Go-Back-N (GBN) protocol, the sender is +allowed to transmit multiple packets (when available) without waiting +for an acknowledgment, but is constrained to have no more than some +maximum allowable number, N, of unacknowledged packets in the pipeline. +We describe the GBN protocol in some detail in this section. But before +reading on, you are encouraged to play with the GBN applet (an awesome +applet!) at the companion Web site. Figure 3.19 shows the sender's view +of the range of sequence numbers in a GBN protocol. If we define base to +be the sequence number of the oldest unacknowledged + +Figure 3.19 Sender's view of sequence numbers in Go-Back-N + + packet and nextseqnum to be the smallest unused sequence number (that +is, the sequence number of the next packet to be sent), then four +intervals in the range of sequence numbers can be identified. Sequence +numbers in the interval \[ 0, base-1 \] correspond to packets that have +already been transmitted and acknowledged. The interval \[base, +nextseqnum-1\] corresponds to packets that have been sent but not yet +acknowledged. Sequence numbers in the interval \[nextseqnum, base+N-1\] +can be used for packets that can be sent immediately, should data arrive +from the upper layer. Finally, sequence numbers greater than or equal to +base+N cannot be used until an unacknowledged packet currently in the +pipeline (specifically, the packet with sequence number base ) has been +acknowledged. As suggested by Figure 3.19, the range of permissible +sequence numbers for transmitted but not yet acknowledged packets can be +viewed as a window of size N over the range of sequence numbers. As the +protocol operates, this window slides forward over the sequence number +space. For this reason, N is often referred to as the window size and +the GBN protocol itself as a sliding-window protocol. You might be +wondering why we would even limit the number of outstanding, +unacknowledged packets to a value of N in the first place. Why not allow +an unlimited number of such packets? We'll see in Section 3.5 that flow +control is one reason to impose a limit on the sender. We'll examine +another reason to do so in Section 3.7, when we study TCP congestion +control. In practice, a packet's sequence number is carried in a +fixed-length field in the packet header. If k is the number of bits in +the packet sequence number field, the range of sequence numbers is thus +\[0,2k−1\]. With a finite range of sequence numbers, all arithmetic +involving sequence numbers must then be done using modulo 2k arithmetic. +(That is, the sequence number space can be thought of as a ring of size +2k, where sequence number 2k−1 is immediately followed by sequence +number 0.) Recall that rdt3.0 had a 1-bit sequence number and a range of +sequence numbers of \[0,1\]. Several of the problems at the end of this +chapter explore the consequences of a finite range of sequence numbers. +We will see in Section 3.5 that TCP has a 32-bit sequence number field, +where TCP sequence numbers count bytes in the byte stream rather than +packets. Figures 3.20 and 3.21 give an extended FSM description of the +sender and receiver sides of an ACKbased, NAK-free, GBN protocol. We +refer to this FSM + + Figure 3.20 Extended FSM description of the GBN sender + +Figure 3.21 Extended FSM description of the GBN receiver + +description as an extended FSM because we have added variables (similar +to programming-language variables) for base and nextseqnum , and added +operations on these variables and conditional actions involving these +variables. Note that the extended FSM specification is now beginning to +look somewhat like a programming-language specification. \[Bochman +1984\] provides an excellent survey of + + additional extensions to FSM techniques as well as other +programming-language-based techniques for specifying protocols. The GBN +sender must respond to three types of events: Invocation from above. +When rdt_send() is called from above, the sender first checks to see if +the window is full, that is, whether there are N outstanding, +unacknowledged packets. If the window is not full, a packet is created +and sent, and variables are appropriately updated. If the window is +full, the sender simply returns the data back to the upper layer, an +implicit indication that the window is full. The upper layer would +presumably then have to try again later. In a real implementation, the +sender would more likely have either buffered (but not immediately sent) +this data, or would have a synchronization mechanism (for example, a +semaphore or a flag) that would allow the upper layer to call rdt_send() +only when the window is not full. Receipt of an ACK. In our GBN +protocol, an acknowledgment for a packet with sequence number n will be +taken to be a cumulative acknowledgment, indicating that all packets +with a sequence number up to and including n have been correctly +received at the receiver. We'll come back to this issue shortly when we +examine the receiver side of GBN. A timeout event. The protocol's name, +"Go-Back-N," is derived from the sender's behavior in the presence of +lost or overly delayed packets. As in the stop-and-wait protocol, a +timer will again be used to recover from lost data or acknowledgment +packets. If a timeout occurs, the sender resends all packets that have +been previously sent but that have not yet been acknowledged. Our sender +in Figure 3.20 uses only a single timer, which can be thought of as a +timer for the oldest transmitted but not yet acknowledged packet. If an +ACK is received but there are still additional transmitted but not yet +acknowledged packets, the timer is restarted. If there are no +outstanding, unacknowledged packets, the timer is stopped. The +receiver's actions in GBN are also simple. If a packet with sequence +number n is received correctly and is in order (that is, the data last +delivered to the upper layer came from a packet with sequence number +n−1), the receiver sends an ACK for packet n and delivers the data +portion of the packet to the upper layer. In all other cases, the +receiver discards the packet and resends an ACK for the most recently +received in-order packet. Note that since packets are delivered one at a +time to the upper layer, if packet k has been received and delivered, +then all packets with a sequence number lower than k have also been +delivered. Thus, the use of cumulative acknowledgments is a natural +choice for GBN. In our GBN protocol, the receiver discards out-of-order +packets. Although it may seem silly and wasteful to discard a correctly +received (but out-of-order) packet, there is some justification for +doing so. Recall that the receiver must deliver data in order to the +upper layer. Suppose now that packet n is expected, but packet n+1 +arrives. Because data must be delivered in order, the receiver could +buffer (save) packet n+1 and then deliver this packet to the upper layer +after it had later received and delivered packet n. However, if packet n +is lost, both it and packet n+1 will eventually be retransmitted as a +result of the + + GBN retransmission rule at the sender. Thus, the receiver can simply +discard packet n+1. The advantage of this approach is the simplicity of +receiver buffering---the receiver need not buffer any outof-order +packets. Thus, while the sender must maintain the upper and lower bounds +of its window and the position of nextseqnum within this window, the +only piece of information the receiver need maintain is the sequence +number of the next in-order packet. This value is held in the variable +expectedseqnum , shown in the receiver FSM in Figure 3.21. Of course, +the disadvantage of throwing away a correctly received packet is that +the subsequent retransmission of that packet might be lost or garbled +and thus even more retransmissions would be required. Figure 3.22 shows +the operation of the GBN protocol for the case of a window size of four +packets. Because of this window size limitation, the sender sends +packets 0 through 3 but then must wait for one or more of these packets +to be acknowledged before proceeding. As each successive ACK (for +example, ACK0 and ACK1 ) is received, the window slides forward and the +sender can transmit one new packet (pkt4 and pkt5, respectively). On the +receiver side, packet 2 is lost and thus packets 3, 4, and 5 are found +to be out of order and are discarded. Before closing our discussion of +GBN, it is worth noting that an implementation of this protocol in a +protocol stack would likely have a structure similar to that of the +extended FSM in Figure 3.20. The implementation would also likely be in +the form of various procedures that implement the actions to be taken in +response to the various events that can occur. In such event-based +programming, the various procedures are called (invoked) either by other +procedures in the protocol stack, or as the result of an interrupt. In +the sender, these events would be (1) a call from the upper-layer entity +to invoke rdt_send() , (2) a timer interrupt, and (3) a call from the +lower layer to invoke rdt_rcv() when a packet arrives. The programming +exercises at the end of this chapter will give you a chance to actually +implement these routines in a simulated, but realistic, network setting. +We note here that the GBN protocol incorporates almost all of the +techniques that we will encounter when we study the reliable data +transfer components of TCP in Section 3.5. These techniques include the +use of sequence numbers, cumulative acknowledgments, checksums, and a +timeout/retransmit operation. + + Figure 3.22 Go-Back-N in operation + +3.4.4 Selective Repeat (SR) The GBN protocol allows the sender to +potentially "fill the pipeline" in Figure 3.17 with packets, thus +avoiding the channel utilization problems we noted with stop-and-wait +protocols. There are, however, scenarios in which GBN itself suffers +from performance problems. In particular, when the window size and +bandwidth-delay product are both large, many packets can be in the +pipeline. A single packet error can thus cause GBN to retransmit a large +number of packets, many unnecessarily. As the probability of channel +errors increases, the pipeline can become filled with these unnecessary +retransmissions. Imagine, in our message-dictation scenario, that if +every time a word was garbled, the surrounding 1,000 words (for example, +a window size of 1,000 words) had to be repeated. The dictation would be + + slowed by all of the reiterated words. As the name suggests, +selective-repeat protocols avoid unnecessary retransmissions by having +the sender retransmit only those packets that it suspects were received +in error (that is, were lost or corrupted) at the receiver. This +individual, as-needed, retransmission will require that the receiver +individually acknowledge correctly received packets. A window size of N +will again be used to limit the number of outstanding, unacknowledged +packets in the pipeline. However, unlike GBN, the sender will have +already received ACKs for some of the packets in the window. Figure 3.23 +shows the SR sender's view of the sequence number space. Figure 3.24 +details the various actions taken by the SR sender. The SR receiver will +acknowledge a correctly received packet whether or not it is in order. +Out-of-order packets are buffered until any missing packets (that is, +packets with lower sequence numbers) are received, at which point a +batch of packets can be delivered in order to the upper layer. Figure +3.25 itemizes the various actions taken by the SR receiver. Figure 3.26 +shows an example of SR operation in the presence of lost packets. Note +that in Figure 3.26, the receiver initially buffers packets 3, 4, and 5, +and delivers them together with packet 2 to the upper layer when packet +2 is finally received. + +Figure 3.23 Selective-repeat (SR) sender and receiver views of +sequence-number space + + Figure 3.24 SR sender events and actions + +Figure 3.25 SR receiver events and actions + +It is important to note that in Step 2 in Figure 3.25, the receiver +reacknowledges (rather than ignores) already received packets with +certain sequence numbers below the current window base. You should +convince yourself that this reacknowledgment is indeed needed. Given the +sender and receiver sequence number spaces in Figure 3.23, for example, +if there is no ACK for packet send_base propagating from the + + Figure 3.26 SR operation + +receiver to the sender, the sender will eventually retransmit packet +send_base , even though it is clear (to us, not the sender!) that the +receiver has already received that packet. If the receiver were not to +acknowledge this packet, the sender's window would never move forward! +This example illustrates an important aspect of SR protocols (and many +other protocols as well). The sender and receiver will not always have +an identical view of what has been received correctly and what has not. +For SR protocols, this means that the sender and receiver windows will +not always coincide. The lack of synchronization between sender and +receiver windows has important consequences when we are faced with the +reality of a finite range of sequence numbers. Consider what could +happen, for example, with a finite range of four packet sequence +numbers, 0, 1, 2, 3, and a window size of three. + + Suppose packets 0 through 2 are transmitted and correctly received and +acknowledged at the receiver. At this point, the receiver's window is +over the fourth, fifth, and sixth packets, which have sequence numbers +3, 0, and 1, respectively. Now consider two scenarios. In the first +scenario, shown in Figure 3.27(a), the ACKs for the first three packets +are lost and the sender retransmits these packets. The receiver thus +next receives a packet with sequence number 0---a copy of the first +packet sent. In the second scenario, shown in Figure 3.27(b), the ACKs +for the first three packets are all delivered correctly. The sender thus +moves its window forward and sends the fourth, fifth, and sixth packets, +with sequence numbers 3, 0, and 1, respectively. The packet with +sequence number 3 is lost, but the packet with sequence number 0 +arrives---a packet containing new data. Now consider the receiver's +viewpoint in Figure 3.27, which has a figurative curtain between the +sender and the receiver, since the receiver cannot "see" the actions +taken by the sender. All the receiver observes is the sequence of +messages it receives from the channel and sends into the channel. As far +as it is concerned, the two scenarios in Figure 3.27 are identical. +There is no way of distinguishing the retransmission of the first packet +from an original transmission of the fifth packet. Clearly, a window +size that is 1 less than the size of the sequence number space won't +work. But how small must the window size be? A problem at the end of the +chapter asks you to show that the window size must be less than or equal +to half the size of the sequence number space for SR protocols. At the +companion Web site, you will find an applet that animates the operation +of the SR protocol. Try performing the same experiments that you did +with the GBN applet. Do the results agree with what you expect? This +completes our discussion of reliable data transfer protocols. We've +covered a lot of ground and introduced numerous mechanisms that together +provide for reliable data transfer. Table 3.1 summarizes these +mechanisms. Now that we have seen all of these mechanisms in operation +and can see the "big picture," we encourage you to review this section +again to see how these mechanisms were incrementally added to cover +increasingly complex (and realistic) models of the channel connecting +the sender and receiver, or to improve the performance of the protocols. +Let's conclude our discussion of reliable data transfer protocols by +considering one remaining assumption in our underlying channel model. +Recall that we have assumed that packets cannot be reordered within the +channel between the sender and receiver. This is generally a reasonable +assumption when the sender and receiver are connected by a single +physical wire. However, when the "channel" connecting the two is a +network, packet reordering can occur. One manifestation of packet +reordering is that old copies of a packet with a sequence or +acknowledgment + + Figure 3.27 SR receiver dilemma with too-large windows: A new packet or +a retransmission? + +Table 3.1 Summary of reliable data transfer mechanisms and their use +Mechanism + +Use, Comments + +Checksum + +Used to detect bit errors in a transmitted packet. + +Timer + +Used to timeout/retransmit a packet, possibly because the packet (or its +ACK) was lost within the channel. Because timeouts can occur when a +packet is delayed but not lost (premature timeout), or when a packet has +been received by the receiver but the receiver-to-sender ACK has been +lost, duplicate copies + + of a packet may be received by a receiver. Sequence + +Used for sequential numbering of packets of data flowing from sender to + +number + +receiver. Gaps in the sequence numbers of received packets allow the +receiver to detect a lost packet. Packets with duplicate sequence +numbers allow the receiver to detect duplicate copies of a packet. + +Acknowledgment + +Used by the receiver to tell the sender that a packet or set of packets +has been received correctly. Acknowledgments will typically carry the +sequence number of the packet or packets being acknowledged. +Acknowledgments may be individual or cumulative, depending on the +protocol. + +Negative + +Used by the receiver to tell the sender that a packet has not been +received + +acknowledgment + +correctly. Negative acknowledgments will typically carry the sequence +number of the packet that was not received correctly. + +Window, + +The sender may be restricted to sending only packets with sequence +numbers + +pipelining + +that fall within a given range. By allowing multiple packets to be +transmitted but not yet acknowledged, sender utilization can be +increased over a stop-and-wait mode of operation. We'll see shortly that +the window size may be set on the basis of the receiver's ability to +receive and buffer messages, or the level of congestion in the network, +or both. + +number of x can appear, even though neither the sender's nor the +receiver's window contains x. With packet reordering, the channel can be +thought of as essentially buffering packets and spontaneously emitting +these packets at any point in the future. Because sequence numbers may +be reused, some care must be taken to guard against such duplicate +packets. The approach taken in practice is to ensure that a sequence +number is not reused until the sender is "sure" that any previously sent +packets with sequence number x are no longer in the network. This is +done by assuming that a packet cannot "live" in the network for longer +than some fixed maximum amount of time. A maximum packet lifetime of +approximately three minutes is assumed in the TCP extensions for +high-speed networks \[RFC 1323\]. \[Sunshine 1978\] describes a method +for using sequence numbers such that reordering problems can be +completely avoided. + + 3.5 Connection-Oriented Transport: TCP Now that we have covered the +underlying principles of reliable data transfer, let's turn to TCP---the +Internet's transport-layer, connection-oriented, reliable transport +protocol. In this section, we'll see that in order to provide reliable +data transfer, TCP relies on many of the underlying principles discussed +in the previous section, including error detection, retransmissions, +cumulative acknowledgments, timers, and header fields for sequence and +acknowledgment numbers. TCP is defined in RFC 793, RFC 1122, RFC 1323, +RFC 2018, and RFC 2581. + +3.5.1 The TCP Connection TCP is said to be connection-oriented because +before one application process can begin to send data to another, the +two processes must first "handshake" with each other---that is, they +must send some preliminary segments to each other to establish the +parameters of the ensuing data transfer. As part of TCP connection +establishment, both sides of the connection will initialize many TCP +state variables (many of which will be discussed in this section and in +Section 3.7) associated with the TCP connection. The TCP "connection" is +not an end-to-end TDM or FDM circuit as in a circuit-switched network. +Instead, the "connection" is a logical one, with common state residing +only in the TCPs in the two communicating end systems. Recall that +because the TCP protocol runs only in the end systems and not in the +intermediate network elements (routers and link-layer switches), the +intermediate network elements do not maintain TCP connection state. In +fact, the intermediate routers are completely oblivious to TCP +connections; they see datagrams, not connections. A TCP connection +provides a full-duplex service: If there is a TCP connection between +Process A on one host and Process B on another host, then +application-layer data can flow from Process A to Process B at the same +time as application-layer data flows from Process B to Process A. A TCP +connection is also always point-to-point, that is, between a single +sender and a single receiver. Socalled "multicasting" (see the online +supplementary materials for this text)---the transfer of data from one +sender to many receivers in a single send operation---is not possible +with TCP. With TCP, two hosts are company and three are a crowd! Let's +now take a look at how a TCP connection is established. Suppose a +process running in one host wants to initiate a connection with another +process in another host. Recall that the process that is + + initiating the connection is called the client process, while the other +process is called the server process. The client application process +first informs the client transport layer that it wants to establish a +connection + +CASE HISTORY Vinton Cerf, Robert Kahn, and TCP/IP In the early 1970s, +packet-switched networks began to proliferate, with the ARPAnet---the +precursor of the Internet---being just one of many networks. Each of +these networks had its own protocol. Two researchers, Vinton Cerf and +Robert Kahn, recognized the importance of interconnecting these networks +and invented a cross-network protocol called TCP/IP, which stands for +Transmission Control Protocol/Internet Protocol. Although Cerf and Kahn +began by seeing the protocol as a single entity, it was later split into +its two parts, TCP and IP, which operated separately. Cerf and Kahn +published a paper on TCP/IP in May 1974 in IEEE Transactions on +Communications Technology \[Cerf 1974\]. The TCP/IP protocol, which is +the bread and butter of today's Internet, was devised before PCs, +workstations, smartphones, and tablets, before the proliferation of +Ethernet, cable, and DSL, WiFi, and other access network technologies, +and before the Web, social media, and streaming video. Cerf and Kahn saw +the need for a networking protocol that, on the one hand, provides broad +support for yet-to-be-defined applications and, on the other hand, +allows arbitrary hosts and link-layer protocols to interoperate. In +2004, Cerf and Kahn received the ACM's Turing Award, considered the +"Nobel Prize of Computing" for "pioneering work on internetworking, +including the design and implementation of the Internet's basic +communications protocols, TCP/IP, and for inspired leadership in +networking." + +to a process in the server. Recall from Section 2.7.2, a Python client +program does this by issuing the command + +clientSocket.connect((serverName, serverPort)) + +where serverName is the name of the server and serverPort identifies the +process on the server. TCP in the client then proceeds to establish a +TCP connection with TCP in the server. At the end of this section we +discuss in some detail the connection-establishment procedure. For now +it suffices to know that the client first sends a special TCP segment; +the server responds with a second special TCP segment; and finally the +client responds again with a third special segment. The first two +segments carry no payload, that is, no application-layer data; the third +of these segments may carry a payload. Because + + three segments are sent between the two hosts, this +connection-establishment procedure is often referred to as a three-way +handshake. Once a TCP connection is established, the two application +processes can send data to each other. Let's consider the sending of +data from the client process to the server process. The client process +passes a stream of data through the socket (the door of the process), as +described in Section 2.7. Once the data passes through the door, the +data is in the hands of TCP running in the client. As shown in Figure +3.28, TCP directs this data to the connection's send buffer, which is +one of the buffers that is set aside during the initial three-way +handshake. From time to time, TCP will grab chunks of data from the send +buffer and pass the data to the network layer. Interestingly, the TCP +specification \[RFC 793\] is very laid back about specifying when TCP +should actually send buffered data, stating that TCP should "send that +data in segments at its own convenience." The maximum amount of data +that can be grabbed and placed in a segment is limited by the maximum +segment size (MSS). The MSS is typically set by first determining the +length of the largest link-layer frame that can be sent by the local +sending host (the socalled maximum transmission unit, MTU), and then +setting the MSS to ensure that a TCP segment (when encapsulated in an IP +datagram) plus the TCP/IP header length (typically 40 bytes) will fit +into a single link-layer frame. Both Ethernet and PPP link-layer +protocols have an MTU of 1,500 bytes. Thus a typical value of MSS is +1460 bytes. Approaches have also been proposed for discovering the path +MTU ---the largest link-layer frame that can be sent on all links from +source to destination \[RFC 1191\]---and setting the MSS based on the +path MTU value. Note that the MSS is the maximum amount of +application-layer data in the segment, not the maximum size of the TCP +segment including headers. (This terminology is confusing, but we have +to live with it, as it is well entrenched.) TCP pairs each chunk of +client data with a TCP header, thereby forming TCP segments. The +segments are passed down to the network layer, where they are separately +encapsulated within network-layer IP datagrams. The IP datagrams are +then sent into the network. When TCP receives a segment at the other +end, the segment's data is placed in the TCP connection's receive +buffer, as shown in Figure 3.28. The application reads the stream of +data from this buffer. Each side of the connection has + +Figure 3.28 TCP send and receive buffers + + its own send buffer and its own receive buffer. (You can see the online +flow-control applet at http://www.awl.com/kurose-ross, which provides an +animation of the send and receive buffers.) We see from this discussion +that a TCP connection consists of buffers, variables, and a socket +connection to a process in one host, and another set of buffers, +variables, and a socket connection to a process in another host. As +mentioned earlier, no buffers or variables are allocated to the +connection in the network elements (routers, switches, and repeaters) +between the hosts. + +3.5.2 TCP Segment Structure Having taken a brief look at the TCP +connection, let's examine the TCP segment structure. The TCP segment +consists of header fields and a data field. The data field contains a +chunk of application data. As mentioned above, the MSS limits the +maximum size of a segment's data field. When TCP sends a large file, +such as an image as part of a Web page, it typically breaks the file +into chunks of size MSS (except for the last chunk, which will often be +less than the MSS). Interactive applications, however, often transmit +data chunks that are smaller than the MSS; for example, with remote +login applications like Telnet, the data field in the TCP segment is +often only one byte. Because the TCP header is typically 20 bytes (12 +bytes more than the UDP header), segments sent by Telnet may be only 21 +bytes in length. Figure 3.29 shows the structure of the TCP segment. As +with UDP, the header includes source and destination port numbers, which +are used for multiplexing/demultiplexing data from/to upper-layer +applications. Also, as with UDP, the header includes a checksum field. A +TCP segment header also contains the following fields: The 32-bit +sequence number field and the 32-bit acknowledgment number field are +used by the TCP sender and receiver in implementing a reliable data +transfer service, as discussed below. The 16-bit receive window field is +used for flow control. We will see shortly that it is used to indicate +the number of bytes that a receiver is willing to accept. The 4-bit +header length field specifies the length of the TCP header in 32-bit +words. The TCP header can be of variable length due to the TCP options +field. (Typically, the options field is empty, so that the length of the +typical TCP header is 20 bytes.) The optional and variable-length +options field is used when a sender and receiver negotiate the maximum +segment size (MSS) or as a window scaling factor for use in high-speed +networks. A timestamping option is also defined. See RFC 854 and RFC +1323 for additional details. The flag field contains 6 bits. The ACK bit +is used to indicate that the value carried in the acknowledgment field +is valid; that is, the segment contains an acknowledgment for a segment +that has been successfully received. The RST, + + Figure 3.29 TCP segment structure + +SYN, and FIN bits are used for connection setup and teardown, as we will +discuss at the end of this section. The CWR and ECE bits are used in +explicit congestion notification, as discussed in Section 3.7.2. Setting +the PSH bit indicates that the receiver should pass the data to the +upper layer immediately. Finally, the URG bit is used to indicate that +there is data in this segment that the sending-side upper-layer entity +has marked as "urgent." The location of the last byte of this urgent +data is indicated by the 16-bit urgent data pointer field. TCP must +inform the receiving-side upperlayer entity when urgent data exists and +pass it a pointer to the end of the urgent data. (In practice, the PSH, +URG, and the urgent data pointer are not used. However, we mention these +fields for completeness.) Our experience as teachers is that our +students sometimes find discussion of packet formats rather dry and +perhaps a bit boring. For a fun and fanciful look at TCP header fields, +particularly if you love Legos™ as we do, see \[Pomeranz 2010\]. +Sequence Numbers and Acknowledgment Numbers Two of the most important +fields in the TCP segment header are the sequence number field and the +acknowledgment number field. These fields are a critical part of TCP's +reliable data transfer service. But before discussing how these fields +are used to provide reliable data transfer, let us first explain what +exactly TCP puts in these fields. + + Figure 3.30 Dividing file data into TCP segments + +TCP views data as an unstructured, but ordered, stream of bytes. TCP's +use of sequence numbers reflects this view in that sequence numbers are +over the stream of transmitted bytes and not over the series of +transmitted segments. The sequence number for a segment is therefore the +byte-stream number of the first byte in the segment. Let's look at an +example. Suppose that a process in Host A wants to send a stream of data +to a process in Host B over a TCP connection. The TCP in Host A will +implicitly number each byte in the data stream. Suppose that the data +stream consists of a file consisting of 500,000 bytes, that the MSS is +1,000 bytes, and that the first byte of the data stream is numbered 0. +As shown in Figure 3.30, TCP constructs 500 segments out of the data +stream. The first segment gets assigned sequence number 0, the second +segment gets assigned sequence number 1,000, the third segment gets +assigned sequence number 2,000, and so on. Each sequence number is +inserted in the sequence number field in the header of the appropriate +TCP segment. Now let's consider acknowledgment numbers. These are a +little trickier than sequence numbers. Recall that TCP is full-duplex, +so that Host A may be receiving data from Host B while it sends data to +Host B (as part of the same TCP connection). Each of the segments that +arrive from Host B has a sequence number for the data flowing from B to +A. The acknowledgment number that Host A puts in its segment is the +sequence number of the next byte Host A is expecting from Host B. It is +good to look at a few examples to understand what is going on here. +Suppose that Host A has received all bytes numbered 0 through 535 from B +and suppose that it is about to send a segment to Host B. Host A is +waiting for byte 536 and all the subsequent bytes in Host B's data +stream. So Host A puts 536 in the acknowledgment number field of the +segment it sends to B. As another example, suppose that Host A has +received one segment from Host B containing bytes 0 through 535 and +another segment containing bytes 900 through 1,000. For some reason Host +A has not yet received bytes 536 through 899. In this example, Host A is +still waiting for byte 536 (and beyond) in order to re-create B's data +stream. Thus, A's next segment to B will contain 536 in the +acknowledgment number field. Because TCP only acknowledges bytes up to +the first missing byte in the stream, TCP is said to provide cumulative +acknowledgments. + + This last example also brings up an important but subtle issue. Host A +received the third segment (bytes 900 through 1,000) before receiving +the second segment (bytes 536 through 899). Thus, the third segment +arrived out of order. The subtle issue is: What does a host do when it +receives out-of-order segments in a TCP connection? Interestingly, the +TCP RFCs do not impose any rules here and leave the decision up to the +programmers implementing a TCP implementation. There are basically two +choices: either (1) the receiver immediately discards out-of-order +segments (which, as we discussed earlier, can simplify receiver design), +or (2) the receiver keeps the out-of-order bytes and waits for the +missing bytes to fill in the gaps. Clearly, the latter choice is more +efficient in terms of network bandwidth, and is the approach taken in +practice. In Figure 3.30, we assumed that the initial sequence number +was zero. In truth, both sides of a TCP connection randomly choose an +initial sequence number. This is done to minimize the possibility that a +segment that is still present in the network from an earlier, +already-terminated connection between two hosts is mistaken for a valid +segment in a later connection between these same two hosts (which also +happen to be using the same port numbers as the old connection) +\[Sunshine 1978\]. Telnet: A Case Study for Sequence and Acknowledgment +Numbers Telnet, defined in RFC 854, is a popular application-layer +protocol used for remote login. It runs over TCP and is designed to work +between any pair of hosts. Unlike the bulk data transfer applications +discussed in Chapter 2, Telnet is an interactive application. We discuss +a Telnet example here, as it nicely illustrates TCP sequence and +acknowledgment numbers. We note that many users now prefer to use the +SSH protocol rather than Telnet, since data sent in a Telnet connection +(including passwords!) are not encrypted, making Telnet vulnerable to +eavesdropping attacks (as discussed in Section 8.7). Suppose Host A +initiates a Telnet session with Host B. Because Host A initiates the +session, it is labeled the client, and Host B is labeled the server. +Each character typed by the user (at the client) will be sent to the +remote host; the remote host will send back a copy of each character, +which will be displayed on the Telnet user's screen. This "echo back" is +used to ensure that characters seen by the Telnet user have already been +received and processed at the remote site. Each character thus traverses +the network twice between the time the user hits the key and the time +the character is displayed on the user's monitor. Now suppose the user +types a single letter, 'C,' and then grabs a coffee. Let's examine the +TCP segments that are sent between the client and server. As shown in +Figure 3.31, we suppose the starting sequence numbers are 42 and 79 for +the client and server, respectively. Recall that the sequence number of +a segment is the sequence number of the first byte in the data field. +Thus, the first segment sent from the client will have sequence number +42; the first segment sent from the server will have sequence number 79. +Recall that the acknowledgment number is the sequence + + Figure 3.31 Sequence and acknowledgment numbers for a simple Telnet +application over TCP + +number of the next byte of data that the host is waiting for. After the +TCP connection is established but before any data is sent, the client is +waiting for byte 79 and the server is waiting for byte 42. As shown in +Figure 3.31, three segments are sent. The first segment is sent from the +client to the server, containing the 1-byte ASCII representation of the +letter 'C' in its data field. This first segment also has 42 in its +sequence number field, as we just described. Also, because the client +has not yet received any data from the server, this first segment will +have 79 in its acknowledgment number field. The second segment is sent +from the server to the client. It serves a dual purpose. First it +provides an acknowledgment of the data the server has received. By +putting 43 in the acknowledgment field, the server is telling the client +that it has successfully received everything up through byte 42 and is +now waiting for bytes 43 onward. The second purpose of this segment is +to echo back the letter 'C.' Thus, the second segment has the ASCII +representation of 'C' in its data field. This second segment has the +sequence number 79, the initial sequence number of the server-to-client +data flow of this TCP connection, as this is the very first byte of data +that the server is sending. Note that the acknowledgment for +client-to-server data is carried in a segment carrying server-to-client +data; this acknowledgment is said to be piggybacked on the +server-to-client data segment. + + The third segment is sent from the client to the server. Its sole +purpose is to acknowledge the data it has received from the server. +(Recall that the second segment contained data---the letter 'C'---from +the server to the client.) This segment has an empty data field (that +is, the acknowledgment is not being piggybacked with any +client-to-server data). The segment has 80 in the acknowledgment number +field because the client has received the stream of bytes up through +byte sequence number 79 and it is now waiting for bytes 80 onward. You +might think it odd that this segment also has a sequence number since +the segment contains no data. But because TCP has a sequence number +field, the segment needs to have some sequence number. + +3.5.3 Round-Trip Time Estimation and Timeout TCP, like our rdt protocol +in Section 3.4, uses a timeout/retransmit mechanism to recover from lost +segments. Although this is conceptually simple, many subtle issues arise +when we implement a timeout/retransmit mechanism in an actual protocol +such as TCP. Perhaps the most obvious question is the length of the +timeout intervals. Clearly, the timeout should be larger than the +connection's round-trip time (RTT), that is, the time from when a +segment is sent until it is acknowledged. Otherwise, unnecessary +retransmissions would be sent. But how much larger? How should the RTT +be estimated in the first place? Should a timer be associated with each +and every unacknowledged segment? So many questions! Our discussion in +this section is based on the TCP work in \[Jacobson 1988\] and the +current IETF recommendations for managing TCP timers \[RFC 6298\]. +Estimating the Round-Trip Time Let's begin our study of TCP timer +management by considering how TCP estimates the round-trip time between +sender and receiver. This is accomplished as follows. The sample RTT, +denoted SampleRTT , for a segment is the amount of time between when the +segment is sent (that is, passed to IP) and when an acknowledgment for +the segment is received. Instead of measuring a SampleRTT for every +transmitted segment, most TCP implementations take only one SampleRTT +measurement at a time. That is, at any point in time, the SampleRTT is +being estimated for only one of the transmitted but currently +unacknowledged segments, leading to a new value of SampleRTT +approximately once every RTT. Also, TCP never computes a SampleRTT for a +segment that has been retransmitted; it only measures SampleRTT for +segments that have been transmitted once \[Karn 1987\]. (A problem at +the end of the chapter asks you to consider why.) Obviously, the +SampleRTT values will fluctuate from segment to segment due to +congestion in the routers and to the varying load on the end systems. +Because of this fluctuation, any given SampleRTT value may be atypical. +In order to estimate a typical RTT, it is therefore natural to take some +sort of average of the SampleRTT values. TCP maintains an average, +called EstimatedRTT , of the + + SampleRTT values. Upon obtaining a new SampleRTT , TCP updates +EstimatedRTT according to the following formula: + +EstimatedRTT=(1−α)⋅EstimatedRTT+α⋅SampleRTT The formula above is written +in the form of a programming-language statement---the new value of +EstimatedRTT is a weighted combination of the previous value of +EstimatedRTT and the new value for SampleRTT. The recommended value of α +is α = 0.125 (that is, 1/8) \[RFC 6298\], in which case the formula +above becomes: + +EstimatedRTT=0.875⋅EstimatedRTT+0.125⋅SampleRTT + +Note that EstimatedRTT is a weighted average of the SampleRTT values. As +discussed in a homework problem at the end of this chapter, this +weighted average puts more weight on recent samples than on old samples. +This is natural, as the more recent samples better reflect the current +congestion in the network. In statistics, such an average is called an +exponential weighted moving average (EWMA). The word "exponential" +appears in EWMA because the weight of a given SampleRTT decays +exponentially fast as the updates proceed. In the homework problems you +will be asked to derive the exponential term in EstimatedRTT . Figure +3.32 shows the SampleRTT values and EstimatedRTT for a value of α = 1/8 +for a TCP connection between gaia.cs.umass.edu (in Amherst, +Massachusetts) to fantasia.eurecom.fr (in the south of France). Clearly, +the variations in the SampleRTT are smoothed out in the computation of +the EstimatedRTT . In addition to having an estimate of the RTT, it is +also valuable to have a measure of the variability of the RTT. \[RFC +6298\] defines the RTT variation, DevRTT , as an estimate of how much +SampleRTT typically deviates from EstimatedRTT : + +DevRTT=(1−β)⋅DevRTT+β⋅\|SampleRTT−EstimatedRTT\| + +Note that DevRTT is an EWMA of the difference between SampleRTT and +EstimatedRTT . If the SampleRTT values have little fluctuation, then +DevRTT will be small; on the other hand, if there is a lot of +fluctuation, DevRTT will be large. The recommended value of β is 0.25. + + Setting and Managing the Retransmission Timeout Interval Given values of +EstimatedRTT and DevRTT , what value should be used for TCP's timeout +interval? Clearly, the interval should be greater than or equal to + +PRINCIPLES IN PRACTICE TCP provides reliable data transfer by using +positive acknowledgments and timers in much the same way that we studied +in Section 3.4. TCP acknowledges data that has been received correctly, +and it then retransmits segments when segments or their corresponding +acknowledgments are thought to be lost or corrupted. Certain versions of +TCP also have an implicit NAK mechanism---with TCP's fast retransmit +mechanism, the receipt of three duplicate ACKs for a given segment +serves as an implicit NAK for the following segment, triggering +retransmission of that segment before timeout. TCP uses sequences of +numbers to allow the receiver to identify lost or duplicate segments. +Just as in the case of our reliable data transfer protocol, rdt3.0 , TCP +cannot itself tell for certain if a segment, or its ACK, is lost, +corrupted, or overly delayed. At the sender, TCP's response will be the +same: retransmit the segment in question. TCP also uses pipelining, +allowing the sender to have multiple transmitted but +yet-to-beacknowledged segments outstanding at any given time. We saw +earlier that pipelining can greatly improve a session's throughput when +the ratio of the segment size to round-trip delay is small. The specific +number of outstanding, unacknowledged segments that a sender can have is +determined by TCP's flow-control and congestion-control mechanisms. TCP +flow control is discussed at the end of this section; TCP congestion +control is discussed in Section 3.7. For the time being, we must simply +be aware that the TCP sender uses pipelining. EstimatedRTT , or +unnecessary retransmissions would be sent. But the timeout interval +should not be too much larger than EstimatedRTT ; otherwise, when a +segment is lost, TCP would not quickly retransmit the segment, leading +to large data transfer delays. It is therefore desirable to set the +timeout equal to the EstimatedRTT plus some margin. The margin should be +large when there is a lot of fluctuation in the SampleRTT values; it +should be small when there is little fluctuation. The value of DevRTT +should thus come into play here. All of these considerations are taken +into account in TCP's method for determining the retransmission timeout +interval: + +TimeoutInterval=EstimatedRTT+4⋅DevRTT + +An initial TimeoutInterval value of 1 second is recommended \[RFC +6298\]. Also, when a timeout occurs, the value of TimeoutInterval is +doubled to avoid a premature timeout occurring for a + + subsequent segment that will soon be acknowledged. However, as soon as a +segment is received and EstimatedRTT is updated, the TimeoutInterval is +again computed using the formula above. + +Figure 3.32 RTT samples and RTT estimates + +3.5.4 Reliable Data Transfer Recall that the Internet's network-layer +service (IP service) is unreliable. IP does not guarantee datagram +delivery, does not guarantee in-order delivery of datagrams, and does +not guarantee the integrity of the data in the datagrams. With IP +service, datagrams can overflow router buffers and never reach their +destination, datagrams can arrive out of order, and bits in the datagram +can get corrupted (flipped from 0 to 1 and vice versa). Because +transport-layer segments are carried across the network by IP datagrams, +transport-layer segments can suffer from these problems as well. TCP +creates a reliable data transfer service on top of IP's unreliable +best-effort service. TCP's reliable data transfer service ensures that +the data stream that a process reads out of its TCP receive buffer is +uncorrupted, without gaps, without duplication, and in sequence; that +is, the byte stream is exactly the same byte stream that was sent by the +end system on the other side of the connection. How TCP provides a +reliable data transfer involves many of the principles that we studied +in Section 3.4. In our earlier development of reliable data transfer +techniques, it was conceptually easiest to assume + + that an individual timer is associated with each transmitted but not yet +acknowledged segment. While this is great in theory, timer management +can require considerable overhead. Thus, the recommended TCP timer +management procedures \[RFC 6298\] use only a single retransmission +timer, even if there are multiple transmitted but not yet acknowledged +segments. The TCP protocol described in this section follows this +single-timer recommendation. We will discuss how TCP provides reliable +data transfer in two incremental steps. We first present a highly +simplified description of a TCP sender that uses only timeouts to +recover from lost segments; we then present a more complete description +that uses duplicate acknowledgments in addition to timeouts. In the +ensuing discussion, we suppose that data is being sent in only one +direction, from Host A to Host B, and that Host A is sending a large +file. Figure 3.33 presents a highly simplified description of a TCP +sender. We see that there are three major events related to data +transmission and retransmission in the TCP sender: data received from +application above; timer timeout; and ACK + +Figure 3.33 Simplified TCP sender + + receipt. Upon the occurrence of the first major event, TCP receives data +from the application, encapsulates the data in a segment, and passes the +segment to IP. Note that each segment includes a sequence number that is +the byte-stream number of the first data byte in the segment, as +described in Section 3.5.2. Also note that if the timer is already not +running for some other segment, TCP starts the timer when the segment is +passed to IP. (It is helpful to think of the timer as being associated +with the oldest unacknowledged segment.) The expiration interval for +this timer is the TimeoutInterval , which is calculated from +EstimatedRTT and DevRTT , as described in Section 3.5.3. The second +major event is the timeout. TCP responds to the timeout event by +retransmitting the segment that caused the timeout. TCP then restarts +the timer. The third major event that must be handled by the TCP sender +is the arrival of an acknowledgment segment (ACK) from the receiver +(more specifically, a segment containing a valid ACK field value). On +the occurrence of this event, TCP compares the ACK value y with its +variable SendBase . The TCP state variable SendBase is the sequence +number of the oldest unacknowledged byte. (Thus SendBase--1 is the +sequence number of the last byte that is known to have been received +correctly and in order at the receiver.) As indicated earlier, TCP uses +cumulative acknowledgments, so that y acknowledges the receipt of all +bytes before byte number y . If y \> SendBase , then the ACK is +acknowledging one or more previously unacknowledged segments. Thus the +sender updates its SendBase variable; it also restarts the timer if +there currently are any not-yet-acknowledged segments. A Few Interesting +Scenarios We have just described a highly simplified version of how TCP +provides reliable data transfer. But even this highly simplified version +has many subtleties. To get a good feeling for how this protocol works, +let's now walk through a few simple scenarios. Figure 3.34 depicts the +first scenario, in which Host A sends one segment to Host B. Suppose +that this segment has sequence number 92 and contains 8 bytes of data. +After sending this segment, Host A waits for a segment from B with +acknowledgment number 100. Although the segment from A is received at B, +the acknowledgment from B to A gets lost. In this case, the timeout +event occurs, and Host A retransmits the same segment. Of course, when +Host B receives the retransmission, it observes from the sequence number +that the segment contains data that has already been received. Thus, TCP +in Host B will discard the bytes in the retransmitted segment. In a +second scenario, shown in Figure 3.35, Host A sends two segments back to +back. The first segment has sequence number 92 and 8 bytes of data, and +the second segment has sequence number 100 and 20 bytes of data. Suppose +that both segments arrive intact at B, and B sends two separate +acknowledgments for each of these segments. The first of these +acknowledgments has acknowledgment number 100; the second has +acknowledgment number 120. Suppose now that neither of the +acknowledgments arrives at Host A before the timeout. When the timeout +event occurs, Host + + Figure 3.34 Retransmission due to a lost acknowledgment + +A resends the first segment with sequence number 92 and restarts the +timer. As long as the ACK for the second segment arrives before the new +timeout, the second segment will not be retransmitted. In a third and +final scenario, suppose Host A sends the two segments, exactly as in the +second example. The acknowledgment of the first segment is lost in the +network, but just before the timeout event, Host A receives an +acknowledgment with acknowledgment number 120. Host A therefore knows +that Host B has received everything up through byte 119; so Host A does +not resend either of the two segments. This scenario is illustrated in +Figure 3.36. Doubling the Timeout Interval We now discuss a few +modifications that most TCP implementations employ. The first concerns +the length of the timeout interval after a timer expiration. In this +modification, whenever the timeout event occurs, TCP retransmits the +not-yet-acknowledged segment with the smallest sequence number, as +described above. But each time TCP retransmits, it sets the next timeout +interval to twice the previous value, + + Figure 3.35 Segment 100 not retransmitted + +rather than deriving it from the last EstimatedRTT and DevRTT (as +described in Section 3.5.3). For example, suppose TimeoutInterval +associated with the oldest not yet acknowledged segment is .75 sec when +the timer first expires. TCP will then retransmit this segment and set +the new expiration time to 1.5 sec. If the timer expires again 1.5 sec +later, TCP will again retransmit this segment, now setting the +expiration time to 3.0 sec. Thus the intervals grow exponentially after +each retransmission. However, whenever the timer is started after either +of the two other events (that is, data received from application above, +and ACK received), the TimeoutInterval is derived from the most recent +values of EstimatedRTT and DevRTT . This modification provides a limited +form of congestion control. (More comprehensive forms of TCP congestion +control will be studied in Section 3.7.) The timer expiration is most +likely caused by congestion in the network, that is, too many packets +arriving at one (or more) router queues in the path between the source +and destination, causing packets to be dropped and/or long queuing +delays. In times of congestion, if the sources continue to retransmit +packets persistently, the congestion + + Figure 3.36 A cumulative acknowledgment avoids retransmission of the +first segment + +may get worse. Instead, TCP acts more politely, with each sender +retransmitting after longer and longer intervals. We will see that a +similar idea is used by Ethernet when we study CSMA/CD in Chapter 6. +Fast Retransmit One of the problems with timeout-triggered +retransmissions is that the timeout period can be relatively long. When +a segment is lost, this long timeout period forces the sender to delay +resending the lost packet, thereby increasing the end-to-end delay. +Fortunately, the sender can often detect packet loss well before the +timeout event occurs by noting so-called duplicate ACKs. A duplicate ACK +is an ACK that reacknowledges a segment for which the sender has already +received an earlier acknowledgment. To understand the sender's response +to a duplicate ACK, we must look at why the receiver sends a duplicate +ACK in the first place. Table 3.2 summarizes the TCP receiver's ACK +generation policy \[RFC 5681\]. When a TCP receiver receives Table 3.2 +TCP ACK Generation Recommendation \[RFC 5681\] Event + +TCP Receiver Action + + Arrival of in-order segment with expected + +Delayed ACK. Wait up to 500 msec for arrival of + +sequence number. All data up to expected + +another in-order segment. If next in-order segment + +sequence number already acknowledged. + +does not arrive in this interval, send an ACK. + +Arrival of in-order segment with expected + +One Immediately send single cumulative ACK, + +sequence number. One other in-order + +ACKing both in-order segments. + +segment waiting for ACK transmission. Arrival of out-of-order segment +with higher- + +Immediately send duplicate ACK, indicating + +than-expected sequence number. Gap + +sequence number of next expected byte (which is + +detected. + +the lower end of the gap). + +Arrival of segment that partially or completely + +Immediately send ACK, provided that segment + +fills in gap in received data. + +starts at the lower end of gap. + +a segment with a sequence number that is larger than the next, expected, +in-order sequence number, it detects a gap in the data stream---that is, +a missing segment. This gap could be the result of lost or reordered +segments within the network. Since TCP does not use negative +acknowledgments, the receiver cannot send an explicit negative +acknowledgment back to the sender. Instead, it simply reacknowledges +(that is, generates a duplicate ACK for) the last in-order byte of data +it has received. (Note that Table 3.2 allows for the case that the +receiver does not discard out-of-order segments.) Because a sender often +sends a large number of segments back to back, if one segment is lost, +there will likely be many back-to-back duplicate ACKs. If the TCP sender +receives three duplicate ACKs for the same data, it takes this as an +indication that the segment following the segment that has been ACKed +three times has been lost. (In the homework problems, we consider the +question of why the sender waits for three duplicate ACKs, rather than +just a single duplicate ACK.) In the case that three duplicate ACKs are +received, the TCP sender performs a fast retransmit \[RFC 5681\], +retransmitting the missing segment before that segment's timer expires. +This is shown in Figure 3.37, where the second segment is lost, then +retransmitted before its timer expires. For TCP with fast retransmit, +the following code snippet replaces the ACK received event in Figure +3.33: + +event: ACK received, with ACK field value of y if (y \> SendBase) { +SendBase=y if (there are currently any not yet acknowledged segments) +start timer + + } + +Figure 3.37 Fast retransmit: retransmitting the missing segment before +the segment's timer expires + +else {/\* a duplicate ACK for already ACKed segment */ increment number +of duplicate ACKs received for y if (number of duplicate ACKS received +for y==3) /* TCP fast retransmit \*/ resend segment with sequence number +y } break; + + We noted earlier that many subtle issues arise when a timeout/retransmit +mechanism is implemented in an actual protocol such as TCP. The +procedures above, which have evolved as a result of more than 20 years +of experience with TCP timers, should convince you that this is indeed +the case! Go-Back-N or Selective Repeat? Let us close our study of TCP's +error-recovery mechanism by considering the following question: Is TCP a +GBN or an SR protocol? Recall that TCP acknowledgments are cumulative +and correctly received but out-of-order segments are not individually +ACKed by the receiver. Consequently, as shown in Figure 3.33 (see also +Figure 3.19), the TCP sender need only maintain the smallest sequence +number of a transmitted but unacknowledged byte ( SendBase ) and the +sequence number of the next byte to be sent ( NextSeqNum ). In this +sense, TCP looks a lot like a GBN-style protocol. But there are some +striking differences between TCP and Go-Back-N. Many TCP implementations +will buffer correctly received but out-of-order segments \[Stevens +1994\]. Consider also what happens when the sender sends a sequence of +segments 1, 2, . . ., N, and all of the segments arrive in order without +error at the receiver. Further suppose that the acknowledgment for +packet n\<N gets lost, but the remaining N−1 acknowledgments arrive at +the sender before their respective timeouts. In this example, GBN would +retransmit not only packet n, but also all of the subsequent packets +n+1,n+2,...,N. TCP, on the other hand, would retransmit at most one +segment, namely, segment n. Moreover, TCP would not even retransmit +segment n if the acknowledgment for segment n+1 arrived before the +timeout for segment n. A proposed modification to TCP, the so-called +selective acknowledgment \[RFC 2018\], allows a TCP receiver to +acknowledge out-of-order segments selectively rather than just +cumulatively acknowledging the last correctly received, in-order +segment. When combined with selective retransmission---skipping the +retransmission of segments that have already been selectively +acknowledged by the receiver---TCP looks a lot like our generic SR +protocol. Thus, TCP's error-recovery mechanism is probably best +categorized as a hybrid of GBN and SR protocols. + +3.5.5 Flow Control Recall that the hosts on each side of a TCP +connection set aside a receive buffer for the connection. When the TCP +connection receives bytes that are correct and in sequence, it places +the data in the receive buffer. The associated application process will +read data from this buffer, but not necessarily at the instant the data +arrives. Indeed, the receiving application may be busy with some other +task and may not even attempt to read the data until long after it has +arrived. If the application is relatively slow at reading the data, the +sender can very easily overflow the connection's receive buffer by +sending too much data too quickly. + + TCP provides a flow-control service to its applications to eliminate the +possibility of the sender overflowing the receiver's buffer. Flow +control is thus a speed-matching service---matching the rate at which +the sender is sending against the rate at which the receiving +application is reading. As noted earlier, a TCP sender can also be +throttled due to congestion within the IP network; this form of sender +control is referred to as congestion control, a topic we will explore in +detail in Sections 3.6 and 3.7. Even though the actions taken by flow +and congestion control are similar (the throttling of the sender), they +are obviously taken for very different reasons. Unfortunately, many +authors use the terms interchangeably, and the savvy reader would be +wise to distinguish between them. Let's now discuss how TCP provides its +flow-control service. In order to see the forest for the trees, we +suppose throughout this section that the TCP implementation is such that +the TCP receiver discards out-of-order segments. TCP provides flow +control by having the sender maintain a variable called the receive +window. Informally, the receive window is used to give the sender an +idea of how much free buffer space is available at the receiver. Because +TCP is full-duplex, the sender at each side of the connection maintains +a distinct receive window. Let's investigate the receive window in the +context of a file transfer. Suppose that Host A is sending a large file +to Host B over a TCP connection. Host B allocates a receive buffer to +this connection; denote its size by RcvBuffer . From time to time, the +application process in Host B reads from the buffer. Define the +following variables: LastByteRead : the number of the last byte in the +data stream read from the buffer by the application process in B +LastByteRcvd : the number of the last byte in the data stream that has +arrived from the network and has been placed in the receive buffer at B +Because TCP is not permitted to overflow the allocated buffer, we must +have + +LastByteRcvd−LastByteRead≤RcvBuffer + +The receive window, denoted rwnd is set to the amount of spare room in +the buffer: + +rwnd=RcvBuffer−\[LastByteRcvd−LastByteRead\] + +Because the spare room changes with time, rwnd is dynamic. The variable +rwnd is illustrated in Figure 3.38. + + How does the connection use the variable rwnd to provide the +flow-control service? Host B tells Host A how much spare room it has in +the connection buffer by placing its current value of rwnd in the +receive window field of every segment it sends to A. Initially, Host B +sets rwnd = RcvBuffer . Note that to pull this off, Host B must keep +track of several connection-specific variables. Host A in turn keeps +track of two variables, LastByteSent and LastByteAcked , which have +obvious meanings. Note that the difference between these two variables, +LastByteSent -- LastByteAcked , is the amount of unacknowledged data +that A has sent into the connection. By keeping the amount of +unacknowledged data less than the value of rwnd , Host A is assured that +it is not + +Figure 3.38 The receive window (rwnd) and the receive buffer (RcvBuffer) + +overflowing the receive buffer at Host B. Thus, Host A makes sure +throughout the connection's life that + +LastByteSent−LastByteAcked≤rwnd + +There is one minor technical problem with this scheme. To see this, +suppose Host B's receive buffer becomes full so that rwnd = 0. After +advertising rwnd = 0 to Host A, also suppose that B has nothing to send +to A. Now consider what happens. As the application process at B empties +the buffer, TCP does not send new segments with new rwnd values to Host +A; indeed, TCP sends a segment to Host A only if it has data to send or +if it has an acknowledgment to send. Therefore, Host A is never informed +that some space has opened up in Host B's receive buffer---Host A is +blocked and can transmit no more data! To solve this problem, the TCP +specification requires Host A to continue to send segments with one data +byte when B's receive window is zero. These segments will be +acknowledged by the receiver. Eventually the buffer will begin to empty +and the acknowledgments will contain a nonzero rwnd value. + + The online site at http://www.awl.com/kurose-ross for this book provides +an interactive Java applet that illustrates the operation of the TCP +receive window. Having described TCP's flow-control service, we briefly +mention here that UDP does not provide flow control and consequently, +segments may be lost at the receiver due to buffer overflow. For +example, consider sending a series of UDP segments from a process on +Host A to a process on Host B. For a typical UDP implementation, UDP +will append the segments in a finite-sized buffer that "precedes" the +corresponding socket (that is, the door to the process). The process +reads one entire segment at a time from the buffer. If the process does +not read the segments fast enough from the buffer, the buffer will +overflow and segments will get dropped. + +3.5.6 TCP Connection Management In this subsection we take a closer look +at how a TCP connection is established and torn down. Although this +topic may not seem particularly thrilling, it is important because TCP +connection establishment can significantly add to perceived delays (for +example, when surfing the Web). Furthermore, many of the most common +network attacks---including the incredibly popular SYN flood +attack---exploit vulnerabilities in TCP connection management. Let's +first take a look at how a TCP connection is established. Suppose a +process running in one host (client) wants to initiate a connection with +another process in another host (server). The client application process +first informs the client TCP that it wants to establish a connection to +a process in the server. The TCP in the client then proceeds to +establish a TCP connection with the TCP in the server in the following +manner: Step 1. The client-side TCP first sends a special TCP segment to +the server-side TCP. This special segment contains no application-layer +data. But one of the flag bits in the segment's header (see Figure +3.29), the SYN bit, is set to 1. For this reason, this special segment +is referred to as a SYN segment. In addition, the client randomly +chooses an initial sequence number ( client_isn ) and puts this number +in the sequence number field of the initial TCP SYN segment. This +segment is encapsulated within an IP datagram and sent to the server. +There has been considerable interest in properly randomizing the choice +of the client_isn in order to avoid certain security attacks \[CERT +2001--09\]. Step 2. Once the IP datagram containing the TCP SYN segment +arrives at the server host (assuming it does arrive!), the server +extracts the TCP SYN segment from the datagram, allocates the TCP +buffers and variables to the connection, and sends a connection-granted +segment to the client TCP. (We'll see in Chapter 8 that the allocation +of these buffers and variables before completing the third step of the +three-way handshake makes TCP vulnerable to a denial-of-service attack +known as SYN flooding.) This connection-granted segment also contains no +application-layer data. However, it does contain three important pieces +of information in the segment header. First, the SYN bit is set to 1. +Second, the acknowledgment field of the TCP segment header is set to + + client_isn+1 . Finally, the server chooses its own initial sequence +number ( server_isn ) and puts this value in the sequence number field +of the TCP segment header. This connection-granted segment is saying, in +effect, "I received your SYN packet to start a connection with your +initial sequence number, client_isn . I agree to establish this +connection. My own initial sequence number is server_isn ." The +connection-granted segment is referred to as a SYNACK segment. Step 3. +Upon receiving the SYNACK segment, the client also allocates buffers and +variables to the connection. The client host then sends the server yet +another segment; this last segment acknowledges the server's +connection-granted segment (the client does so by putting the value +server_isn+1 in the acknowledgment field of the TCP segment header). The +SYN bit is set to zero, since the connection is established. This third +stage of the three-way handshake may carry client-to-server data in the +segment payload. Once these three steps have been completed, the client +and server hosts can send segments containing data to each other. In +each of these future segments, the SYN bit will be set to zero. Note +that in order to establish the connection, three packets are sent +between the two hosts, as illustrated in Figure 3.39. For this reason, +this connection-establishment procedure is often referred to as a +threeway handshake. Several aspects of the TCP three-way handshake are +explored in the homework problems (Why are initial sequence numbers +needed? Why is a three-way handshake, as opposed to a two-way handshake, +needed?). It's interesting to note that a rock climber and a belayer +(who is stationed below the rock climber and whose job it is to handle +the climber's safety rope) use a threeway-handshake communication +protocol that is identical to TCP's to ensure that both sides are ready +before the climber begins ascent. All good things must come to an end, +and the same is true with a TCP connection. Either of the two processes +participating in a TCP connection can end the connection. When a +connection ends, the "resources" (that is, the buffers and variables) + + Figure 3.39 TCP three-way handshake: segment exchange + + Figure 3.40 Closing a TCP connection + +in the hosts are deallocated. As an example, suppose the client decides +to close the connection, as shown in Figure 3.40. The client application +process issues a close command. This causes the client TCP to send a +special TCP segment to the server process. This special segment has a +flag bit in the segment's header, the FIN bit (see Figure 3.29), set +to 1. When the server receives this segment, it sends the client an +acknowledgment segment in return. The server then sends its own shutdown +segment, which has the FIN bit set to 1. Finally, the client +acknowledges the server's shutdown segment. At this point, all the +resources in the two hosts are now deallocated. During the life of a TCP +connection, the TCP protocol running in each host makes transitions +through various TCP states. Figure 3.41 illustrates a typical sequence +of TCP states that are visited by the client TCP. The client TCP begins +in the CLOSED state. The application on the client side initiates a new +TCP connection (by creating a Socket object in our Java examples as in +the Python examples from Chapter 2). This causes TCP in the client to +send a SYN segment to TCP in the server. After having sent the SYN +segment, the client TCP enters the SYN_SENT state. While in the SYN_SENT +state, the client TCP waits for a segment from the server TCP that +includes an acknowledgment for the client's previous segment and + +Figure 3.41 A typical sequence of TCP states visited by a client TCP + + has the SYN bit set to 1. Having received such a segment, the client TCP +enters the ESTABLISHED state. While in the ESTABLISHED state, the TCP +client can send and receive TCP segments containing payload (that is, +application-generated) data. Suppose that the client application decides +it wants to close the connection. (Note that the server could also +choose to close the connection.) This causes the client TCP to send a +TCP segment with the FIN bit set to 1 and to enter the FIN_WAIT_1 state. +While in the FIN_WAIT_1 state, the client TCP waits for a TCP segment +from the server with an acknowledgment. When it receives this segment, +the client TCP enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 +state, the client waits for another segment from the server with the FIN +bit set to 1; after receiving this segment, the client TCP acknowledges +the server's segment and enters the TIME_WAIT state. The TIME_WAIT state +lets the TCP client resend the final acknowledgment in case the ACK is +lost. The time spent in the TIME_WAIT state is implementation-dependent, +but typical values are 30 seconds, 1 minute, and 2 minutes. After the +wait, the connection formally closes and all resources on the client +side (including port numbers) are released. Figure 3.42 illustrates the +series of states typically visited by the server-side TCP, assuming the +client begins connection teardown. The transitions are self-explanatory. +In these two state-transition diagrams, we have only shown how a TCP +connection is normally established and shut down. We have not described +what happens in certain pathological scenarios, for example, when both +sides of a connection want to initiate or shut down at the same time. If +you are interested in learning about + +Figure 3.42 A typical sequence of TCP states visited by a server-side +TCP + + this and other advanced issues concerning TCP, you are encouraged to see +Stevens' comprehensive book \[Stevens 1994\]. Our discussion above has +assumed that both the client and server are prepared to communicate, +i.e., that the server is listening on the port to which the client sends +its SYN segment. Let's consider what happens when a host receives a TCP +segment whose port numbers or source IP address do not match with any of +the ongoing sockets in the host. For example, suppose a host receives a +TCP SYN packet with destination port 80, but the host is not accepting +connections on port 80 (that is, it is not running a Web server on port +80). Then the host will send a special reset segment to the source. This +TCP segment has the RST flag bit (see Section 3.5.2) set to 1. Thus, +when a host sends a reset segment, it is telling the source "I don't +have a socket for that segment. Please do not resend the segment." When +a host receives a UDP packet whose destination port number doesn't match +with an ongoing UDP socket, the host sends a special ICMP datagram, as +discussed in Chapter 5. Now that we have a good understanding of TCP +connection management, let's revisit the nmap portscanning tool and +examine more closely how it works. To explore a specific TCP port, say +port 6789, on a target host, nmap will send a TCP SYN segment with +destination port 6789 to that host. There are three possible outcomes: +The source host receives a TCP SYNACK segment from the target host. +Since this means that an application is running with TCP port 6789 on +the target post, nmap returns "open." FOCUS ON SECURITY The Syn Flood +Attack We've seen in our discussion of TCP's three-way handshake that a +server allocates and initializes connection variables and buffers in +response to a received SYN. The server then sends a SYNACK in response, +and awaits an ACK segment from the client. If the client does not send +an ACK to complete the third step of this 3-way handshake, eventually +(often after a minute or more) the server will terminate the half-open +connection and reclaim the allocated resources. This TCP connection +management protocol sets the stage for a classic Denial of Service (DoS) +attack known as the SYN flood attack. In this attack, the attacker(s) +send a large number of TCP SYN segments, without completing the third +handshake step. With this deluge of SYN segments, the server's +connection resources become exhausted as they are allocated (but never +used!) for half-open connections; legitimate clients are then denied +service. Such SYN flooding attacks were among the first documented DoS +attacks \[CERT SYN 1996\]. Fortunately, an effective defense known as +SYN cookies \[RFC 4987\] are now deployed in most major operating +systems. SYN cookies work as follows: When the server receives a SYN +segment, it does not know if the segment is coming + + from a legitimate user or is part of a SYN flood attack. So, instead of +creating a half-open TCP connection for this SYN, the server creates an +initial TCP sequence number that is a complicated function (hash +function) of source and destination IP addresses and port numbers of the +SYN segment, as well as a secret number only known to the server. This +carefully crafted initial sequence number is the so-called "cookie." The +server then sends the client a SYNACK packet with this special initial +sequence number. Importantly, the server does not remember the cookie or +any other state information corresponding to the SYN. A legitimate +client will return an ACK segment. When the server receives this ACK, it +must verify that the ACK corresponds to some SYN sent earlier. But how +is this done if the server maintains no memory about SYN segments? As +you may have guessed, it is done with the cookie. Recall that for a +legitimate ACK, the value in the acknowledgment field is equal to the +initial sequence number in the SYNACK (the cookie value in this case) +plus one (see Figure 3.39). The server can then run the same hash +function using the source and destination IP address and port numbers in +the SYNACK (which are the same as in the original SYN) and the secret +number. If the result of the function plus one is the same as the +acknowledgment (cookie) value in the client's SYNACK, the server +concludes that the ACK corresponds to an earlier SYN segment and is +hence valid. The server then creates a fully open connection along with +a socket. On the other hand, if the client does not return an ACK +segment, then the original SYN has done no harm at the server, since the +server hasn't yet allocated any resources in response to the original +bogus SYN. The source host receives a TCP RST segment from the target +host. This means that the SYN segment reached the target host, but the +target host is not running an application with TCP port 6789. But the +attacker at least knows that the segments destined to the host at port +6789 are not blocked by any firewall on the path between source and +target hosts. (Firewalls are discussed in Chapter 8.) The source +receives nothing. This likely means that the SYN segment was blocked by +an intervening firewall and never reached the target host. Nmap is a +powerful tool that can "case the joint" not only for open TCP ports, but +also for open UDP ports, for firewalls and their configurations, and +even for the versions of applications and operating systems. Most of +this is done by manipulating TCP connection-management segments +\[Skoudis 2006\]. You can download nmap from www.nmap.org. This +completes our introduction to error control and flow control in TCP. In +Section 3.7 we'll return to TCP and look at TCP congestion control in +some depth. Before doing so, however, we first step back and examine +congestion-control issues in a broader context. + + 3.6 Principles of Congestion Control In the previous sections, we +examined both the general principles and specific TCP mechanisms used to +provide for a reliable data transfer service in the face of packet loss. +We mentioned earlier that, in practice, such loss typically results from +the overflowing of router buffers as the network becomes congested. +Packet retransmission thus treats a symptom of network congestion (the +loss of a specific transport-layer segment) but does not treat the cause +of network congestion---too many sources attempting to send data at too +high a rate. To treat the cause of network congestion, mechanisms are +needed to throttle senders in the face of network congestion. In this +section, we consider the problem of congestion control in a general +context, seeking to understand why congestion is a bad thing, how +network congestion is manifested in the performance received by +upper-layer applications, and various approaches that can be taken to +avoid, or react to, network congestion. This more general study of +congestion control is appropriate since, as with reliable data transfer, +it is high on our "top-ten" list of fundamentally important problems in +networking. The following section contains a detailed study of TCP's +congestion-control algorithm. + +3.6.1 The Causes and the Costs of Congestion Let's begin our general +study of congestion control by examining three increasingly complex +scenarios in which congestion occurs. In each case, we'll look at why +congestion occurs in the first place and at the cost of congestion (in +terms of resources not fully utilized and poor performance received by +the end systems). We'll not (yet) focus on how to react to, or avoid, +congestion but rather focus on the simpler issue of understanding what +happens as hosts increase their transmission rate and the network +becomes congested. Scenario 1: Two Senders, a Router with Infinite +Buffers We begin by considering perhaps the simplest congestion scenario +possible: Two hosts (A and B) each have a connection that shares a +single hop between source and destination, as shown in Figure 3.43. +Let's assume that the application in Host A is sending data into the +connection (for example, passing data to the transport-level protocol +via a socket) at an average rate of λin bytes/sec. These data are +original in the sense that each unit of data is sent into the socket +only once. The underlying transportlevel protocol is a simple one. Data +is encapsulated and sent; no error recovery (for example, + + retransmission), flow control, or congestion control is performed. +Ignoring the additional overhead due to adding transport- and +lower-layer header information, the rate at which Host A offers traffic +to the router in this first scenario is thus λin bytes/sec. Host B +operates in a similar manner, and we assume for simplicity that it too +is sending at a rate of λin bytes/sec. Packets from Hosts A and B pass +through a router and over a shared outgoing link of capacity R. The +router has buffers that allow it to store incoming packets when the +packet-arrival rate exceeds the outgoing link's capacity. In this first +scenario, we assume that the router has an infinite amount of buffer +space. Figure 3.44 plots the performance of Host A's connection under +this first scenario. The left graph plots the per-connection throughput +(number of bytes per + +Figure 3.43 Congestion scenario 1: Two connections sharing a single hop +with infinite buffers + +Figure 3.44 Congestion scenario 1: Throughput and delay as a function of +host sending rate + + second at the receiver) as a function of the connection-sending rate. +For a sending rate between 0 and R/2, the throughput at the receiver +equals the sender's sending rate---everything sent by the sender is +received at the receiver with a finite delay. When the sending rate is +above R/2, however, the throughput is only R/2. This upper limit on +throughput is a consequence of the sharing of link capacity between two +connections. The link simply cannot deliver packets to a receiver at a +steady-state rate that exceeds R/2. No matter how high Hosts A and B set +their sending rates, they will each never see a throughput higher than +R/2. Achieving a per-connection throughput of R/2 might actually appear +to be a good thing, because the link is fully utilized in delivering +packets to their destinations. The right-hand graph in Figure 3.44, +however, shows the consequence of operating near link capacity. As the +sending rate approaches R/2 (from the left), the average delay becomes +larger and larger. When the sending rate exceeds R/2, the average number +of queued packets in the router is unbounded, and the average delay +between source and destination becomes infinite (assuming that the +connections operate at these sending rates for an infinite period of +time and there is an infinite amount of buffering available). Thus, +while operating at an aggregate throughput of near R may be ideal from a +throughput standpoint, it is far from ideal from a delay standpoint. +Even in this (extremely) idealized scenario, we've already found one +cost of a congested network---large queuing delays are experienced as +the packet-arrival rate nears the link capacity. Scenario 2: Two Senders +and a Router with Finite Buffers Let's now slightly modify scenario 1 in +the following two ways (see Figure 3.45). First, the amount of router +buffering is assumed to be finite. A consequence of this real-world +assumption is that packets will be dropped when arriving to an +already-full buffer. Second, we assume that each connection is reliable. +If a packet containing + + Figure 3.45 Scenario 2: Two hosts (with retransmissions) and a router +with finite buffers + +a transport-level segment is dropped at the router, the sender will +eventually retransmit it. Because packets can be retransmitted, we must +now be more careful with our use of the term sending rate. Specifically, +let us again denote the rate at which the application sends original +data into the socket by λin bytes/sec. The rate at which the transport +layer sends segments (containing original data and retransmitted data) +into the network will be denoted λ′in bytes/sec. λ′in is sometimes +referred to as the offered load to the network. The performance realized +under scenario 2 will now depend strongly on how retransmission is +performed. First, consider the unrealistic case that Host A is able to +somehow (magically!) determine whether or not a buffer is free in the +router and thus sends a packet only when a buffer is free. In this case, +no loss would occur, λin would be equal to λ′in, and the throughput of +the connection would be equal to λin. This case is shown in Figure +3.46(a). From a throughput standpoint, performance is ideal--- +everything that is sent is received. Note that the average host sending +rate cannot exceed R/2 under this scenario, since packet loss is assumed +never to occur. Consider next the slightly more realistic case that the +sender retransmits only when a packet is known for certain to be lost. +(Again, this assumption is a bit of a stretch. However, it is possible +that the sending host might set its timeout large enough to be virtually +assured that a packet that has not been acknowledged has been lost.) In +this case, the performance might look something like that shown in +Figure 3.46(b). To appreciate what is happening here, consider the case +that the offered load, λ′in (the rate of original data transmission plus +retransmissions), equals R/2. According to Figure 3.46(b), at this value +of the offered load, the rate at which data + + Figure 3.46 Scenario 2 performance with finite buffers + +are delivered to the receiver application is R/3. Thus, out of the 0.5R +units of data transmitted, 0.333R bytes/sec (on average) are original +data and 0.166R bytes/sec (on average) are retransmitted data. We see +here another cost of a congested network---the sender must perform +retransmissions in order to compensate for dropped (lost) packets due to +buffer overflow. Finally, let us consider the case that the sender may +time out prematurely and retransmit a packet that has been delayed in +the queue but not yet lost. In this case, both the original data packet +and the retransmission may reach the receiver. Of course, the receiver +needs but one copy of this packet and will discard the retransmission. +In this case, the work done by the router in forwarding the +retransmitted copy of the original packet was wasted, as the receiver +will have already received the original copy of this packet. The router +would have better used the link transmission capacity to send a +different packet instead. Here then is yet another cost of a congested +network---unneeded retransmissions by the sender in the face of large +delays may cause a router to use its link bandwidth to forward unneeded +copies of a packet. Figure 3.46 (c) shows the throughput versus offered +load when each packet is assumed to be forwarded (on average) twice by +the router. Since each packet is forwarded twice, the throughput will +have an asymptotic value of R/4 as the offered load approaches R/2. +Scenario 3: Four Senders, Routers with Finite Buffers, and Multihop +Paths In our final congestion scenario, four hosts transmit packets, +each over overlapping two-hop paths, as shown in Figure 3.47. We again +assume that each host uses a timeout/retransmission mechanism to +implement a reliable data transfer service, that all hosts have the same +value of λin, and that all router links have capacity R bytes/sec. + + Figure 3.47 Four senders, routers with finite buffers, and multihop +paths + +Let's consider the connection from Host A to Host C, passing through +routers R1 and R2. The A--C connection shares router R1 with the D--B +connection and shares router R2 with the B--D connection. For extremely +small values of λin, buffer overflows are rare (as in congestion +scenarios 1 and 2), and the throughput approximately equals the offered +load. For slightly larger values of λin, the corresponding throughput is +also larger, since more original data is being transmitted into the +network and delivered to the destination, and overflows are still rare. +Thus, for small values of λin, an increase in λin results in an increase +in λout. Having considered the case of extremely low traffic, let's next +examine the case that λin (and hence λ′in) is extremely large. Consider +router R2. The A--C traffic arriving to router R2 (which arrives at R2 +after being forwarded from R1) can have an arrival rate at R2 that is at +most R, the capacity of the link from R1 to R2, regardless of the value +of λin. If λ′in is extremely large for all connections (including the + + Figure 3.48 Scenario 3 performance with finite buffers and multihop +paths + +B--D connection), then the arrival rate of B--D traffic at R2 can be +much larger than that of the A--C traffic. Because the A--C and B--D +traffic must compete at router R2 for the limited amount of buffer +space, the amount of A--C traffic that successfully gets through R2 +(that is, is not lost due to buffer overflow) becomes smaller and +smaller as the offered load from B--D gets larger and larger. In the +limit, as the offered load approaches infinity, an empty buffer at R2 is +immediately filled by a B--D packet, and the throughput of the A--C +connection at R2 goes to zero. This, in turn, implies that the A--C +end-to-end throughput goes to zero in the limit of heavy traffic. These +considerations give rise to the offered load versus throughput tradeoff +shown in Figure 3.48. The reason for the eventual decrease in throughput +with increasing offered load is evident when one considers the amount of +wasted work done by the network. In the high-traffic scenario outlined +above, whenever a packet is dropped at a second-hop router, the work +done by the first-hop router in forwarding a packet to the second-hop +router ends up being "wasted." The network would have been equally well +off (more accurately, equally bad off) if the first router had simply +discarded that packet and remained idle. More to the point, the +transmission capacity used at the first router to forward the packet to +the second router could have been much more profitably used to transmit +a different packet. (For example, when selecting a packet for +transmission, it might be better for a router to give priority to +packets that have already traversed some number of upstream routers.) So +here we see yet another cost of dropping a packet due to +congestion---when a packet is dropped along a path, the transmission +capacity that was used at each of the upstream links to forward that +packet to the point at which it is dropped ends up having been wasted. + +3.6.2 Approaches to Congestion Control In Section 3.7, we'll examine +TCP's specific approach to congestion control in great detail. Here, we +identify the two broad approaches to congestion control that are taken +in practice and discuss specific + + network architectures and congestion-control protocols embodying these +approaches. At the highest level, we can distinguish among +congestion-control approaches by whether the network layer provides +explicit assistance to the transport layer for congestion-control +purposes: End-to-end congestion control. In an end-to-end approach to +congestion control, the network layer provides no explicit support to +the transport layer for congestion-control purposes. Even the presence +of network congestion must be inferred by the end systems based only on +observed network behavior (for example, packet loss and delay). We'll +see shortly in Section 3.7.1 that TCP takes this end-to-end approach +toward congestion control, since the IP layer is not required to provide +feedback to hosts regarding network congestion. TCP segment loss (as +indicated by a timeout or the receipt of three duplicate +acknowledgments) is taken as an indication of network congestion, and +TCP decreases its window size accordingly. We'll also see a more recent +proposal for TCP congestion control that uses increasing round-trip +segment delay as an indicator of increased network congestion +Network-assisted congestion control. With network-assisted congestion +control, routers provide explicit feedback to the sender and/or receiver +regarding the congestion state of the network. This feedback may be as +simple as a single bit indicating congestion at a link -- an approach +taken in the early IBM SNA \[Schwartz 1982\], DEC DECnet \[Jain 1989; +Ramakrishnan 1990\] architectures, and ATM \[Black 1995\] network +architectures. More sophisticated feedback is also possible. For +example, in ATM Available Bite Rate (ABR) congestion control, a router +informs the sender of the maximum host sending rate it (the router) can +support on an outgoing link. As noted above, the Internet-default +versions of IP and TCP adopt an end-to-end approach towards congestion +control. We'll see, however, in Section 3.7.2 that, more recently, IP +and TCP may also optionally implement network-assisted congestion +control. For network-assisted congestion control, congestion information +is typically fed back from the network to the sender in one of two ways, +as shown in Figure 3.49. Direct feedback may be sent from a network +router to the sender. This form of notification typically takes the form +of a choke packet (essentially saying, "I'm congested!"). The second and +more common form of notification occurs when a router marks/updates a +field in a packet flowing from sender to receiver to indicate +congestion. Upon receipt of a marked packet, the receiver then notifies +the sender of the congestion indication. This latter form of +notification takes a full round-trip time. + + Figure 3.49 Two feedback pathways for network-indicated congestion +information + + 3.7 TCP Congestion Control In this section we return to our study of +TCP. As we learned in Section 3.5, TCP provides a reliable transport +service between two processes running on different hosts. Another key +component of TCP is its congestion-control mechanism. As indicated in +the previous section, TCP must use end-to-end congestion control rather +than network-assisted congestion control, since the IP layer provides no +explicit feedback to the end systems regarding network congestion. The +approach taken by TCP is to have each sender limit the rate at which it +sends traffic into its connection as a function of perceived network +congestion. If a TCP sender perceives that there is little congestion on +the path between itself and the destination, then the TCP sender +increases its send rate; if the sender perceives that there is +congestion along the path, then the sender reduces its send rate. But +this approach raises three questions. First, how does a TCP sender limit +the rate at which it sends traffic into its connection? Second, how does +a TCP sender perceive that there is congestion on the path between +itself and the destination? And third, what algorithm should the sender +use to change its send rate as a function of perceived end-to-end +congestion? Let's first examine how a TCP sender limits the rate at +which it sends traffic into its connection. In Section 3.5 we saw that +each side of a TCP connection consists of a receive buffer, a send +buffer, and several variables ( LastByteRead , rwnd , and so on). The +TCP congestion-control mechanism operating at the sender keeps track of +an additional variable, the congestion window. The congestion window, +denoted cwnd , imposes a constraint on the rate at which a TCP sender +can send traffic into the network. Specifically, the amount of +unacknowledged data at a sender may not exceed the minimum of cwnd and +rwnd , that is: + +LastByteSent−LastByteAcked≤min{cwnd, rwnd} + +In order to focus on congestion control (as opposed to flow control), +let us henceforth assume that the TCP receive buffer is so large that +the receive-window constraint can be ignored; thus, the amount of +unacknowledged data at the sender is solely limited by cwnd . We will +also assume that the sender always has data to send, i.e., that all +segments in the congestion window are sent. The constraint above limits +the amount of unacknowledged data at the sender and therefore indirectly +limits the sender's send rate. To see this, consider a connection for +which loss and packet transmission delays are negligible. Then, roughly, +at the beginning of every RTT, the constraint permits the sender to + + send cwnd bytes of data into the connection; at the end of the RTT the +sender receives acknowledgments for the data. Thus the sender's send +rate is roughly cwnd/RTT bytes/sec. By adjusting the value of cwnd , the +sender can therefore adjust the rate at which it sends data into its +connection. Let's next consider how a TCP sender perceives that there is +congestion on the path between itself and the destination. Let us define +a "loss event" at a TCP sender as the occurrence of either a timeout or +the receipt of three duplicate ACKs from the receiver. (Recall our +discussion in Section 3.5.4 of the timeout event in Figure 3.33 and the +subsequent modification to include fast retransmit on receipt of three +duplicate ACKs.) When there is excessive congestion, then one (or more) +router buffers along the path overflows, causing a datagram (containing +a TCP segment) to be dropped. The dropped datagram, in turn, results in +a loss event at the sender---either a timeout or the receipt of three +duplicate ACKs--- which is taken by the sender to be an indication of +congestion on the sender-to-receiver path. Having considered how +congestion is detected, let's next consider the more optimistic case +when the network is congestion-free, that is, when a loss event doesn't +occur. In this case, acknowledgments for previously unacknowledged +segments will be received at the TCP sender. As we'll see, TCP will take +the arrival of these acknowledgments as an indication that all is +well---that segments being transmitted into the network are being +successfully delivered to the destination---and will use acknowledgments +to increase its congestion window size (and hence its transmission +rate). Note that if acknowledgments arrive at a relatively slow rate +(e.g., if the end-end path has high delay or contains a low-bandwidth +link), then the congestion window will be increased at a relatively slow +rate. On the other hand, if acknowledgments arrive at a high rate, then +the congestion window will be increased more quickly. Because TCP uses +acknowledgments to trigger (or clock) its increase in congestion window +size, TCP is said to be self-clocking. Given the mechanism of adjusting +the value of cwnd to control the sending rate, the critical question +remains: How should a TCP sender determine the rate at which it should +send? If TCP senders collectively send too fast, they can congest the +network, leading to the type of congestion collapse that we saw in +Figure 3.48. Indeed, the version of TCP that we'll study shortly was +developed in response to observed Internet congestion collapse +\[Jacobson 1988\] under earlier versions of TCP. However, if TCP senders +are too cautious and send too slowly, they could under utilize the +bandwidth in the network; that is, the TCP senders could send at a +higher rate without congesting the network. How then do the TCP senders +determine their sending rates such that they don't congest the network +but at the same time make use of all the available bandwidth? Are TCP +senders explicitly coordinated, or is there a distributed approach in +which the TCP senders can set their sending rates based only on local +information? TCP answers these questions using the following guiding +principles: A lost segment implies congestion, and hence, the TCP +sender's rate should be decreased when a segment is lost. Recall from +our discussion in Section 3.5.4, that a timeout event or the + + receipt of four acknowledgments for a given segment (one original ACK +and then three duplicate ACKs) is interpreted as an implicit "loss +event" indication of the segment following the quadruply ACKed segment, +triggering a retransmission of the lost segment. From a +congestion-control standpoint, the question is how the TCP sender should +decrease its congestion window size, and hence its sending rate, in +response to this inferred loss event. An acknowledged segment indicates +that the network is delivering the sender's segments to the receiver, +and hence, the sender's rate can be increased when an ACK arrives for a +previously unacknowledged segment. The arrival of acknowledgments is +taken as an implicit indication that all is well---segments are being +successfully delivered from sender to receiver, and the network is thus +not congested. The congestion window size can thus be increased. +Bandwidth probing. Given ACKs indicating a congestion-free +source-to-destination path and loss events indicating a congested path, +TCP's strategy for adjusting its transmission rate is to increase its +rate in response to arriving ACKs until a loss event occurs, at which +point, the transmission rate is decreased. The TCP sender thus increases +its transmission rate to probe for the rate that at which congestion +onset begins, backs off from that rate, and then to begins probing again +to see if the congestion onset rate has changed. The TCP sender's +behavior is perhaps analogous to the child who requests (and gets) more +and more goodies until finally he/she is finally told "No!", backs off a +bit, but then begins making requests again shortly afterwards. Note that +there is no explicit signaling of congestion state by the network---ACKs +and loss events serve as implicit signals---and that each TCP sender +acts on local information asynchronously from other TCP senders. Given +this overview of TCP congestion control, we're now in a position to +consider the details of the celebrated TCP congestion-control algorithm, +which was first described in \[Jacobson 1988\] and is standardized in +\[RFC 5681\]. The algorithm has three major components: (1) slow start, +(2) congestion avoidance, and (3) fast recovery. Slow start and +congestion avoidance are mandatory components of TCP, differing in how +they increase the size of cwnd in response to received ACKs. We'll see +shortly that slow start increases the size of cwnd more rapidly (despite +its name!) than congestion avoidance. Fast recovery is recommended, but +not required, for TCP senders. Slow Start When a TCP connection begins, +the value of cwnd is typically initialized to a small value of 1 MSS +\[RFC 3390\], resulting in an initial sending rate of roughly MSS/RTT. +For example, if MSS = 500 bytes and RTT = 200 msec, the resulting +initial sending rate is only about 20 kbps. Since the available +bandwidth to the TCP sender may be much larger than MSS/RTT, the TCP +sender would like to find the amount of available bandwidth quickly. +Thus, in the slow-start state, the value of cwnd begins at 1 MSS and +increases by 1 MSS every time a transmitted segment is first +acknowledged. In the example of Figure 3.50, TCP sends the first segment +into the network + + Figure 3.50 TCP slow start + +and waits for an acknowledgment. When this acknowledgment arrives, the +TCP sender increases the congestion window by one MSS and sends out two +maximum-sized segments. These segments are then acknowledged, with the +sender increasing the congestion window by 1 MSS for each of the +acknowledged segments, giving a congestion window of 4 MSS, and so on. +This process results in a doubling of the sending rate every RTT. Thus, +the TCP send rate starts slow but grows exponentially during the slow +start phase. But when should this exponential growth end? Slow start +provides several answers to this question. First, if there is a loss +event (i.e., congestion) indicated by a timeout, the TCP sender sets the +value of cwnd to 1 and begins the slow start process anew. It also sets +the value of a second state variable, ssthresh (shorthand for "slow +start threshold") to cwnd/2 ---half of the value of the congestion +window value when congestion was detected. The second way in which slow +start may end is directly tied to the value of ssthresh . Since ssthresh +is half the value of cwnd when congestion was last detected, it might be +a bit reckless to keep doubling cwnd when it reaches or surpasses the +value of ssthresh . Thus, when the value of cwnd equals ssthresh , slow +start ends and TCP transitions into congestion avoidance mode. As we'll +see, TCP increases cwnd more cautiously when in congestion-avoidance +mode. The final way in which slow start can end is if three duplicate +ACKs are + + detected, in which case TCP performs a fast retransmit (see Section +3.5.4) and enters the fast recovery state, as discussed below. TCP's +behavior in slow start is summarized in the FSM description of TCP +congestion control in Figure 3.51. The slow-start algorithm traces it +roots to \[Jacobson 1988\]; an approach similar to slow start was also +proposed independently in \[Jain 1986\]. Congestion Avoidance On entry +to the congestion-avoidance state, the value of cwnd is approximately +half its value when congestion was last encountered---congestion could +be just around the corner! Thus, rather than doubling the value of cwnd +every RTT, TCP adopts a more conservative approach and increases the +value of cwnd by just a single MSS every RTT \[RFC 5681\]. This can be +accomplished in several ways. A common approach is for the TCP sender to +increase cwnd by MSS bytes (MSS/ cwnd ) whenever a new acknowledgment +arrives. For example, if MSS is 1,460 bytes and cwnd is 14,600 bytes, +then 10 segments are being sent within an RTT. Each arriving ACK +(assuming one ACK per segment) increases the congestion window size by +1/10 MSS, and thus, the value of the congestion window will have +increased by one MSS after ACKs when all 10 segments have been received. +But when should congestion avoidance's linear increase (of 1 MSS per +RTT) end? TCP's congestionavoidance algorithm behaves the same when a +timeout occurs. As in the case of slow start: The value of cwnd is set +to 1 MSS, and the value of ssthresh is updated to half the value of cwnd +when the loss event occurred. Recall, however, that a loss event also +can be triggered by a triple duplicate ACK event. + + Figure 3.51 FSM description of TCP congestion control + +In this case, the network is continuing to deliver segments from sender +to receiver (as indicated by the receipt of duplicate ACKs). So TCP's +behavior to this type of loss event should be less drastic than with a +timeout-indicated loss: TCP halves the value of cwnd (adding in 3 MSS +for good measure to account for the triple duplicate ACKs received) and +records the value of ssthresh to be half the value of cwnd when the +triple duplicate ACKs were received. The fast-recovery state is then +entered. Fast Recovery In fast recovery, the value of cwnd is increased +by 1 MSS for every duplicate ACK received for the missing segment that +caused TCP to enter the fast-recovery state. Eventually, when an ACK +arrives for the missing segment, TCP enters the + + Examining the behavior of TCP + +PRINCIPLES IN PRACTICE TCP SPLITTING: OPTIMIZING THE PERFORMANCE OF +CLOUD SERVICES For cloud services such as search, e-mail, and social +networks, it is desirable to provide a highlevel of responsiveness, +ideally giving users the illusion that the services are running within +their own end systems (including their smartphones). This can be a major +challenge, as users are often located far away from the data centers +responsible for serving the dynamic content associated with the cloud +services. Indeed, if the end system is far from a data center, then the +RTT will be large, potentially leading to poor response time performance +due to TCP slow start. As a case study, consider the delay in receiving +a response for a search query. Typically, the server requires three TCP +windows during slow start to deliver the response \[Pathak 2010\]. Thus +the time from when an end system initiates a TCP connection until the +time when it receives the last packet of the response is roughly 4⋅RTT +(one RTT to set up the TCP connection plus three RTTs for the three +windows of data) plus the processing time in the data center. These RTT +delays can lead to a noticeable delay in returning search results for a +significant fraction of queries. Moreover, there can be significant +packet loss in access networks, leading to TCP retransmissions and even +larger delays. One way to mitigate this problem and improve +user-perceived performance is to (1) deploy frontend servers closer to +the users, and (2) utilize TCP splitting by breaking the TCP connection +at the front-end server. With TCP splitting, the client establishes a +TCP connection to the nearby front-end, and the front-end maintains a +persistent TCP connection to the data center with a very large TCP +congestion window \[Tariq 2008, Pathak 2010, Chen 2011\]. With this +approach, the response time roughly becomes 4⋅RTTFE+RTTBE+ processing +time, where RTTFE is the roundtrip time between client and front-end +server, and RTTBE is the round-trip time between the frontend server and +the data center (back-end server). If the front-end server is close to +client, then this response time approximately becomes RTT plus +processing time, since RTTFE is negligibly small and RTTBE is +approximately RTT. In summary, TCP splitting can reduce the networking +delay roughly from 4⋅RTT to RTT, significantly improving user-perceived +performance, particularly for users who are far from the nearest data +center. TCP splitting also helps reduce TCP retransmission delays caused +by losses in access networks. Google and Akamai have made extensive use +of their CDN servers in access networks (recall our discussion in +Section 2.6) to perform TCP splitting for the cloud services they +support \[Chen 2011\]. + + congestion-avoidance state after deflating cwnd . If a timeout event +occurs, fast recovery transitions to the slow-start state after +performing the same actions as in slow start and congestion avoidance: +The value of cwnd is set to 1 MSS, and the value of ssthresh is set to +half the value of cwnd when the loss event occurred. Fast recovery is a +recommended, but not required, component of TCP \[RFC 5681\]. It is +interesting that an early version of TCP, known as TCP Tahoe, +unconditionally cut its congestion window to 1 MSS and entered the +slow-start phase after either a timeout-indicated or +triple-duplicate-ACK-indicated loss event. The newer version of TCP, TCP +Reno, incorporated fast recovery. Figure 3.52 illustrates the evolution +of TCP's congestion window for both Reno and Tahoe. In this figure, the +threshold is initially equal to 8 MSS. For the first eight transmission +rounds, Tahoe and Reno take identical actions. The congestion window +climbs exponentially fast during slow start and hits the threshold at +the fourth round of transmission. The congestion window then climbs +linearly until a triple duplicate- ACK event occurs, just after +transmission round 8. Note that the congestion window is 12⋅MSS when +this loss event occurs. The value of ssthresh is then set to 0.5⋅ cwnd +=6⋅MSS. Under TCP Reno, the congestion window is set to cwnd = 9⋅MSS and +then grows linearly. Under TCP Tahoe, the congestion window is set to 1 +MSS and grows exponentially until it reaches the value of ssthresh , at +which point it grows linearly. Figure 3.51 presents the complete FSM +description of TCP's congestion-control algorithms---slow start, +congestion avoidance, and fast recovery. The figure also indicates where +transmission of new segments or retransmitted segments can occur. +Although it is important to distinguish between TCP error +control/retransmission and TCP congestion control, it's also important +to appreciate how these two aspects of TCP are inextricably linked. TCP +Congestion Control: Retrospective Having delved into the details of slow +start, congestion avoidance, and fast recovery, it's worthwhile to now +step back and view the forest from the trees. Ignoring the + + Figure 3.52 Evolution of TCP's congestion window (Tahoe and Reno) + +Figure 3.53 Additive-increase, multiplicative-decrease congestion +control + +initial slow-start period when a connection begins and assuming that +losses are indicated by triple duplicate ACKs rather than timeouts, +TCP's congestion control consists of linear (additive) increase in cwnd +of 1 MSS per RTT and then a halving (multiplicative decrease) of cwnd on +a triple duplicate-ACK event. For this reason, TCP congestion control is +often referred to as an additive-increase, multiplicative-decrease +(AIMD) form of congestion control. AIMD congestion control gives rise to +the "saw tooth" behavior shown in Figure 3.53, which also nicely +illustrates our earlier intuition of TCP "probing" for bandwidth---TCP +linearly increases its congestion window size (and hence its +transmission rate) until a triple duplicate-ACK event occurs. It then +decreases its congestion window size by a factor of two but then again +begins increasing it linearly, probing to see if there is additional +available bandwidth. + + As noted previously, many TCP implementations use the Reno algorithm +\[Padhye 2001\]. Many variations of the Reno algorithm have been +proposed \[RFC 3782; RFC 2018\]. The TCP Vegas algorithm \[Brakmo 1995; +Ahn 1995\] attempts to avoid congestion while maintaining good +throughput. The basic idea of Vegas is to (1) detect congestion in the +routers between source and destination before packet loss occurs, and +(2) lower the rate linearly when this imminent packet loss is detected. +Imminent packet loss is predicted by observing the RTT. The longer the +RTT of the packets, the greater the congestion in the routers. As of +late 2015, the Ubuntu Linux implementation of TCP provided slowstart, +congestion avoidance, fast recovery, fast retransmit, and SACK, by +default; alternative congestion control algorithms, such as TCP Vegas +and BIC \[Xu 2004\], are also provided. For a survey of the many flavors +of TCP, see \[Afanasyev 2010\]. TCP's AIMD algorithm was developed based +on a tremendous amount of engineering insight and experimentation with +congestion control in operational networks. Ten years after TCP's +development, theoretical analyses showed that TCP's congestion-control +algorithm serves as a distributed asynchronous-optimization algorithm +that results in several important aspects of user and network +performance being simultaneously optimized \[Kelly 1998\]. A rich theory +of congestion control has since been developed \[Srikant 2004\]. +Macroscopic Description of TCP Throughput Given the saw-toothed behavior +of TCP, it's natural to consider what the average throughput (that is, +the average rate) of a long-lived TCP connection might be. In this +analysis we'll ignore the slow-start phases that occur after timeout +events. (These phases are typically very short, since the sender grows +out of the phase exponentially fast.) During a particular round-trip +interval, the rate at which TCP sends data is a function of the +congestion window and the current RTT. When the window size is w bytes +and the current round-trip time is RTT seconds, then TCP's transmission +rate is roughly w/RTT. TCP then probes for additional bandwidth by +increasing w by 1 MSS each RTT until a loss event occurs. Denote by W +the value of w when a loss event occurs. Assuming that RTT and W are +approximately constant over the duration of the connection, the TCP +transmission rate ranges from W/(2 · RTT) to W/RTT. These assumptions +lead to a highly simplified macroscopic model for the steady-state +behavior of TCP. The network drops a packet from the connection when the +rate increases to W/RTT; the rate is then cut in half and then increases +by MSS/RTT every RTT until it again reaches W/RTT. This process repeats +itself over and over again. Because TCP's throughput (that is, rate) +increases linearly between the two extreme values, we have average +throughput of a connection=0.75⋅WRTT Using this highly idealized model +for the steady-state dynamics of TCP, we can also derive an interesting +expression that relates a connection's loss rate to its available +bandwidth \[Mahdavi 1997\]. + + This derivation is outlined in the homework problems. A more +sophisticated model that has been found empirically to agree with +measured data is \[Padhye 2000\]. TCP Over High-Bandwidth Paths It is +important to realize that TCP congestion control has evolved over the +years and indeed continues to evolve. For a summary of current TCP +variants and discussion of TCP evolution, see \[Floyd 2001, RFC 5681, +Afanasyev 2010\]. What was good for the Internet when the bulk of the +TCP connections carried SMTP, FTP, and Telnet traffic is not necessarily +good for today's HTTP-dominated Internet or for a future Internet with +services that are still undreamed of. The need for continued evolution +of TCP can be illustrated by considering the high-speed TCP connections +that are needed for grid- and cloud-computing applications. For example, +consider a TCP connection with 1,500-byte segments and a 100 ms RTT, and +suppose we want to send data through this connection at 10 Gbps. +Following \[RFC 3649\], we note that using the TCP throughput formula +above, in order to achieve a 10 Gbps throughput, the average congestion +window size would need to be 83,333 segments. That's a lot of segments, +leading us to be rather concerned that one of these 83,333 in-flight +segments might be lost. What would happen in the case of a loss? Or, put +another way, what fraction of the transmitted segments could be lost +that would allow the TCP congestion-control algorithm specified in +Figure 3.51 still to achieve the desired 10 Gbps rate? In the homework +questions for this chapter, you are led through the derivation of a +formula relating the throughput of a TCP connection as a function of the +loss rate (L), the round-trip time (RTT), and the maximum segment size +(MSS): average throughput of a connection=1.22⋅MSSRTTL Using this +formula, we can see that in order to achieve a throughput of 10 Gbps, +today's TCP congestion-control algorithm can only tolerate a segment +loss probability of 2 · 10--10 (or equivalently, one loss event for +every 5,000,000,000 segments)---a very low rate. This observation has +led a number of researchers to investigate new versions of TCP that are +specifically designed for such high-speed environments; see \[Jin 2004; +Kelly 2003; Ha 2008; RFC 7323\] for discussions of these efforts. + +3.7.1 Fairness Consider K TCP connections, each with a different +end-to-end path, but all passing through a bottleneck link with +transmission rate R bps. (By bottleneck link, we mean that for each +connection, all the other links along the connection's path are not +congested and have abundant transmission capacity as compared with the +transmission capacity of the bottleneck link.) Suppose each connection +is transferring a large file and there is no UDP traffic passing through +the bottleneck link. A congestion-control mechanism is said to be fair +if the average transmission rate of each connection is approximately +R/K; + + that is, each connection gets an equal share of the link bandwidth. Is +TCP's AIMD algorithm fair, particularly given that different TCP +connections may start at different times and thus may have different +window sizes at a given point in time? \[Chiu 1989\] provides an elegant +and intuitive explanation of why TCP congestion control converges to +provide an equal share of a bottleneck link's bandwidth among competing +TCP connections. Let's consider the simple case of two TCP connections +sharing a single link with transmission rate R, as shown in Figure 3.54. +Assume that the two connections + +Figure 3.54 Two TCP connections sharing a single bottleneck link + +have the same MSS and RTT (so that if they have the same congestion +window size, then they have the same throughput), that they have a large +amount of data to send, and that no other TCP connections or UDP +datagrams traverse this shared link. Also, ignore the slow-start phase +of TCP and assume the TCP connections are operating in CA mode (AIMD) at +all times. Figure 3.55 plots the throughput realized by the two TCP +connections. If TCP is to share the link bandwidth equally between the +two connections, then the realized throughput should fall along the +45degree arrow (equal bandwidth share) emanating from the origin. +Ideally, the sum of the two throughputs should equal R. (Certainly, each +connection receiving an equal, but zero, share of the link capacity is +not a desirable situation!) So the goal should be to have the achieved +throughputs fall somewhere near the intersection of the equal bandwidth +share line and the full bandwidth utilization line in Figure 3.55. +Suppose that the TCP window sizes are such that at a given point in +time, connections 1 and 2 realize throughputs indicated by point A in +Figure 3.55. Because the amount of link bandwidth jointly consumed by +the two connections is less than R, no loss will occur, and both +connections will increase their window by 1 MSS per RTT as a result of +TCP's congestion-avoidance algorithm. Thus, the joint throughput of the +two connections proceeds along a 45-degree line (equal increase for both + + connections) starting from point A. Eventually, the link bandwidth +jointly consumed by the two connections will be greater than R, and +eventually packet loss will occur. Suppose that connections 1 and 2 +experience packet loss when they realize throughputs indicated by point +B. Connections 1 and 2 then decrease their windows by a factor of two. +The resulting throughputs realized are thus at point C, halfway along a +vector starting at B and ending at the origin. Because the joint +bandwidth use is less than R at point C, the two connections again +increase their throughputs along a 45-degree line starting from C. +Eventually, loss will again occur, for example, at point D, and the two +connections again decrease their window sizes by a factor of two, and so +on. You should convince yourself that the bandwidth realized by the two +connections eventually fluctuates along the equal bandwidth share line. +You should also convince + +Figure 3.55 Throughput realized by TCP connections 1 and 2 + +yourself that the two connections will converge to this behavior +regardless of where they are in the twodimensional space! Although a +number of idealized assumptions lie behind this scenario, it still +provides an intuitive feel for why TCP results in an equal sharing of +bandwidth among connections. In our idealized scenario, we assumed that +only TCP connections traverse the bottleneck link, that the connections +have the same RTT value, and that only a single TCP connection is +associated with a hostdestination pair. In practice, these conditions +are typically not met, and client-server applications can thus obtain +very unequal portions of link bandwidth. In particular, it has been +shown that when multiple connections share a common bottleneck, those +sessions with a smaller RTT are able to grab the available bandwidth at +that link more quickly as it becomes free (that is, open their +congestion windows faster) and thus will enjoy higher throughput than +those connections with larger RTTs \[Lakshman + + 1997\]. Fairness and UDP We have just seen how TCP congestion control +regulates an application's transmission rate via the congestion window +mechanism. Many multimedia applications, such as Internet phone and +video conferencing, often do not run over TCP for this very +reason---they do not want their transmission rate throttled, even if the +network is very congested. Instead, these applications prefer to run +over UDP, which does not have built-in congestion control. When running +over UDP, applications can pump their audio and video into the network +at a constant rate and occasionally lose packets, rather than reduce +their rates to "fair" levels at times of congestion and not lose any +packets. From the perspective of TCP, the multimedia applications +running over UDP are not being fair---they do not cooperate with the +other connections nor adjust their transmission rates appropriately. +Because TCP congestion control will decrease its transmission rate in +the face of increasing congestion (loss), while UDP sources need not, it +is possible for UDP sources to crowd out TCP traffic. An area of +research today is thus the development of congestion-control mechanisms +for the Internet that prevent UDP traffic from bringing the Internet's +throughput to a grinding halt \[Floyd 1999; Floyd 2000; Kohler 2006; RFC +4340\]. Fairness and Parallel TCP Connections But even if we could force +UDP traffic to behave fairly, the fairness problem would still not be +completely solved. This is because there is nothing to stop a TCP-based +application from using multiple parallel connections. For example, Web +browsers often use multiple parallel TCP connections to transfer the +multiple objects within a Web page. (The exact number of multiple +connections is configurable in most browsers.) When an application uses +multiple parallel connections, it gets a larger fraction of the +bandwidth in a congested link. As an example, consider a link of rate R +supporting nine ongoing clientserver applications, with each of the +applications using one TCP connection. If a new application comes along +and also uses one TCP connection, then each application gets +approximately the same transmission rate of R/10. But if this new +application instead uses 11 parallel TCP connections, then the new +application gets an unfair allocation of more than R/2. Because Web +traffic is so pervasive in the Internet, multiple parallel connections +are not uncommon. + +3.7.2 Explicit Congestion Notification (ECN): Network-assisted +Congestion Control Since the initial standardization of slow start and +congestion avoidance in the late 1980's \[RFC 1122\], TCP has +implemented the form of end-end congestion control that we studied in +Section 3.7.1: a TCP sender receives no explicit congestion indications +from the network layer, and instead infers congestion through observed +packet loss. More recently, extensions to both IP and TCP \[RFC 3168\] +have been proposed, implemented, and deployed that allow the network to +explicitly signal congestion to a TCP + + sender and receiver. This form of network-assisted congestion control is +known as Explicit Congestion Notification. As shown in Figure 3.56, the +TCP and IP protocols are involved. At the network layer, two bits (with +four possible values, overall) in the Type of Service field of the IP +datagram header (which we'll discuss in Section 4.3) are used for ECN. +One setting of the ECN bits is used by a router to indicate that it (the + +Figure 3.56 Explicit Congestion Notification: network-assisted +congestion control + +router) is experiencing congestion. This congestion indication is then +carried in the marked IP datagram to the destination host, which then +informs the sending host, as shown in Figure 3.56. RFC 3168 does not +provide a definition of when a router is congested; that decision is a +configuration choice made possible by the router vendor, and decided by +the network operator. However, RFC 3168 does recommend that an ECN +congestion indication be set only in the face of persistent congestion. +A second setting of the ECN bits is used by the sending host to inform +routers that the sender and receiver are ECN-capable, and thus capable +of taking action in response to ECN-indicated network congestion. As +shown in Figure 3.56, when the TCP in the receiving host receives an ECN +congestion indication via a received datagram, the TCP in the receiving +host informs the TCP in the sending host of the congestion indication by +setting the ECE (Explicit Congestion Notification Echo) bit (see Figure +3.29) in a receiver-to-sender TCP ACK segment. The TCP sender, in turn, +reacts to an ACK with an ECE congestion indication by halving the +congestion window, as it would react to a lost segment using fast +retransmit, and sets the CWR (Congestion Window Reduced) bit in the +header of the next transmitted TCP sender-to-receiver segment. + + Other transport-layer protocols besides TCP may also make use of +network-layer-signaled ECN. The Datagram Congestion Control Protocol +(DCCP) \[RFC 4340\] provides a low-overhead, congestioncontrolled +UDP-like unreliable service that utilizes ECN. DCTCP (Data Center TCP) +\[Alizadeh 2010\], a version of TCP designed specifically for data +center networks, also makes use of ECN. + + 3.8 Summary We began this chapter by studying the services that a +transport-layer protocol can provide to network applications. At one +extreme, the transport-layer protocol can be very simple and offer a +no-frills service to applications, providing only a +multiplexing/demultiplexing function for communicating processes. The +Internet's UDP protocol is an example of such a no-frills +transport-layer protocol. At the other extreme, a transport-layer +protocol can provide a variety of guarantees to applications, such as +reliable delivery of data, delay guarantees, and bandwidth guarantees. +Nevertheless, the services that a transport protocol can provide are +often constrained by the service model of the underlying network-layer +protocol. If the network-layer protocol cannot provide delay or +bandwidth guarantees to transport-layer segments, then the +transport-layer protocol cannot provide delay or bandwidth guarantees +for the messages sent between processes. We learned in Section 3.4 that +a transport-layer protocol can provide reliable data transfer even if +the underlying network layer is unreliable. We saw that providing +reliable data transfer has many subtle points, but that the task can be +accomplished by carefully combining acknowledgments, timers, +retransmissions, and sequence numbers. Although we covered reliable data +transfer in this chapter, we should keep in mind that reliable data +transfer can be provided by link-, network-, transport-, or +application-layer protocols. Any of the upper four layers of the +protocol stack can implement acknowledgments, timers, retransmissions, +and sequence numbers and provide reliable data transfer to the layer +above. In fact, over the years, engineers and computer scientists have +independently designed and implemented link-, network-, transport-, and +application-layer protocols that provide reliable data transfer +(although many of these protocols have quietly disappeared). In Section +3.5, we took a close look at TCP, the Internet's connection-oriented and +reliable transportlayer protocol. We learned that TCP is complex, +involving connection management, flow control, and round-trip time +estimation, as well as reliable data transfer. In fact, TCP is actually +more complex than our description---we intentionally did not discuss a +variety of TCP patches, fixes, and improvements that are widely +implemented in various versions of TCP. All of this complexity, however, +is hidden from the network application. If a client on one host wants to +send data reliably to a server on another host, it simply opens a TCP +socket to the server and pumps data into that socket. The client-server +application is blissfully unaware of TCP's complexity. In Section 3.6, +we examined congestion control from a broad perspective, and in Section +3.7, we showed how TCP implements congestion control. We learned that +congestion control is imperative for + + the well-being of the network. Without congestion control, a network can +easily become gridlocked, with little or no data being transported +end-to-end. In Section 3.7 we learned that TCP implements an endto-end +congestion-control mechanism that additively increases its transmission +rate when the TCP connection's path is judged to be congestion-free, and +multiplicatively decreases its transmission rate when loss occurs. This +mechanism also strives to give each TCP connection passing through a +congested link an equal share of the link bandwidth. We also examined in +some depth the impact of TCP connection establishment and slow start on +latency. We observed that in many important scenarios, connection +establishment and slow start significantly contribute to end-to-end +delay. We emphasize once more that while TCP congestion control has +evolved over the years, it remains an area of intensive research and +will likely continue to evolve in the upcoming years. Our discussion of +specific Internet transport protocols in this chapter has focused on UDP +and TCP---the two "work horses" of the Internet transport layer. +However, two decades of experience with these two protocols has +identified circumstances in which neither is ideally suited. Researchers +have thus been busy developing additional transport-layer protocols, +several of which are now IETF proposed standards. The Datagram +Congestion Control Protocol (DCCP) \[RFC 4340\] provides a low-overhead, +messageoriented, UDP-like unreliable service, but with an +application-selected form of congestion control that is compatible with +TCP. If reliable or semi-reliable data transfer is needed by an +application, then this would be performed within the application itself, +perhaps using the mechanisms we have studied in Section 3.4. DCCP is +envisioned for use in applications such as streaming media (see Chapter +9) that can exploit the tradeoff between timeliness and reliability of +data delivery, but that want to be responsive to network congestion. +Google's QUIC (Quick UDP Internet Connections) protocol \[Iyengar +2016\], implemented in Google's Chromium browser, provides reliability +via retransmission as well as error correction, fast-connection setup, +and a rate-based congestion control algorithm that aims to be TCP +friendly---all implemented as an application-level protocol on top of +UDP. In early 2015, Google reported that roughly half of all requests +from Chrome to Google servers are served over QUIC. DCTCP (Data Center +TCP) \[Alizadeh 2010\] is a version of TCP designed specifically for +data center networks, and uses ECN to better support the mix of short- +and long-lived flows that characterize data center workloads. The Stream +Control Transmission Protocol (SCTP) \[RFC 4960, RFC 3286\] is a +reliable, messageoriented protocol that allows several different +application-level "streams" to be multiplexed through a single SCTP +connection (an approach known as "multi-streaming"). From a reliability +standpoint, the different streams within the connection are handled +separately, so that packet loss in one stream does not affect the +delivery of data in other streams. QUIC provides similar multi-stream +semantics. SCTP + + also allows data to be transferred over two outgoing paths when a host +is connected to two or more networks, optional delivery of out-of-order +data, and a number of other features. SCTP's flow- and +congestion-control algorithms are essentially the same as in TCP. The +TCP-Friendly Rate Control (TFRC) protocol \[RFC 5348\] is a +congestion-control protocol rather than a full-fledged transport-layer +protocol. It specifies a congestion-control mechanism that could be used +in another transport protocol such as DCCP (indeed one of the two +application-selectable protocols available in DCCP is TFRC). The goal of +TFRC is to smooth out the "saw tooth" behavior (see Figure 3.53) in TCP +congestion control, while maintaining a long-term sending rate that is +"reasonably" close to that of TCP. With a smoother sending rate than +TCP, TFRC is well-suited for multimedia applications such as IP +telephony or streaming media where such a smooth rate is important. TFRC +is an "equationbased" protocol that uses the measured packet loss rate +as input to an equation \[Padhye 2000\] that estimates what TCP's +throughput would be if a TCP session experiences that loss rate. This +rate is then taken as TFRC's target sending rate. Only the future will +tell whether DCCP, SCTP, QUIC, or TFRC will see widespread deployment. +While these protocols clearly provide enhanced capabilities over TCP and +UDP, TCP and UDP have proven themselves "good enough" over the years. +Whether "better" wins out over "good enough" will depend on a complex +mix of technical, social, and business considerations. In Chapter 1, we +said that a computer network can be partitioned into the "network edge" +and the "network core." The network edge covers everything that happens +in the end systems. Having now covered the application layer and the +transport layer, our discussion of the network edge is complete. It is +time to explore the network core! This journey begins in the next two +chapters, where we'll study the network layer, and continues into +Chapter 6, where we'll study the link layer. + + Homework Problems and Questions + +Chapter 3 Review Questions + +SECTIONS 3.1--3.3 R1. Suppose the network layer provides the following +service. The network layer in the source host accepts a segment of +maximum size 1,200 bytes and a destination host address from the +transport layer. The network layer then guarantees to deliver the +segment to the transport layer at the destination host. Suppose many +network application processes can be running at the destination host. + +a. Design the simplest possible transport-layer protocol that will get + application data to the desired process at the destination host. + Assume the operating system in the destination host has assigned a + 4-byte port number to each running application process. + +b. Modify this protocol so that it provides a "return address" to the + destination process. + +c. In your protocols, does the transport layer "have to do anything" in + the core of the computer network? R2. Consider a planet where + everyone belongs to a family of six, every family lives in its own + house, each house has a unique address, and each person in a given + house has a unique name. Suppose this planet has a mail service that + delivers letters from source house to destination house. The mail + service requires that (1) the letter be in an envelope, and that (2) + the address of the destination house (and nothing more) be clearly + written on the envelope. Suppose each family has a delegate family + member who collects and distributes letters for the other family + members. The letters do not necessarily provide any indication of + the recipients of the letters. + +d. Using the solution to Problem R1 above as inspiration, describe a + protocol that the delegates can use to deliver letters from a + sending family member to a receiving family member. + +e. In your protocol, does the mail service ever have to open the + envelope and examine the letter in order to provide its service? R3. + Consider a TCP connection between Host A and Host B. Suppose that + the TCP segments traveling from Host A to Host B have source port + number x and destination port number y. What are the source and + destination port numbers for the segments traveling from Host B to + Host A? + + R4. Describe why an application developer might choose to run an +application over UDP rather than TCP. R5. Why is it that voice and video +traffic is often sent over TCP rather than UDP in today's Internet? +(Hint: The answer we are looking for has nothing to do with TCP's +congestion-control mechanism.) R6. Is it possible for an application to +enjoy reliable data transfer even when the application runs over UDP? If +so, how? R7. Suppose a process in Host C has a UDP socket with port +number 6789. Suppose both Host A and Host B each send a UDP segment to +Host C with destination port number 6789. Will both of these segments be +directed to the same socket at Host C? If so, how will the process at +Host C know that these two segments originated from two different hosts? +R8. Suppose that a Web server runs in Host C on port 80. Suppose this +Web server uses persistent connections, and is currently receiving +requests from two different Hosts, A and B. Are all of the requests +being sent through the same socket at Host C? If they are being passed +through different sockets, do both of the sockets have port 80? Discuss +and explain. + +SECTION 3.4 R9. In our rdt protocols, why did we need to introduce +sequence numbers? R10. In our rdt protocols, why did we need to +introduce timers? R11. Suppose that the roundtrip delay between sender +and receiver is constant and known to the sender. Would a timer still be +necessary in protocol rdt 3.0 , assuming that packets can be lost? +Explain. R12. Visit the Go-Back-N Java applet at the companion Web site. + +a. Have the source send five packets, and then pause the animation + before any of the five packets reach the destination. Then kill the + first packet and resume the animation. Describe what happens. + +b. Repeat the experiment, but now let the first packet reach the + destination and kill the first acknowledgment. Describe again what + happens. + +c. Finally, try sending six packets. What happens? R13. Repeat R12, but + now with the Selective Repeat Java applet. How are Selective Repeat + and Go-Back-N different? + +SECTION 3.5 R14. True or false? + +a. Host A is sending Host B a large file over a TCP connection. Assume + Host B has no data to send Host A. Host B will not send + acknowledgments to Host A because Host B cannot piggyback the + acknowledgments on data. + + b. The size of the TCP rwnd never changes throughout the duration of the +connection. c. Suppose Host A is sending Host B a large file over a TCP +connection. The number of unacknowledged bytes that A sends cannot +exceed the size of the receive buffer. + +d. Suppose Host A is sending a large file to Host B over a TCP + connection. If the sequence number for a segment of this connection + is m, then the sequence number for the subsequent segment will + necessarily be m+1. + +e. The TCP segment has a field in its header for rwnd . + +f. Suppose that the last SampleRTT in a TCP connection is equal to 1 + sec. The current value of TimeoutInterval for the connection will + necessarily be ≥1 sec. + +g. Suppose Host A sends one segment with sequence number 38 and 4 bytes + of data over a TCP connection to Host B. In this same segment the + acknowledgment number is necessarily 42. R15. Suppose Host A sends + two TCP segments back to back to Host B over a TCP connection. The + first segment has sequence number 90; the second has sequence number + 110. + +h. How much data is in the first segment? + +i. Suppose that the first segment is lost but the second segment + arrives at B. In the acknowledgment that Host B sends to Host A, + what will be the acknowledgment number? R16. Consider the Telnet + example discussed in Section 3.5 . A few seconds after the user + types the letter 'C,' the user types the letter 'R.' After typing + the letter 'R,' how many segments are sent, and what is put in the + sequence number and acknowledgment fields of the segments? + +SECTION 3.7 R17. Suppose two TCP connections are present over some +bottleneck link of rate R bps. Both connections have a huge file to send +(in the same direction over the bottleneck link). The transmissions of +the files start at the same time. What transmission rate would TCP like +to give to each of the connections? R18. True or false? Consider +congestion control in TCP. When the timer expires at the sender, the +value of ssthresh is set to one half of its previous value. R19. In the +discussion of TCP splitting in the sidebar in Section 3.7 , it was +claimed that the response time with TCP splitting is approximately +4⋅RTTFE+RTTBE+processing time. Justify this claim. + +Problems P1. Suppose Client A initiates a Telnet session with Server S. +At about the same time, Client B + + also initiates a Telnet session with Server S. Provide possible source +and destination port numbers for + +a. The segments sent from A to S. + +b. The segments sent from B to S. + +c. The segments sent from S to A. + +d. The segments sent from S to B. + +e. If A and B are different hosts, is it possible that the source port + number in the segments from A to S is the same as that from B to S? + +f. How about if they are the same host? P2. Consider Figure 3.5 . What + are the source and destination port values in the segments flowing + from the server back to the clients' processes? What are the IP + addresses in the network-layer datagrams carrying the + transport-layer segments? P3. UDP and TCP use 1s complement for + their checksums. Suppose you have the following three 8-bit bytes: + 01010011, 01100110, 01110100. What is the 1s complement of the sum + of these 8-bit bytes? (Note that although UDP and TCP use 16-bit + words in computing the checksum, for this problem you are being + asked to consider 8-bit sums.) Show all work. Why is it that UDP + takes the 1s complement of the sum; that is, why not just use the + sum? With the 1s complement scheme, how does the receiver detect + errors? Is it possible that a 1-bit error will go undetected? How + about a 2-bit error? P4. + +g. Suppose you have the following 2 bytes: 01011100 and 01100101. What + is the 1s complement of the sum of these 2 bytes? + +h. Suppose you have the following 2 bytes: 11011010 and 01100101. What + is the 1s complement of the sum of these 2 bytes? + +i. For the bytes in part (a), give an example where one bit is flipped + in each of the 2 bytes and yet the 1s complement doesn't change. P5. + Suppose that the UDP receiver computes the Internet checksum for the + received UDP segment and finds that it matches the value carried in + the checksum field. Can the receiver be absolutely certain that no + bit errors have occurred? Explain. P6. Consider our motivation for + correcting protocol rdt2.1 . Show that the receiver, shown in Figure + 3.57 , when operating with the sender shown in Figure 3.11 , can + lead the sender and receiver to enter into a deadlock state, where + each is waiting for an event that will never occur. P7. In protocol + rdt3.0 , the ACK packets flowing from the receiver to the sender do + not have sequence numbers (although they do have an ACK field that + contains the sequence number of the packet they are acknowledging). + Why is it that our ACK packets do not require sequence numbers? + + Figure 3.57 An incorrect receiver for protocol rdt 2.1 + +P8. Draw the FSM for the receiver side of protocol rdt3.0 . P9. Give a +trace of the operation of protocol rdt3.0 when data packets and +acknowledgment packets are garbled. Your trace should be similar to that +used in Figure 3.16 . P10. Consider a channel that can lose packets but +has a maximum delay that is known. Modify protocol rdt2.1 to include +sender timeout and retransmit. Informally argue why your protocol can +communicate correctly over this channel. P11. Consider the rdt2.2 +receiver in Figure 3.14 , and the creation of a new packet in the +self-transition (i.e., the transition from the state back to itself) in +the Wait-for-0-from-below and the Wait-for-1-from-below states: +sndpkt=make_pkt(ACK, 1, checksum) and sndpkt=make_pkt(ACK, 0, checksum) +. Would the protocol work correctly if this action were removed from the +self-transition in the Wait-for-1-from-below state? Justify your answer. +What if this event were removed from the self-transition in the +Wait-for-0-from-below state? \[Hint: In this latter case, consider what +would happen if the first sender-to-receiver packet were corrupted.\] +P12. The sender side of rdt3.0 simply ignores (that is, takes no action +on) all received packets that are either in error or have the wrong +value in the acknum field of an acknowledgment packet. Suppose that in +such circumstances, rdt3.0 were simply to retransmit the current data +packet. Would the protocol still work? (Hint: Consider what would happen +if there were only bit errors; there are no packet losses but premature +timeouts can occur. Consider how many times the nth packet is sent, in +the limit as n approaches infinity.) + + P13. Consider the rdt 3.0 protocol. Draw a diagram showing that if the +network connection between the sender and receiver can reorder messages +(that is, that two messages propagating in the medium between the sender +and receiver can be reordered), then the alternating-bit protocol will +not work correctly (make sure you clearly identify the sense in which it +will not work correctly). Your diagram should have the sender on the +left and the receiver on the right, with the time axis running down the +page, showing data (D) and acknowledgment (A) message exchange. Make +sure you indicate the sequence number associated with any data or +acknowledgment segment. P14. Consider a reliable data transfer protocol +that uses only negative acknowledgments. Suppose the sender sends data +only infrequently. Would a NAK-only protocol be preferable to a protocol +that uses ACKs? Why? Now suppose the sender has a lot of data to send +and the endto-end connection experiences few losses. In this second +case, would a NAK-only protocol be preferable to a protocol that uses +ACKs? Why? P15. Consider the cross-country example shown in Figure 3.17 +. How big would the window size have to be for the channel utilization +to be greater than 98 percent? Suppose that the size of a packet is +1,500 bytes, including both header fields and data. P16. Suppose an +application uses rdt 3.0 as its transport layer protocol. As the +stop-and-wait protocol has very low channel utilization (shown in the +cross-country example), the designers of this application let the +receiver keep sending back a number (more than two) of alternating ACK 0 +and ACK 1 even if the corresponding data have not arrived at the +receiver. Would this application design increase the channel +utilization? Why? Are there any potential problems with this approach? +Explain. P17. Consider two network entities, A and B, which are +connected by a perfect bi-directional channel (i.e., any message sent +will be received correctly; the channel will not corrupt, lose, or +re-order packets). A and B are to deliver data messages to each other in +an alternating manner: First, A must deliver a message to B, then B must +deliver a message to A, then A must deliver a message to B and so on. If +an entity is in a state where it should not attempt to deliver a message +to the other side, and there is an event like rdt_send(data) call from +above that attempts to pass data down for transmission to the other +side, this call from above can simply be ignored with a call to +rdt_unable_to_send(data) , which informs the higher layer that it is +currently not able to send data. \[Note: This simplifying assumption is +made so you don't have to worry about buffering data.\] Draw a FSM +specification for this protocol (one FSM for A, and one FSM for B!). +Note that you do not have to worry about a reliability mechanism here; +the main point of this question is to create a FSM specification that +reflects the synchronized behavior of the two entities. You should use +the following events and actions that have the same meaning as protocol +rdt1.0 in Figure 3.9 : rdt_send(data), packet = make_pkt(data) , +udt_send(packet), rdt_rcv(packet) , extract (packet, data), +deliver_data(data) . Make sure your protocol reflects the strict +alternation of sending between A and B. Also, make sure to indicate the +initial states for A and B in your FSM descriptions. + + P18. In the generic SR protocol that we studied in Section 3.4.4 , the +sender transmits a message as soon as it is available (if it is in the +window) without waiting for an acknowledgment. Suppose now that we want +an SR protocol that sends messages two at a time. That is, the sender +will send a pair of messages and will send the next pair of messages +only when it knows that both messages in the first pair have been +received correctly. Suppose that the channel may lose messages but will +not corrupt or reorder messages. Design an error-control protocol for +the unidirectional reliable transfer of messages. Give an FSM +description of the sender and receiver. Describe the format of the +packets sent between sender and receiver, and vice versa. If you use any +procedure calls other than those in Section 3.4 (for example, udt_send() +, start_timer() , rdt_rcv() , and so on), clearly state their actions. +Give an example (a timeline trace of sender and receiver) showing how +your protocol recovers from a lost packet. P19. Consider a scenario in +which Host A wants to simultaneously send packets to Hosts B and C. A is +connected to B and C via a broadcast channel---a packet sent by A is +carried by the channel to both B and C. Suppose that the broadcast +channel connecting A, B, and C can independently lose and corrupt +packets (and so, for example, a packet sent from A might be correctly +received by B, but not by C). Design a stop-and-wait-like error-control +protocol for reliably transferring packets from A to B and C, such that +A will not get new data from the upper layer until it knows that both B +and C have correctly received the current packet. Give FSM descriptions +of A and C. (Hint: The FSM for B should be essentially the same as for +C.) Also, give a description of the packet format(s) used. P20. Consider +a scenario in which Host A and Host B want to send messages to Host C. +Hosts A and C are connected by a channel that can lose and corrupt (but +not reorder) messages. Hosts B and C are connected by another channel +(independent of the channel connecting A and C) with the same +properties. The transport layer at Host C should alternate in delivering +messages from A and B to the layer above (that is, it should first +deliver the data from a packet from A, then the data from a packet from +B, and so on). Design a stop-and-wait-like error-control protocol for +reliably transferring packets from A and B to C, with alternating +delivery at C as described above. Give FSM descriptions of A and C. +(Hint: The FSM for B should be essentially the same as for A.) Also, +give a description of the packet format(s) used. P21. Suppose we have +two network entities, A and B. B has a supply of data messages that will +be sent to A according to the following conventions. When A gets a +request from the layer above to get the next data (D) message from B, A +must send a request (R) message to B on the A-to-B channel. Only when B +receives an R message can it send a data (D) message back to A on the +B-to-A channel. A should deliver exactly one copy of each D message to +the layer above. R messages can be lost (but not corrupted) in the +A-to-B channel; D messages, once sent, are always delivered correctly. +The delay along both channels is unknown and variable. Design (give an +FSM description of) a protocol that incorporates the appropriate +mechanisms to compensate for the loss-prone A-to-B channel and +implements message passing to the layer above at entity A, as discussed +above. Use only those mechanisms that are absolutely + + necessary. P22. Consider the GBN protocol with a sender window size of 4 +and a sequence number range of 1,024. Suppose that at time t, the next +in-order packet that the receiver is expecting has a sequence number of +k. Assume that the medium does not reorder messages. Answer the +following questions: + +a. What are the possible sets of sequence numbers inside the sender's + window at time t? Justify your answer. + +b. What are all possible values of the ACK field in all possible + messages currently propagating back to the sender at time t? Justify + your answer. P23. Consider the GBN and SR protocols. Suppose the + sequence number space is of size k. What is the largest allowable + sender window that will avoid the occurrence of problems such as + that in Figure 3.27 for each of these protocols? P24. Answer true or + false to the following questions and briefly justify your answer: + +c. With the SR protocol, it is possible for the sender to receive an + ACK for a packet that falls outside of its current window. + +d. With GBN, it is possible for the sender to receive an ACK for a + packet that falls outside of its current window. + +e. The alternating-bit protocol is the same as the SR protocol with a + sender and receiver window size of 1. + +f. The alternating-bit protocol is the same as the GBN protocol with a + sender and receiver window size of 1. P25. We have said that an + application may choose UDP for a transport protocol because UDP + offers finer application control (than TCP) of what data is sent in + a segment and when. + +g. Why does an application have more control of what data is sent in a + segment? + +h. Why does an application have more control on when the segment is + sent? P26. Consider transferring an enormous file of L bytes from + Host A to Host B. Assume an MSS of 536 bytes. + +i. What is the maximum value of L such that TCP sequence numbers are + not exhausted? Recall that the TCP sequence number field has 4 + bytes. + +j. For the L you obtain in (a), find how long it takes to transmit the + file. Assume that a total of 66 bytes of transport, network, and + data-link header are added to each segment before the resulting + packet is sent out over a 155 Mbps link. Ignore flow control and + congestion control so A can pump out the segments back to back and + continuously. P27. Host A and B are communicating over a TCP + connection, and Host B has already received from A all bytes up + through byte 126. Suppose Host A then sends two segments to Host B + backto-back. The first and second segments contain 80 and 40 bytes + of data, respectively. In the first + + segment, the sequence number is 127, the source port number is 302, and +the destination port number is 80. Host B sends an acknowledgment +whenever it receives a segment from Host A. + +a. In the second segment sent from Host A to B, what are the sequence + number, source port number, and destination port number? + +b. If the first segment arrives before the second segment, in the + acknowledgment of the first arriving segment, what is the + acknowledgment number, the source port number, and the destination + port number? + +c. If the second segment arrives before the first segment, in the + acknowledgment of the first arriving segment, what is the + acknowledgment number? + +d. Suppose the two segments sent by A arrive in order at B. The first + acknowledgment is lost and the second acknowledgment arrives after + the first timeout interval. Draw a timing diagram, showing these + segments and all other segments and acknowledgments sent. (Assume + there is no additional packet loss.) For each segment in your + figure, provide the sequence number and the number of bytes of data; + for each acknowledgment that you add, provide the acknowledgment + number. P28. Host A and B are directly connected with a 100 Mbps + link. There is one TCP connection between the two hosts, and Host A + is sending to Host B an enormous file over this connection. Host A + can send its application data into its TCP socket at a rate as high + as 120 Mbps but Host B can read out of its TCP receive buffer at a + maximum rate of 50 Mbps. Describe the effect of TCP flow control. + P29. SYN cookies were discussed in Section 3.5.6 . + +e. Why is it necessary for the server to use a special initial sequence + number in the SYNACK? + +f. Suppose an attacker knows that a target host uses SYN cookies. Can + the attacker create half-open or fully open connections by simply + sending an ACK packet to the target? Why or why not? + +g. Suppose an attacker collects a large amount of initial sequence + numbers sent by the server. Can the attacker cause the server to + create many fully open connections by sending ACKs with those + initial sequence numbers? Why? P30. Consider the network shown in + Scenario 2 in Section 3.6.1 . Suppose both sending hosts A and B + have some fixed timeout values. + +h. Argue that increasing the size of the finite buffer of the router + might possibly decrease the throughput (λout). + +i. Now suppose both hosts dynamically adjust their timeout values (like + what TCP does) based on the buffering delay at the router. Would + increasing the buffer size help to increase the throughput? Why? + P31. Suppose that the five measured SampleRTT values (see Section + 3.5.3 ) are 106 ms, 120 + + ms, 140 ms, 90 ms, and 115 ms. Compute the EstimatedRTT after each of +these SampleRTT values is obtained, using a value of α=0.125 and +assuming that the value of EstimatedRTT was 100 ms just before the first +of these five samples were obtained. Compute also the DevRTT after each +sample is obtained, assuming a value of β=0.25 and assuming the value of +DevRTT was 5 ms just before the first of these five samples was +obtained. Last, compute the TCP TimeoutInterval after each of these +samples is obtained. P32. Consider the TCP procedure for estimating RTT. +Suppose that α=0.1. Let SampleRTT 1 be the most recent sample RTT, let +SampleRTT 2 be the next most recent sample RTT, and so on. + +a. For a given TCP connection, suppose four acknowledgments have been + returned with corresponding sample RTTs: SampleRTT 4, SampleRTT 3, + SampleRTT 2, and SampleRTT 1. Express EstimatedRTT in terms of the + four sample RTTs. + +b. Generalize your formula for n sample RTTs. + +c. For the formula in part (b) let n approach infinity. Comment on why + this averaging procedure is called an exponential moving average. + P33. In Section 3.5.3 , we discussed TCP's estimation of RTT. Why do + you think TCP avoids measuring the SampleRTT for retransmitted + segments? P34. What is the relationship between the variable + SendBase in Section 3.5.4 and the variable LastByteRcvd in Section + 3.5.5 ? P35. What is the relationship between the variable + LastByteRcvd in Section 3.5.5 and the variable y in Section 3.5.4? + P36. In Section 3.5.4 , we saw that TCP waits until it has received + three duplicate ACKs before performing a fast retransmit. Why do you + think the TCP designers chose not to perform a fast retransmit after + the first duplicate ACK for a segment is received? P37. Compare GBN, + SR, and TCP (no delayed ACK). Assume that the timeout values for all + three protocols are sufficiently long such that 5 consecutive data + segments and their corresponding ACKs can be received (if not lost + in the channel) by the receiving host (Host B) and the sending host + (Host A) respectively. Suppose Host A sends 5 data segments to Host + B, and the 2nd segment (sent from A) is lost. In the end, all 5 data + segments have been correctly received by Host B. + +d. How many segments has Host A sent in total and how many ACKs has + Host B sent in total? What are their sequence numbers? Answer this + question for all three protocols. + +e. If the timeout values for all three protocol are much longer than 5 + RTT, then which protocol successfully delivers all five data + segments in shortest time interval? P38. In our description of TCP + in Figure 3.53 , the value of the threshold, ssthresh , is set as + ssthresh=cwnd/2 in several places and ssthresh value is referred to + as being set to half the window size when a loss event occurred. + Must the rate at which the sender is sending when the loss event + occurred be approximately equal to cwnd segments per RTT? Explain + your + + answer. If your answer is no, can you suggest a different manner in +which ssthresh should be set? P39. Consider Figure 3.46(b) . If λ′in +increases beyond R/2, can λout increase beyond R/3? Explain. Now +consider Figure 3.46(c) . If λ′in increases beyond R/2, can λout +increase beyond R/4 under the assumption that a packet will be forwarded +twice on average from the router to the receiver? Explain. P40. Consider +Figure 3.58 . Assuming TCP Reno is the protocol experiencing the +behavior shown above, answer the following questions. In all cases, you +should provide a short discussion justifying your answer. + +Examining the behavior of TCP + +a. Identify the intervals of time when TCP slow start is operating. + +b. Identify the intervals of time when TCP congestion avoidance is + operating. + +c. After the 16th transmission round, is segment loss detected by a + triple duplicate ACK or by a timeout? + +d. After the 22nd transmission round, is segment loss detected by a + triple duplicate ACK or by a timeout? + +Figure 3.58 TCP window size as a function of time + + e. What is the initial value of ssthresh at the first transmission +round? f. What is the value of ssthresh at the 18th transmission round? +g. What is the value of ssthresh at the 24th transmission round? h. +During what transmission round is the 70th segment sent? i. Assuming a +packet loss is detected after the 26th round by the receipt of a triple +duplicate ACK, what will be the values of the congestion window size and +of ssthresh ? + +j. Suppose TCP Tahoe is used (instead of TCP Reno), and assume that + triple duplicate ACKs are received at the 16th round. What are the + ssthresh and the congestion window size at the 19th round? + +k. Again suppose TCP Tahoe is used, and there is a timeout event at + 22nd round. How many packets have been sent out from 17th round till + 22nd round, inclusive? P41. Refer to Figure 3.55 , which illustrates + the convergence of TCP's AIMD algorithm. Suppose that instead of a + multiplicative decrease, TCP decreased the window size by a constant + amount. Would the resulting AIAD algorithm converge to an equal + share algorithm? Justify your answer using a diagram similar to + Figure 3.55 . P42. In Section 3.5.4 , we discussed the doubling of + the timeout interval after a timeout event. This mechanism is a form + of congestion control. Why does TCP need a window-based + congestion-control mechanism (as studied in Section 3.7 ) in + addition to this doubling-timeoutinterval mechanism? P43. Host A is + sending an enormous file to Host B over a TCP connection. Over this + connection there is never any packet loss and the timers never + expire. Denote the transmission rate of the link connecting Host A + to the Internet by R bps. Suppose that the process in Host A is + capable of sending data into its TCP socket at a rate S bps, where + S=10⋅R. Further suppose that the TCP receive buffer is large enough + to hold the entire file, and the send buffer can hold only one + percent of the file. What would prevent the process in Host A from + continuously passing data to its TCP socket at rate S bps? TCP flow + control? TCP congestion control? Or something else? Elaborate. P44. + Consider sending a large file from a host to another over a TCP + connection that has no loss. + +l. Suppose TCP uses AIMD for its congestion control without slow start. + Assuming cwnd increases by 1 MSS every time a batch of ACKs is + received and assuming approximately constant round-trip times, how + long does it take for cwnd increase from 6 MSS to 12 MSS (assuming + no loss events)? + +m. What is the average throughout (in terms of MSS and RTT) for this + connection up through time=6 RTT? P45. Recall the macroscopic + description of TCP throughput. In the period of time from when the + + connection's rate varies from W/(2 · RTT) to W/RTT, only one packet is +lost (at the very end of the period). + +a. Show that the loss rate (fraction of packets lost) is equal to + L=loss rate=138W2+34W + +b. Use the result above to show that if a connection has loss rate L, + then its average rate is approximately given by ≈1.22⋅MSSRTTL P46. + Consider that only a single TCP (Reno) connection uses one 10Mbps + link which does not buffer any data. Suppose that this link is the + only congested link between the sending and receiving hosts. Assume + that the TCP sender has a huge file to send to the receiver, and the + receiver's receive buffer is much larger than the congestion window. + We also make the following assumptions: each TCP segment size is + 1,500 bytes; the two-way propagation delay of this connection is 150 + msec; and this TCP connection is always in congestion avoidance + phase, that is, ignore slow start. + +c. What is the maximum window size (in segments) that this TCP + connection can achieve? + +d. What is the average window size (in segments) and average throughput + (in bps) of this TCP connection? + +e. How long would it take for this TCP connection to reach its maximum + window again after recovering from a packet loss? P47. Consider the + scenario described in the previous problem. Suppose that the 10Mbps + link can buffer a finite number of segments. Argue that in order for + the link to always be busy sending data, we would like to choose a + buffer size that is at least the product of the link speed C and the + two-way propagation delay between the sender and the receiver. P48. + Repeat Problem 46, but replacing the 10 Mbps link with a 10 Gbps + link. Note that in your answer to part c, you will realize that it + takes a very long time for the congestion window size to reach its + maximum window size after recovering from a packet loss. Sketch a + solution to solve this problem. P49. Let T (measured by RTT) denote + the time interval that a TCP connection takes to increase its + congestion window size from W/2 to W, where W is the maximum + congestion window size. Argue that T is a function of TCP's average + throughput. P50. Consider a simplified TCP's AIMD algorithm where + the congestion window size is measured in number of segments, not in + bytes. In additive increase, the congestion window size increases by + one segment in each RTT. In multiplicative decrease, the congestion + window size decreases by half (if the result is not an integer, + round down to the nearest integer). Suppose that two TCP + connections, C1 and C2, share a single congested link of speed 30 + segments per second. Assume that both C1 and C2 are in the + congestion avoidance phase. Connection C1's RTT is 50 msec and + connection C2's RTT is 100 msec. Assume that when the data rate in + the + + link exceeds the link's speed, all TCP connections experience data +segment loss. + +a. If both C1 and C2 at time t0 have a congestion window of 10 + segments, what are their congestion window sizes after 1000 msec? + +b. In the long run, will these two connections get the same share of + the bandwidth of the congested link? Explain. P51. Consider the + network described in the previous problem. Now suppose that the two + TCP connections, C1 and C2, have the same RTT of 100 msec. Suppose + that at time t0, C1's congestion window size is 15 segments but C2's + congestion window size is 10 segments. + +c. What are their congestion window sizes after 2200 msec? + +d. In the long run, will these two connections get about the same share + of the bandwidth of the congested link? + +e. We say that two connections are synchronized, if both connections + reach their maximum window sizes at the same time and reach their + minimum window sizes at the same time. In the long run, will these + two connections get synchronized eventually? If so, what are their + maximum window sizes? + +f. Will this synchronization help to improve the utilization of the + shared link? Why? Sketch some idea to break this synchronization. + P52. Consider a modification to TCP's congestion control algorithm. + Instead of additive increase, we can use multiplicative increase. A + TCP sender increases its window size by a small positive constant + a(0\<a\<1) whenever it receives a valid ACK. Find the functional + relationship between loss rate L and maximum congestion window W. + Argue that for this modified TCP, regardless of TCP's average + throughput, a TCP connection always spends the same amount of time + to increase its congestion window size from W/2 to W. P53. In our + discussion of TCP futures in Section 3.7 , we noted that to achieve + a throughput of 10 Gbps, TCP could only tolerate a segment loss + probability of 2⋅10−10 (or equivalently, one loss event for every + 5,000,000,000 segments). Show the derivation for the values of + 2⋅10−10 (1 out of 5,000,000) for the RTT and MSS values given in + Section 3.7 . If TCP needed to support a 100 Gbps connection, what + would the tolerable loss be? P54. In our discussion of TCP + congestion control in Section 3.7 , we implicitly assumed that the + TCP sender always had data to send. Consider now the case that the + TCP sender sends a large amount of data and then goes idle (since it + has no more data to send) at t1. TCP remains idle for a relatively + long period of time and then wants to send more data at t2. What are + the advantages and disadvantages of having TCP use the cwnd and + ssthresh values from t1 when starting to send data at t2? What + alternative would you recommend? Why? P55. In this problem we + investigate whether either UDP or TCP provides a degree of end-point + authentication. + +g. Consider a server that receives a request within a UDP packet and + responds to that request within a UDP packet (for example, as done + by a DNS server). If a client with IP + + address X spoofs its address with address Y, where will the server send +its response? + +b. Suppose a server receives a SYN with IP source address Y, and after + responding with a SYNACK, receives an ACK with IP source address Y + with the correct acknowledgment number. Assuming the server chooses + a random initial sequence number and there is no + "man-in-the-middle," can the server be certain that the client is + indeed at Y (and not at some other address X that is spoofing Y)? + P56. In this problem, we consider the delay introduced by the TCP + slow-start phase. Consider a client and a Web server directly + connected by one link of rate R. Suppose the client wants to + retrieve an object whose size is exactly equal to 15 S, where S is + the maximum segment size (MSS). Denote the round-trip time between + client and server as RTT (assumed to be constant). Ignoring protocol + headers, determine the time to retrieve the object (including TCP + connection establishment) when + +c. 4 S/R\>S/R+RTT\>2S/R + +d. S/R+RTT\>4 S/R + +e. S/R\>RTT. + +Programming Assignments Implementing a Reliable Transport Protocol In +this laboratory programming assignment, you will be writing the sending +and receiving transport-level code for implementing a simple reliable +data transfer protocol. There are two versions of this lab, the +alternating-bit-protocol version and the GBN version. This lab should be +fun---your implementation will differ very little from what would be +required in a real-world situation. Since you probably don't have +standalone machines (with an OS that you can modify), your code will +have to execute in a simulated hardware/software environment. However, +the programming interface provided to your routines---the code that +would call your entities from above and from below---is very close to +what is done in an actual UNIX environment. (Indeed, the software +interfaces described in this programming assignment are much more +realistic than the infinite loop senders and receivers that many texts +describe.) Stopping and starting timers are also simulated, and timer +interrupts will cause your timer handling routine to be activated. The +full lab assignment, as well as code you will need to compile with your +own code, are available at this book's Web site: +www.pearsonhighered.com/cs-resources. + +Wireshark Lab: Exploring TCP + + In this lab, you'll use your Web browser to access a file from a Web +server. As in earlier Wireshark labs, you'll use Wireshark to capture +the packets arriving at your computer. Unlike earlier labs, you'll also +be able to download a Wireshark-readable packet trace from the Web +server from which you downloaded the file. In this server trace, you'll +find the packets that were generated by your own access of the Web +server. You'll analyze the client- and server-side traces to explore +aspects of TCP. In particular, you'll evaluate the performance of the +TCP connection between your computer and the Web server. You'll trace +TCP's window behavior, and infer packet loss, retransmission, flow +control and congestion control behavior, and estimated roundtrip time. +As is the case with all Wireshark labs, the full description of this lab +is available at this book's Web site, +www.pearsonhighered.com/cs-resources. + +Wireshark Lab: Exploring UDP In this short lab, you'll do a packet +capture and analysis of your favorite application that uses UDP (for +example, DNS or a multimedia application such as Skype). As we learned +in Section 3.3, UDP is a simple, no-frills transport protocol. In this +lab, you'll investigate the header fields in the UDP segment as well as +the checksum calculation. As is the case with all Wireshark labs, the +full description of this lab is available at this book's Web site, +www.pearsonhighered.com/cs-resources. AN INTERVIEW WITH... Van Jacobson +Van Jacobson works at Google and was previously a Research Fellow at +PARC. Prior to that, he was co-founder and Chief Scientist of Packet +Design. Before that, he was Chief Scientist at Cisco. Before joining +Cisco, he was head of the Network Research Group at Lawrence Berkeley +National Laboratory and taught at UC Berkeley and Stanford. Van received +the ACM SIGCOMM Award in 2001 for outstanding lifetime contribution to +the field of communication networks and the IEEE Kobayashi Award in 2002 +for "contributing to the understanding of network congestion and +developing congestion control mechanisms that enabled the successful +scaling of the Internet". He was elected to the U.S. National Academy of +Engineering in 2004. + + Please describe one or two of the most exciting projects you have worked +on during your career. What were the biggest challenges? School teaches +us lots of ways to find answers. In every interesting problem I've +worked on, the challenge has been finding the right question. When Mike +Karels and I started looking at TCP congestion, we spent months staring +at protocol and packet traces asking "Why is it failing?". One day in +Mike's office, one of us said "The reason I can't figure out why it +fails is because I don't understand how it ever worked to begin with." +That turned out to be the right question and it forced us to figure out +the "ack clocking" that makes TCP work. After that, the rest was easy. +More generally, where do you see the future of networking and the +Internet? For most people, the Web is the Internet. Networking geeks +smile politely since we know the Web is an application running over the +Internet but what if they're right? The Internet is about enabling +conversations between pairs of hosts. The Web is about distributed +information production and consumption. "Information propagation" is a +very general view of communication of which "pairwise conversation" is a +tiny subset. We need to move into the larger tent. Networking today +deals with broadcast media (radios, PONs, etc.) by pretending it's a +point-topoint wire. That's massively inefficient. Terabits-per-second of +data are being exchanged all over the World via thumb drives or smart +phones but we don't know how to treat that as "networking". ISPs are +busily setting up caches and CDNs to scalably distribute video and +audio. Caching is a necessary part of the solution but there's no part +of today's networking---from Information, Queuing or Traffic Theory down +to the Internet protocol specs---that tells us how to engineer and +deploy it. I think and hope that over the next few years, networking +will evolve to embrace the much larger vision of communication that +underlies the Web. What people inspired you professionally? + + When I was in grad school, Richard Feynman visited and gave a +colloquium. He talked about a piece of Quantum theory that I'd been +struggling with all semester and his explanation was so simple and lucid +that what had been incomprehensible gibberish to me became obvious and +inevitable. That ability to see and convey the simplicity that underlies +our complex world seems to me a rare and wonderful gift. What are your +recommendations for students who want careers in computer science and +networking? It's a wonderful field---computers and networking have +probably had more impact on society than any invention since the book. +Networking is fundamentally about connecting stuff, and studying it +helps you make intellectual connections: Ant foraging & Bee dances +demonstrate protocol design better than RFCs, traffic jams or people +leaving a packed stadium are the essence of congestion, and students +finding flights back to school in a post-Thanksgiving blizzard are the +core of dynamic routing. If you're interested in lots of stuff and want +to have an impact, it's hard to imagine a better field. + + Chapter 4 The Network Layer: Data Plane + +We learned in the previous chapter that the transport layer provides +various forms of process-to-process communication by relying on the +network layer's host-to-host communication service. We also learned that +the transport layer does so without any knowledge about how the network +layer actually implements this service. So perhaps you're now wondering, +what's under the hood of the host-to-host communication service, what +makes it tick? In this chapter and the next, we'll learn exactly how the +network layer can provide its host-to-host communication service. We'll +see that unlike the transport and application layers, there is a piece +of the network layer in each and every host and router in the network. +Because of this, network-layer protocols are among the most challenging +(and therefore among the most interesting!) in the protocol stack. Since +the network layer is arguably the most complex layer in the protocol +stack, we'll have a lot of ground to cover here. Indeed, there is so +much to cover that we cover the network layer in two chapters. We'll see +that the network layer can be decomposed into two interacting parts, the +data plane and the control plane. In Chapter 4, we'll first cover the +data plane functions of the network layer---the perrouter functions in +the network layer that determine how a datagram (that is, a +network-layer packet) arriving on one of a router's input links is +forwarded to one of that router's output links. We'll cover both +traditional IP forwarding (where forwarding is based on a datagram's +destination address) and generalized forwarding (where forwarding and +other functions may be performed using values in several different +fields in the datagram's header). We'll study the IPv4 and IPv6 +protocols and addressing in detail. In Chapter 5, we'll cover the +control plane functions of the network layer---the network-wide logic +that controls how a datagram is routed among routers along an end-to-end +path from the source host to the destination host. We'll cover routing +algorithms, as well as routing protocols, such as OSPF and BGP, that are +in widespread use in today's Internet. Traditionally, these +control-plane routing protocols and data-plane forwarding functions have +been implemented together, monolithically, within a router. +Software-defined networking (SDN) explicitly separates the data plane +and control plane by implementing these control plane functions as a +separate service, typically in a remote "controller." We'll also cover +SDN controllers in Chapter 5. This distinction between data-plane and +control-plane functions in the network layer is an important concept to +keep in mind as you learn about the network layer ---it will help +structure your thinking about + + the network layer and reflects a modern view of the network layer's role +in computer networking. + + 4.1 Overview of Network Layer Figure 4.1 shows a simple network with two +hosts, H1 and H2, and several routers on the path between H1 and H2. +Let's suppose that H1 is sending information to H2, and consider the +role of the network layer in these hosts and in the intervening routers. +The network layer in H1 takes segments from the transport layer in H1, +encapsulates each segment into a datagram, and then sends the datagrams +to its nearby router, R1. At the receiving host, H2, the network layer +receives the datagrams from its nearby router R2, extracts the +transport-layer segments, and delivers the segments up to the transport +layer at H2. The primary data-plane role of each router is to forward +datagrams from its input links to its output links; the primary role of +the network control plane is to coordinate these local, per-router +forwarding actions so that datagrams are ultimately transferred +end-to-end, along paths of routers between source and destination hosts. +Note that the routers in Figure 4.1 are shown with a truncated protocol +stack, that is, with no upper layers above the network layer, because +routers do not run application- and transportlayer protocols such as +those we examined in Chapters 2 and 3. + +4.1.1 Forwarding and Routing: The Data and Control Planes The primary +role of the network layer is deceptively simple---to move packets from a +sending host to a receiving host. To do so, two important network-layer +functions can be identified: Forwarding. When a packet arrives at a +router's input link, the router must move the packet to the appropriate +output link. For example, a packet arriving from Host H1 to Router R1 in +Figure 4.1 must be forwarded to the next router on a path to H2. As we +will see, forwarding is but one function (albeit the most + + Figure 4.1 The network layer + +common and important one!) implemented in the data plane. In the more +general case, which we'll cover in Section 4.4, a packet might also be +blocked from exiting a router (e.g., if the packet originated at a known +malicious sending host, or if the packet were destined to a forbidden +destination host), or might be duplicated and sent over multiple +outgoing links. Routing. The network layer must determine the route or +path taken by packets as they flow from a sender to a receiver. The +algorithms that calculate these paths are referred to as routing +algorithms. A routing algorithm would determine, for example, the path +along which packets flow + + from H1 to H2 in Figure 4.1. Routing is implemented in the control plane +of the network layer. The terms forwarding and routing are often used +interchangeably by authors discussing the network layer. We'll use these +terms much more precisely in this book. Forwarding refers to the +router-local action of transferring a packet from an input link +interface to the appropriate output link interface. Forwarding takes +place at very short timescales (typically a few nanoseconds), and thus +is typically implemented in hardware. Routing refers to the network-wide +process that determines the end-to-end paths that packets take from +source to destination. Routing takes place on much longer timescales +(typically seconds), and as we will see is often implemented in +software. Using our driving analogy, consider the trip from Pennsylvania +to Florida undertaken by our traveler back in Section 1.3.1. During this +trip, our driver passes through many interchanges en route to Florida. +We can think of forwarding as the process of getting through a single +interchange: A car enters the interchange from one road and determines +which road it should take to leave the interchange. We can think of +routing as the process of planning the trip from Pennsylvania to +Florida: Before embarking on the trip, the driver has consulted a map +and chosen one of many paths possible, with each path consisting of a +series of road segments connected at interchanges. A key element in +every network router is its forwarding table. A router forwards a packet +by examining the value of one or more fields in the arriving packet's +header, and then using these header values to index into its forwarding +table. The value stored in the forwarding table entry for those values +indicates the outgoing link interface at that router to which that +packet is to be forwarded. For example, in Figure 4.2, a packet with +header field value of 0110 arrives to a router. The router indexes into +its forwarding table and determines that the output link interface for +this packet is interface 2. The router then internally forwards the +packet to interface 2. In Section 4.2, we'll look inside a router and +examine the forwarding function in much greater detail. Forwarding is +the key function performed by the data-plane functionality of the +network layer. Control Plane: The Traditional Approach But now you are +undoubtedly wondering how a router's forwarding tables are configured in +the first place. This is a crucial issue, one that exposes the important +interplay between forwarding (in data plane) and routing (in control +plane). As shown + + Figure 4.2 Routing algorithms determine values in forward tables + +in Figure 4.2, the routing algorithm determines the contents of the +routers' forwarding tables. In this example, a routing algorithm runs in +each and every router and both forwarding and routing functions are +contained within a router. As we'll see in Sections 5.3 and 5.4, the +routing algorithm function in one router communicates with the routing +algorithm function in other routers to compute the values for its +forwarding table. How is this communication performed? By exchanging +routing messages containing routing information according to a routing +protocol! We'll cover routing algorithms and protocols in Sections 5.2 +through 5.4. The distinct and different purposes of the forwarding and +routing functions can be further illustrated by considering the +hypothetical (and unrealistic, but technically feasible) case of a +network in which all forwarding tables are configured directly by human +network operators physically present at the routers. In this case, no +routing protocols would be required! Of course, the human operators +would need to interact with each other to ensure that the forwarding +tables were configured in such a way that packets reached their intended +destinations. It's also likely that human configuration would be more +error-prone and much slower to respond to changes in the network +topology than a routing protocol. We're thus fortunate that all networks +have both a forwarding and a routing function! Control Plane: The SDN +Approach The approach to implementing routing functionality shown in +Figure 4.2---with each router having a routing component that +communicates with the routing component of other routers---has been the + + traditional approach adopted by routing vendors in their products, at +least until recently. Our observation that humans could manually +configure forwarding tables does suggest, however, that there may be +other ways for control-plane functionality to determine the contents of +the data-plane forwarding tables. Figure 4.3 shows an alternate approach +in which a physically separate (from the routers), remote controller +computes and distributes the forwarding tables to be used by each and +every router. Note that the data plane components of Figures 4.2 and 4.3 +are identical. In Figure 4.3, however, control-plane routing +functionality is separated + +Figure 4.3 A remote controller determines and distributes values in +forwarding tables + +from the physical router---the routing device performs forwarding only, +while the remote controller computes and distributes forwarding tables. +The remote controller might be implemented in a remote data center with +high reliability and redundancy, and might be managed by the ISP or some +third party. How might the routers and the remote controller +communicate? By exchanging messages containing forwarding tables and +other pieces of routing information. The control-plane approach shown in +Figure 4.3 is at the heart of software-defined networking (SDN), where +the network is "software-defined" because the controller that computes +forwarding tables and interacts with routers is implemented in software. +Increasingly, these software implementations are also open, i.e., +similar to Linux OS code, the + + code is publically available, allowing ISPs (and networking researchers +and students!) to innovate and propose changes to the software that +controls network-layer functionality. We will cover the SDN control +plane in Section 5.5. + +4.1.2 Network Service Model Before delving into the network layer's data +plane, let's wrap up our introduction by taking the broader view and +consider the different types of service that might be offered by the +network layer. When the transport layer at a sending host transmits a +packet into the network (that is, passes it down to the network layer at +the sending host), can the transport layer rely on the network layer to +deliver the packet to the destination? When multiple packets are sent, +will they be delivered to the transport layer in the receiving host in +the order in which they were sent? Will the amount of time between the +sending of two sequential packet transmissions be the same as the amount +of time between their reception? Will the network provide any feedback +about congestion in the network? The answers to these questions and +others are determined by the service model provided by the network +layer. The network service model defines the characteristics of +end-to-end delivery of packets between sending and receiving hosts. +Let's now consider some possible services that the network layer could +provide. These services could include: Guaranteed delivery. This service +guarantees that a packet sent by a source host will eventually arrive at +the destination host. Guaranteed delivery with bounded delay. This +service not only guarantees delivery of the packet, but delivery within +a specified host-to-host delay bound (for example, within 100 msec). +In-order packet delivery. This service guarantees that packets arrive at +the destination in the order that they were sent. Guaranteed minimal +bandwidth. This network-layer service emulates the behavior of a +transmission link of a specified bit rate (for example, 1 Mbps) between +sending and receiving hosts. As long as the sending host transmits bits +(as part of packets) at a rate below the specified bit rate, then all +packets are eventually delivered to the destination host. Security. The +network layer could encrypt all datagrams at the source and decrypt them +at the destination, thereby providing confidentiality to all +transport-layer segments. This is only a partial list of services that a +network layer could provide---there are countless variations possible. +The Internet's network layer provides a single service, known as +best-effort service. With best-effort service, packets are neither +guaranteed to be received in the order in which they were sent, nor is +their eventual delivery even guaranteed. There is no guarantee on the +end-to-end delay nor is there a + + minimal bandwidth guarantee. It might appear that best-effort service is +a euphemism for no service at all---a network that delivered no packets +to the destination would satisfy the definition of best-effort delivery +service! Other network architectures have defined and implemented +service models that go beyond the Internet's best-effort service. For +example, the ATM network architecture \[MFA Forum 2016, Black 1995\] +provides for guaranteed in-order delay, bounded delay, and guaranteed +minimal bandwidth. There have also been proposed service model +extensions to the Internet architecture; for example, the Intserv +architecture \[RFC 1633\] aims to provide end-end delay guarantees and +congestion-free communication. Interestingly, in spite of these +well-developed alternatives, the Internet's basic best-effort service +model combined with adequate bandwidth provisioning have arguably proven +to be more than "good enough" to enable an amazing range of +applications, including streaming video services such as Netflix and +voice-and-video-over-IP, real-time conferencing applications such as +Skype and Facetime. + +An Overview of Chapter 4 Having now provided an overview of the network +layer, we'll cover the data-plane component of the network layer in the +following sections in this chapter. In Section 4.2, we'll dive down into +the internal hardware operations of a router, including input and output +packet processing, the router's internal switching mechanism, and packet +queueing and scheduling. In Section 4.3, we'll take a look at +traditional IP forwarding, in which packets are forwarded to output +ports based on their destination IP addresses. We'll encounter IP +addressing, the celebrated IPv4 and IPv6 protocols and more. In Section +4.4, we'll cover more generalized forwarding, where packets may be +forwarded to output ports based on a large number of header values +(i.e., not only based on destination IP address). Packets may be blocked +or duplicated at the router, or may have certain header field values +rewritten---all under software control. This more generalized form of +packet forwarding is a key component of a modern network data plane, +including the data plane in software-defined networks (SDN). We mention +here in passing that the terms forwarding and switching are often used +interchangeably by computer-networking researchers and practitioners; +we'll use both terms interchangeably in this textbook as well. While +we're on the topic of terminology, it's also worth mentioning two other +terms that are often used interchangeably, but that we will use more +carefully. We'll reserve the term packet switch to mean a general +packet-switching device that transfers a packet from input link +interface to output link interface, according to values in a packet's +header fields. Some packet switches, called link-layer switches +(examined in Chapter 6), base their forwarding decision on values in the +fields of the linklayer frame; switches are thus referred to as +link-layer (layer 2) devices. Other packet switches, called routers, +base their forwarding decision on header field values in the +network-layer datagram. Routers are thus network-layer (layer 3) +devices. (To fully appreciate this important distinction, you might want +to review Section 1.5.2, where we discuss network-layer datagrams and +link-layer frames and their relationship.) Since our focus in this +chapter is on the network layer, we'll mostly use the term router in +place of packet switch. + + 4.2 What's Inside a Router? Now that we've overviewed the data and +control planes within the network layer, the important distinction +between forwarding and routing, and the services and functions of the +network layer, let's turn our attention to its forwarding function---the +actual transfer of packets from a router's incoming links to the +appropriate outgoing links at that router. A high-level view of a +generic router architecture is shown in Figure 4.4. Four router +components can be identified: + +Figure 4.4 Router architecture + +Input ports. An input port performs several key functions. It performs +the physical layer function of terminating an incoming physical link at +a router; this is shown in the leftmost box of an input port and the +rightmost box of an output port in Figure 4.4. An input port also +performs link-layer functions needed to interoperate with the link layer +at the other side of the incoming link; this is represented by the +middle boxes in the input and output ports. Perhaps most crucially, a +lookup function is also performed at the input port; this will occur in +the rightmost box of the input port. It is here that the forwarding +table is consulted to determine the router output port to which an +arriving packet will be forwarded via the switching fabric. Control +packets (for example, packets carrying routing protocol information) are +forwarded from an input port to the routing processor. Note that the +term "port" here ---referring to the physical input and output router +interfaces---is distinctly different from the software + + ports associated with network applications and sockets discussed in +Chapters 2 and 3. In practice, the number of ports supported by a router +can range from a relatively small number in enterprise routers, to +hundreds of 10 Gbps ports in a router at an ISP's edge, where the number +of incoming lines tends to be the greatest. The Juniper MX2020, edge +router, for example, supports up to 960 10 Gbps Ethernet ports, with an +overall router system capacity of 80 Tbps \[Juniper MX 2020 2016\]. +Switching fabric. The switching fabric connects the router's input ports +to its output ports. This switching fabric is completely contained +within the router---a network inside of a network router! Output ports. +An output port stores packets received from the switching fabric and +transmits these packets on the outgoing link by performing the necessary +link-layer and physical-layer functions. When a link is bidirectional +(that is, carries traffic in both directions), an output port will +typically be paired with the input port for that link on the same line +card. Routing processor. The routing processor performs control-plane +functions. In traditional routers, it executes the routing protocols +(which we'll study in Sections 5.3 and 5.4), maintains routing tables +and attached link state information, and computes the forwarding table +for the router. In SDN routers, the routing processor is responsible for +communicating with the remote controller in order to (among other +activities) receive forwarding table entries computed by the remote +controller, and install these entries in the router's input ports. The +routing processor also performs the network management functions that +we'll study in Section 5.7. A router's input ports, output ports, and +switching fabric are almost always implemented in hardware, as shown in +Figure 4.4. To appreciate why a hardware implementation is needed, +consider that with a 10 Gbps input link and a 64-byte IP datagram, the +input port has only 51.2 ns to process the datagram before another +datagram may arrive. If N ports are combined on a line card (as is often +done in practice), the datagram-processing pipeline must operate N times +faster---far too fast for software implementation. Forwarding hardware +can be implemented either using a router vendor's own hardware designs, +or constructed using purchased merchant-silicon chips (e.g., as sold by +companies such as Intel and Broadcom). While the data plane operates at +the nanosecond time scale, a router's control functions---executing the +routing protocols, responding to attached links that go up or down, +communicating with the remote controller (in the SDN case) and +performing management functions---operate at the millisecond or second +timescale. These control plane functions are thus usually implemented in +software and execute on the routing processor (typically a traditional +CPU). Before delving into the details of router internals, let's return +to our analogy from the beginning of this chapter, where packet +forwarding was compared to cars entering and leaving an interchange. +Let's suppose that the interchange is a roundabout, and that as a car +enters the roundabout, a bit of processing is required. Let's consider +what information is required for this processing: Destination-based +forwarding. Suppose the car stops at an entry station and indicates its +final + + destination (not at the local roundabout, but the ultimate destination +of its journey). An attendant at the entry station looks up the final +destination, determines the roundabout exit that leads to that final +destination, and tells the driver which roundabout exit to take. +Generalized forwarding. The attendant could also determine the car's +exit ramp on the basis of many other factors besides the destination. +For example, the selected exit ramp might depend on the car's origin, +for example the state that issued the car's license plate. Cars from a +certain set of states might be directed to use one exit ramp (that leads +to the destination via a slow road), while cars from other states might +be directed to use a different exit ramp (that leads to the destination +via superhighway). The same decision might be made based on the model, +make and year of the car. Or a car not deemed roadworthy might be +blocked and not be allowed to pass through the roundabout. In the case +of generalized forwarding, any number of factors may contribute to the +attendant's choice of the exit ramp for a given car. Once the car enters +the roundabout (which may be filled with other cars entering from other +input roads and heading to other roundabout exits), it eventually leaves +at the prescribed roundabout exit ramp, where it may encounter other +cars leaving the roundabout at that exit. We can easily recognize the +principal router components in Figure 4.4 in this analogy---the entry +road and entry station correspond to the input port (with a lookup +function to determine to local outgoing port); the roundabout +corresponds to the switch fabric; and the roundabout exit road +corresponds to the output port. With this analogy, it's instructive to +consider where bottlenecks might occur. What happens if cars arrive +blazingly fast (for example, the roundabout is in Germany or Italy!) but +the station attendant is slow? How fast must the attendant work to +ensure there's no backup on an entry road? Even with a blazingly fast +attendant, what happens if cars traverse the roundabout slowly---can +backups still occur? And what happens if most of the cars entering at +all of the roundabout's entrance ramps all want to leave the roundabout +at the same exit ramp---can backups occur at the exit ramp or elsewhere? +How should the roundabout operate if we want to assign priorities to +different cars, or block certain cars from entering the roundabout in +the first place? These are all analogous to critical questions faced by +router and switch designers. In the following subsections, we'll look at +router functions in more detail. \[Iyer 2008, Chao 2001; Chuang 2005; +Turner 1988; McKeown 1997a; Partridge 1998; Sopranos 2011\] provide a +discussion of specific router architectures. For concreteness and +simplicity, we'll initially assume in this section that forwarding +decisions are based only on the packet's destination address, rather +than on a generalized set of packet header fields. We will cover the +case of more generalized packet forwarding in Section 4.4. + +4.2.1 Input Port Processing and Destination-Based Forwarding + + A more detailed view of input processing is shown in Figure 4.5. As just +discussed, the input port's linetermination function and link-layer +processing implement the physical and link layers for that individual +input link. The lookup performed in the input port is central to the +router's operation---it is here that the router uses the forwarding +table to look up the output port to which an arriving packet will be +forwarded via the switching fabric. The forwarding table is either +computed and updated by the routing processor (using a routing protocol +to interact with the routing processors in other network routers) or is +received from a remote SDN controller. The forwarding table is copied +from the routing processor to the line cards over a separate bus (e.g., +a PCI bus) indicated by the dashed line from the routing processor to +the input line cards in Figure 4.4. With such a shadow copy at each line +card, forwarding decisions can be made locally, at each input port, +without invoking the centralized routing processor on a per-packet basis +and thus avoiding a centralized processing bottleneck. Let's now +consider the "simplest" case that the output port to which an incoming +packet is to be switched is based on the packet's destination address. +In the case of 32-bit IP addresses, a brute-force implementation of the +forwarding table would have one entry for every possible destination +address. Since there are more than 4 billion possible addresses, this +option is totally out of the question. + +Figure 4.5 Input port processing + +As an example of how this issue of scale can be handled, let's suppose +that our router has four links, numbered 0 through 3, and that packets +are to be forwarded to the link interfaces as follows: + +Destination Address Range + +Link Interface + +11001000 00010111 00010000 00000000 + +0 + +through 11001000 00010111 00010111 11111111 + +11001000 00010111 00011000 00000000 + +1 + + through 11001000 00010111 00011000 11111111 + +11001000 00010111 00011001 00000000 + +2 + +through 11001000 00010111 00011111 11111111 + +Otherwise + +3 + +Clearly, for this example, it is not necessary to have 4 billion entries +in the router's forwarding table. We could, for example, have the +following forwarding table with just four entries: + +Prefix + +Link Interface + +11001000 00010111 00010 + +0 + +11001000 00010111 00011000 + +1 + +11001000 00010111 00011 + +2 + +Otherwise + +3 + +With this style of forwarding table, the router matches a prefix of the +packet's destination address with the entries in the table; if there's a +match, the router forwards the packet to a link associated with the +match. For example, suppose the packet's destination address is 11001000 +00010111 00010110 10100001 ; because the 21-bit prefix of this address +matches the first entry in the table, the router forwards the packet to +link interface 0. If a prefix doesn't match any of the first three +entries, then the router forwards the packet to the default interface 3. +Although this sounds simple enough, there's a very important subtlety +here. You may have noticed that it is possible for a destination address +to match more than one entry. For example, the first 24 bits of the +address 11001000 00010111 00011000 10101010 match the second entry in +the table, and the first 21 bits of the address match the third entry in +the table. When there are multiple matches, the router uses the longest +prefix matching rule; that is, it finds the longest matching entry in +the table and forwards the packet to the link interface associated with +the longest prefix match. We'll see exactly why this longest +prefix-matching rule is used when we study Internet addressing in more +detail in Section 4.3. + + Given the existence of a forwarding table, lookup is conceptually +simple---hardware logic just searches through the forwarding table +looking for the longest prefix match. But at Gigabit transmission rates, +this lookup must be performed in nanoseconds (recall our earlier example +of a 10 Gbps link and a 64-byte IP datagram). Thus, not only must lookup +be performed in hardware, but techniques beyond a simple linear search +through a large table are needed; surveys of fast lookup algorithms can +be found in \[Gupta 2001, Ruiz-Sanchez 2001\]. Special attention must +also be paid to memory access times, resulting in designs with embedded +on-chip DRAM and faster SRAM (used as a DRAM cache) memories. In +practice, Ternary Content Addressable Memories (TCAMs) are also often +used for lookup \[Yu 2004\]. With a TCAM, a 32-bit IP address is +presented to the memory, which returns the content of the forwarding +table entry for that address in essentially constant time. The Cisco +Catalyst 6500 and 7600 Series routers and switches can hold upwards of a +million TCAM forwarding table entries \[Cisco TCAM 2014\]. Once a +packet's output port has been determined via the lookup, the packet can +be sent into the switching fabric. In some designs, a packet may be +temporarily blocked from entering the switching fabric if packets from +other input ports are currently using the fabric. A blocked packet will +be queued at the input port and then scheduled to cross the fabric at a +later point in time. We'll take a closer look at the blocking, queuing, +and scheduling of packets (at both input ports and output ports) +shortly. Although "lookup" is arguably the most important action in +input port processing, many other actions must be taken: (1) physical- +and link-layer processing must occur, as discussed previously; (2) the +packet's version number, checksum and time-to-live field---all of which +we'll study in Section 4.3---must be checked and the latter two fields +rewritten; and (3) counters used for network management (such as the +number of IP datagrams received) must be updated. Let's close our +discussion of input port processing by noting that the input port steps +of looking up a destination IP address ("match") and then sending the +packet into the switching fabric to the specified output port ("action") +is a specific case of a more general "match plus action" abstraction +that is performed in many networked devices, not just routers. In +link-layer switches (covered in Chapter 6), link-layer destination +addresses are looked up and several actions may be taken in addition to +sending the frame into the switching fabric towards the output port. In +firewalls (covered in Chapter 8)---devices that filter out selected +incoming packets---an incoming packet whose header matches a given +criteria (e.g., a combination of source/destination IP addresses and +transport-layer port numbers) may be dropped (action). In a network +address translator (NAT, covered in Section 4.3), an incoming packet +whose transport-layer port number matches a given value will have its +port number rewritten before forwarding (action). Indeed, the "match +plus action" abstraction is both powerful and prevalent in network +devices today, and is central to the notion of generalized forwarding +that we'll study in Section 4.4. + + 4.2.2 Switching The switching fabric is at the very heart of a router, +as it is through this fabric that the packets are actually switched +(that is, forwarded) from an input port to an output port. Switching can +be accomplished in a number of ways, as shown in Figure 4.6: Switching +via memory. The simplest, earliest routers were traditional computers, +with switching between input and output ports being done under direct +control of the CPU (routing processor). Input and output ports +functioned as traditional I/O devices in a traditional operating system. +An input port with an arriving packet first signaled the routing +processor via an interrupt. The packet was then copied from the input +port into processor memory. The routing processor then extracted the +destination address from the header, looked up the appropriate output +port in the forwarding table, and copied the packet to the output port's +buffers. In this scenario, if the memory bandwidth is such that a +maximum of B packets per second can be written into, or read from, +memory, then the overall forwarding throughput (the total rate at which +packets are transferred from input ports to output ports) must be less +than B/2. Note also that two packets cannot be forwarded + +Figure 4.6 Three switching techniques + + at the same time, even if they have different destination ports, since +only one memory read/write can be done at a time over the shared system +bus. Some modern routers switch via memory. A major difference from +early routers, however, is that the lookup of the destination address +and the storing of the packet into the appropriate memory location are +performed by processing on the input line cards. In some ways, routers +that switch via memory look very much like shared-memory +multiprocessors, with the processing on a line card switching (writing) +packets into the memory of the appropriate output port. Cisco's Catalyst +8500 series switches \[Cisco 8500 2016\] internally switches packets via +a shared memory. Switching via a bus. In this approach, an input port +transfers a packet directly to the output port over a shared bus, +without intervention by the routing processor. This is typically done by +having the input port pre-pend a switch-internal label (header) to the +packet indicating the local output port to which this packet is being +transferred and transmitting the packet onto the bus. All output ports +receive the packet, but only the port that matches the label will keep +the packet. The label is then removed at the output port, as this label +is only used within the switch to cross the bus. If multiple packets +arrive to the router at the same time, each at a different input port, +all but one must wait since only one packet can cross the bus at a time. +Because every packet must cross the single bus, the switching speed of +the router is limited to the bus speed; in our roundabout analogy, this +is as if the roundabout could only contain one car at a time. +Nonetheless, switching via a bus is often sufficient for routers that +operate in small local area and enterprise networks. The Cisco 6500 +router \[Cisco 6500 2016\] internally switches packets over a +32-Gbps-backplane bus. Switching via an interconnection network. One way +to overcome the bandwidth limitation of a single, shared bus is to use a +more sophisticated interconnection network, such as those that have been +used in the past to interconnect processors in a multiprocessor computer +architecture. A crossbar switch is an interconnection network consisting +of 2N buses that connect N input ports to N output ports, as shown in +Figure 4.6. Each vertical bus intersects each horizontal bus at a +crosspoint, which can be opened or closed at any time by the switch +fabric controller (whose logic is + + part of the switching fabric itself). When a packet arrives from port A +and needs to be forwarded to port Y, the switch controller closes the +crosspoint at the intersection of busses A and Y, and port A then sends +the packet onto its bus, which is picked up (only) by bus Y. Note that a +packet from port B can be forwarded to port X at the same time, since +the A-to-Y and B-to-X packets use different input and output busses. +Thus, unlike the previous two switching approaches, crossbar switches +are capable of forwarding multiple packets in parallel. A crossbar +switch is non-blocking---a packet being forwarded to an output port will +not be blocked from reaching that output port as long as no other packet +is currently being forwarded to that output port. However, if two +packets from two different input ports are destined to that same output +port, then one will have to wait at the input, since only one packet can +be sent over any given bus at a time. Cisco 12000 series switches +\[Cisco 12000 2016\] use a crossbar switching network; the Cisco 7600 +series can be configured to use either a bus or crossbar switch \[Cisco +7600 2016\]. More sophisticated interconnection networks use multiple +stages of switching elements to allow packets from different input ports +to proceed towards the same output port at the same time through the +multi-stage switching fabric. See \[Tobagi 1990\] for a survey of switch +architectures. The Cisco CRS employs a three-stage non-blocking +switching strategy. A router's switching capacity can also be scaled by +running multiple switching fabrics in parallel. In this approach, input +ports and output ports are connected to N switching fabrics that operate +in parallel. An input port breaks a packet into K smaller chunks, and +sends ("sprays") the chunks through K of these N switching fabrics to +the selected output port, which reassembles the K chunks back into the +original packet. + +4.2.3 Output Port Processing Output port processing, shown in Figure +4.7, takes packets that have been stored in the output port's memory and +transmits them over the output link. This includes selecting and +de-queueing packets for transmission, and performing the needed +link-layer and physical-layer transmission functions. + +4.2.4 Where Does Queuing Occur? If we consider input and output port +functionality and the configurations shown in Figure 4.6, it's clear +that packet queues may form at both the input ports and the output +ports, just as we identified cases where cars may wait at the inputs and +outputs of the traffic intersection in our roundabout analogy. The +location and extent of queueing (either at the input port queues or the +output port queues) will depend on the traffic load, the relative speed +of the switching fabric, and the line speed. Let's now consider these +queues in a bit more detail, since as these queues grow large, the +router's memory can eventually be exhausted and packet loss will occur +when no memory is available to store arriving packets. Recall that in +our earlier discussions, we said that packets were "lost within the +network" or "dropped at a + + router." It is here, at these queues within a router, where such packets +are actually dropped and lost. + +Figure 4.7 Output port processing + +Suppose that the input and output line speeds (transmission rates) all +have an identical transmission rate of Rline packets per second, and +that there are N input ports and N output ports. To further simplify the +discussion, let's assume that all packets have the same fixed length, +and that packets arrive to input ports in a synchronous manner. That is, +the time to send a packet on any link is equal to the time to receive a +packet on any link, and during such an interval of time, either zero or +one packets can arrive on an input link. Define the switching fabric +transfer rate Rswitch as the rate at which packets can be moved from +input port to output port. If Rswitch is N times faster than Rline, then +only negligible queuing will occur at the input ports. This is because +even in the worst case, where all N input lines are receiving packets, +and all packets are to be forwarded to the same output port, each batch +of N packets (one packet per input port) can be cleared through the +switch fabric before the next batch arrives. Input Queueing But what +happens if the switch fabric is not fast enough (relative to the input +line speeds) to transfer all arriving packets through the fabric without +delay? In this case, packet queuing can also occur at the input ports, +as packets must join input port queues to wait their turn to be +transferred through the switching fabric to the output port. To +illustrate an important consequence of this queuing, consider a crossbar +switching fabric and suppose that (1) all link speeds are identical, (2) +that one packet can be transferred from any one input port to a given +output port in the same amount of time it takes for a packet to be +received on an input link, and (3) packets are moved from a given input +queue to their desired output queue in an FCFS manner. Multiple packets +can be transferred in parallel, as long as their output ports are +different. However, if two packets at the front of two input queues are +destined for the same output queue, then one of the packets will be +blocked and must wait at the input queue---the switching fabric can +transfer only one packet to a given output port at a time. Figure 4.8 +shows an example in which two packets (darkly shaded) at the front of +their input queues are destined for the same upper-right output port. +Suppose that the switch fabric chooses to transfer the packet from the +front of the upper-left queue. In this case, the darkly shaded packet in +the lower-left queue must wait. But not only must this darkly shaded +packet wait, so too must the lightly shaded + + packet that is queued behind that packet in the lower-left queue, even +though there is no contention for the middle-right output port (the +destination for the lightly shaded packet). This phenomenon is known as +head-of-the-line (HOL) blocking in an input-queued switch---a queued +packet in an input queue must wait for transfer through the fabric (even +though its output port is free) because it is blocked by another packet +at the head of the line. \[Karol 1987\] shows that due to HOL blocking, +the input queue will grow to unbounded length (informally, this is +equivalent to saying that significant packet loss will occur) under +certain assumptions as soon as the packet arrival rate on the input +links reaches only 58 percent of their capacity. A number of solutions +to HOL blocking are discussed in \[McKeown 1997\]. + +Figure 4.8 HOL blocking at and input-queued switch + +Output Queueing Let's next consider whether queueing can occur at a +switch's output ports. Suppose that Rswitch is again N times faster than +Rline and that packets arriving at each of the N input ports are +destined to the same output port. In this case, in the time it takes to +send a single packet onto the outgoing link, N new packets will arrive +at this output port (one from each of the N input ports). Since the +output port can + + transmit only a single packet in a unit of time (the packet transmission +time), the N arriving packets will have to queue (wait) for transmission +over the outgoing link. Then N more packets can possibly arrive in the +time it takes to transmit just one of the N packets that had just +previously been queued. And so on. Thus, packet queues can form at the +output ports even when the switching fabric is N times faster than the +port line speeds. Eventually, the number of queued packets can grow +large enough to exhaust available memory at the output port. + +Figure 4.9 Output port queueing + +When there is not enough memory to buffer an incoming packet, a decision +must be made to either drop the arriving packet (a policy known as +drop-tail) or remove one or more already-queued packets to make room for +the newly arrived packet. In some cases, it may be advantageous to drop +(or mark the header of) a packet before the buffer is full in order to +provide a congestion signal to the sender. A number of proactive +packet-dropping and -marking policies (which collectively have become +known as active queue management (AQM) algorithms) have been proposed +and analyzed \[Labrador 1999, Hollot 2002\]. One of the most widely +studied and implemented AQM algorithms is the Random Early Detection +(RED) algorithm \[Christiansen 2001; Floyd 2016\]. Output port queuing +is illustrated in Figure 4.9. At time t, a packet has arrived at each of +the incoming input ports, each destined for the uppermost outgoing port. +Assuming identical line speeds and a switch operating at three times the +line speed, one time unit later (that is, in the time needed to receive +or send + + a packet), all three original packets have been transferred to the +outgoing port and are queued awaiting transmission. In the next time +unit, one of these three packets will have been transmitted over the +outgoing link. In our example, two new packets have arrived at the +incoming side of the switch; one of these packets is destined for this +uppermost output port. A consequence of such queuing is that a packet +scheduler at the output port must choose one packet, among those queued, +for transmission--- a topic we'll cover in the following section. Given +that router buffers are needed to absorb the fluctuations in traffic +load, a natural question to ask is how much buffering is required. For +many years, the rule of thumb \[RFC 3439\] for buffer sizing was that +the amount of buffering (B) should be equal to an average round-trip +time (RTT, say 250 msec) times the link capacity (C). This result is +based on an analysis of the queueing dynamics of a relatively small +number of TCP flows \[Villamizar 1994\]. Thus, a 10 Gbps link with an +RTT of 250 msec would need an amount of buffering equal to B 5 RTT · C 5 +2.5 Gbits of buffers. More recent theoretical and experimental efforts +\[Appenzeller 2004\], however, suggest that when there are a large +number of TCP flows (N) passing through a link, the amount of buffering +needed is B=RTI⋅C/N. With a large number of flows typically passing +through large backbone router links (see, e.g., \[Fraleigh 2003\]), the +value of N can be large, with the decrease in needed buffer size +becoming quite significant. \[Appenzeller 2004; Wischik 2005; Beheshti +2008\] provide very readable discussions of the buffer-sizing problem +from a theoretical, implementation, and operational standpoint. + +4.2.5 Packet Scheduling Let's now return to the question of determining +the order in which queued packets are transmitted over an outgoing link. +Since you yourself have undoubtedly had to wait in long lines on many +occasions and observed how waiting customers are served, you're no doubt +familiar with many of the queueing disciplines commonly used in routers. +There is first-come-first-served (FCFS, also known as first-in-firstout, +FIFO). The British are famous for patient and orderly FCFS queueing at +bus stops and in the marketplace ("Oh, are you queueing?"). Other +countries operate on a priority basis, with one class of waiting +customers given priority service over other waiting customers. There is +also round-robin queueing, where customers are again divided into +classes (as in priority queueing) but each class of customer is given +service in turn. First-in-First-Out (FIFO) Figure 4.10 shows the queuing +model abstraction for the FIFO link-scheduling discipline. Packets +arriving at the link output queue wait for transmission if the link is +currently busy transmitting another packet. If there is not sufficient +buffering space to hold the arriving packet, the queue's +packetdiscarding policy then determines whether the packet will be +dropped (lost) or whether other packets will be removed from the queue +to make space for the arriving packet, as discussed above. In our + + discussion below, we'll ignore packet discard. When a packet is +completely transmitted over the outgoing link (that is, receives +service) it is removed from the queue. The FIFO (also known as +first-come-first-served, or FCFS) scheduling discipline selects packets +for link transmission in the same order in which they arrived at the +output link queue. We're all familiar with FIFO queuing from service +centers, where + +Figure 4.10 FIFO queueing abstraction + +arriving customers join the back of the single waiting line, remain in +order, and are then served when they reach the front of the line. Figure +4.11 shows the FIFO queue in operation. Packet arrivals are indicated by +numbered arrows above the upper timeline, with the number indicating the +order in which the packet arrived. Individual packet departures are +shown below the lower timeline. The time that a packet spends in service +(being transmitted) is indicated by the shaded rectangle between the two +timelines. In our examples here, let's assume that each packet takes +three units of time to be transmitted. Under the FIFO discipline, +packets leave in the same order in which they arrived. Note that after +the departure of packet 4, the link remains idle (since packets 1 +through 4 have been transmitted and removed from the queue) until the +arrival of packet 5. Priority Queuing Under priority queuing, packets +arriving at the output link are classified into priority classes upon +arrival at the queue, as shown in Figure 4.12. In practice, a network +operator may configure a queue so that packets carrying network +management information (e.g., as indicated by the source or destination +TCP/UDP port number) receive priority over user traffic; additionally, +real-time voice-over-IP packets might receive priority over non-real +traffic such as SMTP or IMAP e-mail packets. Each + + Figure 4.11 The FIFO queue in operation + +Figure 4.12 The priority queueing model + +priority class typically has its own queue. When choosing a packet to +transmit, the priority queuing discipline will transmit a packet from +the highest priority class that has a nonempty queue (that is, has +packets waiting for transmission). The choice among packets in the same +priority class is typically done in a FIFO manner. Figure 4.13 +illustrates the operation of a priority queue with two priority classes. +Packets 1, 3, and 4 belong to the high-priority class, and packets 2 and +5 belong to the low-priority class. Packet 1 arrives and, finding the +link idle, begins transmission. During the transmission of packet 1, +packets 2 and 3 arrive and are queued in the low- and high-priority +queues, respectively. After the transmission of packet 1, packet 3 (a +high-priority packet) is selected for transmission over packet 2 (which, +even though it arrived earlier, is a low-priority packet). At the end of +the transmission of packet 3, packet 2 then begins transmission. Packet +4 (a high-priority packet) arrives during the transmission of packet 2 +(a low-priority packet). Under a non-preemptive priority queuing +discipline, the transmission of a packet is not interrupted once it has + + Figure 4.13 The priority queue in operation + +Figure 4.14 The two-class robin queue in operation + +begun. In this case, packet 4 queues for transmission and begins being +transmitted after the transmission of packet 2 is completed. Round Robin +and Weighted Fair Queuing (WFQ) Under the round robin queuing +discipline, packets are sorted into classes as with priority queuing. +However, rather than there being a strict service priority among +classes, a round robin scheduler alternates service among the classes. +In the simplest form of round robin scheduling, a class 1 packet is +transmitted, followed by a class 2 packet, followed by a class 1 packet, +followed by a class 2 packet, and so on. A so-called work-conserving +queuing discipline will never allow the link to remain idle whenever +there are packets (of any class) queued for transmission. A +work-conserving round robin discipline that looks for a packet of a +given class but finds none will immediately check the next class in the +round robin sequence. Figure 4.14 illustrates the operation of a +two-class round robin queue. In this example, packets 1, 2, and + + 4 belong to class 1, and packets 3 and 5 belong to the second class. +Packet 1 begins transmission immediately upon arrival at the output +queue. Packets 2 and 3 arrive during the transmission of packet 1 and +thus queue for transmission. After the transmission of packet 1, the +link scheduler looks for a class 2 packet and thus transmits packet 3. +After the transmission of packet 3, the scheduler looks for a class 1 +packet and thus transmits packet 2. After the transmission of packet 2, +packet 4 is the only queued packet; it is thus transmitted immediately +after packet 2. A generalized form of round robin queuing that has been +widely implemented in routers is the so-called weighted fair queuing +(WFQ) discipline \[Demers 1990; Parekh 1993; Cisco QoS 2016\]. WFQ is +illustrated in Figure 4.15. Here, arriving packets are classified and +queued in the appropriate per-class waiting area. As in round robin +scheduling, a WFQ scheduler will serve classes in a circular manner--- +first serving class 1, then serving class 2, then serving class 3, and +then (assuming there are three classes) repeating the service pattern. +WFQ is also a work-conserving + +Figure 4.15 Weighted fair queueing + +queuing discipline and thus will immediately move on to the next class +in the service sequence when it finds an empty class queue. WFQ differs +from round robin in that each class may receive a differential amount of +service in any interval of time. Specifically, each class, i, is +assigned a weight, wi. Under WFQ, during any interval of time during +which there are class i packets to send, class i will then be guaranteed +to receive a fraction of service equal to wi/(∑wj), where the sum in the +denominator is taken over all classes that also have packets queued for +transmission. In the worst case, even if all classes have queued +packets, class i will still be guaranteed to receive a fraction wi/(∑wj) +of the bandwidth, where in this worst case the sum in the denominator is +over all classes. Thus, for a link with transmission rate R, class i +will always achieve a throughput of at least R⋅wi/(∑wj). Our description +of WFQ has been idealized, as we have not considered the fact that +packets are discrete and a packet's transmission will not be interrupted +to begin transmission of another packet; \[Demers 1990; Parekh 1993\] +discuss this packetization issue. + + 4.3 The Internet Protocol (IP): IPv4, Addressing, IPv6, and More Our +study of the network layer thus far in Chapter 4---the notion of the +data and control plane component of the network layer, our distinction +between forwarding and routing, the identification of various network +service models, and our look inside a router---have often been without +reference to any specific computer network architecture or protocol. In +this section we'll focus on key aspects of the network layer on today's +Internet and the celebrated Internet Protocol (IP). There are two +versions of IP in use today. We'll first examine the widely deployed IP +protocol version 4, which is usually referred to simply as IPv4 \[RFC +791\] + +Figure 4.16 IPv4 datagram format + +in Section 4.3.1. We'll examine IP version 6 \[RFC 2460; RFC 4291\], +which has been proposed to replace IPv4, in Section 4.3.5. In between, +we'll primarily cover Internet addressing---a topic that might seem +rather dry and detail-oriented but we'll see is crucial to understanding +how the Internet's network layer works. To master IP addressing is to +master the Internet's network layer itself! + + 4.3.1 IPv4 Datagram Format Recall that the Internet's network-layer +packet is referred to as a datagram. We begin our study of IP with an +overview of the syntax and semantics of the IPv4 datagram. You might be +thinking that nothing could be drier than the syntax and semantics of a +packet's bits. Nevertheless, the datagram plays a central role in the +Internet---every networking student and professional needs to see it, +absorb it, and master it. (And just to see that protocol headers can +indeed be fun to study, check out \[Pomeranz 2010\]). The IPv4 datagram +format is shown in Figure 4.16. The key fields in the IPv4 datagram are +the following: Version number. These 4 bits specify the IP protocol +version of the datagram. By looking at the version number, the router +can determine how to interpret the remainder of the IP datagram. +Different versions of IP use different datagram formats. The datagram +format for IPv4 is shown in Figure 4.16. The datagram format for the new +version of IP (IPv6) is discussed in Section 4.3.5. Header length. +Because an IPv4 datagram can contain a variable number of options (which +are included in the IPv4 datagram header), these 4 bits are needed to +determine where in the IP datagram the payload (e.g., the +transport-layer segment being encapsulated in this datagram) actually +begins. Most IP datagrams do not contain options, so the typical IP +datagram has a 20-byte header. Type of service. The type of service +(TOS) bits were included in the IPv4 header to allow different types of +IP datagrams to be distinguished from each other. For example, it might +be useful to distinguish real-time datagrams (such as those used by an +IP telephony application) from non-realtime traffic (for example, FTP). +The specific level of service to be provided is a policy issue +determined and configured by the network administrator for that router. +We also learned in Section 3.7.2 that two of the TOS bits are used for +Explicit Congestion Notification. Datagram length. This is the total +length of the IP datagram (header plus data), measured in bytes. Since +this field is 16 bits long, the theoretical maximum size of the IP +datagram is 65,535 bytes. However, datagrams are rarely larger than +1,500 bytes, which allows an IP datagram to fit in the payload field of +a maximally sized Ethernet frame. Identifier, flags, fragmentation +offset. These three fields have to do with so-called IP fragmentation, a +topic we will consider shortly. Interestingly, the new version of IP, +IPv6, does not allow for fragmentation. Time-to-live. The time-to-live +(TTL) field is included to ensure that datagrams do not circulate +forever (due to, for example, a long-lived routing loop) in the network. +This field is decremented by one each time the datagram is processed by +a router. If the TTL field reaches 0, a router must drop that datagram. +Protocol. This field is typically used only when an IP datagram reaches +its final destination. The value of this field indicates the specific +transport-layer protocol to which the data portion of this IP datagram +should be passed. For example, a value of 6 indicates that the data +portion is passed to TCP, while a value of 17 indicates that the data is +passed to UDP. For a list of all possible values, + + see \[IANA Protocol Numbers 2016\]. Note that the protocol number in the +IP datagram has a role that is analogous to the role of the port number +field in the transport-layer segment. The protocol number is the glue +that binds the network and transport layers together, whereas the port +number is the glue that binds the transport and application layers +together. We'll see in Chapter 6 that the linklayer frame also has a +special field that binds the link layer to the network layer. Header +checksum. The header checksum aids a router in detecting bit errors in a +received IP datagram. The header checksum is computed by treating each 2 +bytes in the header as a number and summing these numbers using 1s +complement arithmetic. As discussed in Section 3.3, the 1s complement of +this sum, known as the Internet checksum, is stored in the checksum +field. A router computes the header checksum for each received IP +datagram and detects an error condition if the checksum carried in the +datagram header does not equal the computed checksum. Routers typically +discard datagrams for which an error has been detected. Note that the +checksum must be recomputed and stored again at each router, since the +TTL field, and possibly the options field as well, will change. An +interesting discussion of fast algorithms for computing the Internet +checksum is \[RFC 1071\]. A question often asked at this point is, why +does TCP/IP perform error checking at both the transport and network +layers? There are several reasons for this repetition. First, note that +only the IP header is checksummed at the IP layer, while the TCP/UDP +checksum is computed over the entire TCP/UDP segment. Second, TCP/UDP +and IP do not necessarily both have to belong to the same protocol +stack. TCP can, in principle, run over a different network-layer +protocol (for example, ATM) \[Black 1995\]) and IP can carry data that +will not be passed to TCP/UDP. Source and destination IP addresses. When +a source creates a datagram, it inserts its IP address into the source +IP address field and inserts the address of the ultimate destination +into the destination IP address field. Often the source host determines +the destination address via a DNS lookup, as discussed in Chapter 2. +We'll discuss IP addressing in detail in Section 4.3.3. Options. The +options fields allow an IP header to be extended. Header options were +meant to be used rarely---hence the decision to save overhead by not +including the information in options fields in every datagram header. +However, the mere existence of options does complicate matters---since +datagram headers can be of variable length, one cannot determine a +priori where the data field will start. Also, since some datagrams may +require options processing and others may not, the amount of time needed +to process an IP datagram at a router can vary greatly. These +considerations become particularly important for IP processing in +high-performance routers and hosts. For these reasons and others, IP +options were not included in the IPv6 header, as discussed in Section +4.3.5. Data (payload). Finally, we come to the last and most important +field---the raison d'etre for the datagram in the first place! In most +circumstances, the data field of the IP datagram contains the +transport-layer segment (TCP or UDP) to be delivered to the destination. +However, the data field can carry other types of data, such as ICMP +messages (discussed in Section 5.6). Note that an IP datagram has a +total of 20 bytes of header (assuming no options). If the datagram +carries a TCP segment, then each (non-fragmented) datagram carries a +total of 40 bytes of header (20 bytes of IP header plus 20 bytes of TCP +header) along with the application-layer message. + + 4.3.2 IPv4 Datagram Fragmentation We'll see in Chapter 6 that not all +link-layer protocols can carry network-layer packets of the same size. +Some protocols can carry big datagrams, whereas other protocols can +carry only little datagrams. For example, Ethernet frames can carry up +to 1,500 bytes of data, whereas frames for some wide-area links can +carry no more than 576 bytes. The maximum amount of data that a +link-layer frame can carry is called the maximum transmission unit +(MTU). Because each IP datagram is encapsulated within the link-layer +frame for transport from one router to the next router, the MTU of the +link-layer protocol places a hard limit on the length of an IP datagram. +Having a hard limit on the size of an IP datagram is not much of a +problem. What is a problem is that each of the links along the route +between sender and destination can use different link-layer protocols, +and each of these protocols can have different MTUs. To understand the +forwarding issue better, imagine that you are a router that +interconnects several links, each running different link-layer protocols +with different MTUs. Suppose you receive an IP datagram from one link. +You check your forwarding table to determine the outgoing link, and this +outgoing link has an MTU that is smaller than the length of the IP +datagram. Time to panic---how are you going to squeeze this oversized IP +datagram into the payload field of the link-layer frame? The solution is +to fragment the payload in the IP datagram into two or more smaller IP +datagrams, encapsulate each of these smaller IP datagrams in a separate +link-layer frame; and send these frames over the outgoing link. Each of +these smaller datagrams is referred to as a fragment. Fragments need to +be reassembled before they reach the transport layer at the destination. +Indeed, both TCP and UDP are expecting to receive complete, unfragmented +segments from the network layer. The designers of IPv4 felt that +reassembling datagrams in the routers would introduce significant +complication into the protocol and put a damper on router performance. +(If you were a router, would you want to be reassembling fragments on +top of everything else you had to do?) Sticking to the principle of +keeping the network core simple, the designers of IPv4 decided to put +the job of datagram reassembly in the end systems rather than in network +routers. When a destination host receives a series of datagrams from the +same source, it needs to determine whether any of these datagrams are +fragments of some original, larger datagram. If some datagrams are +fragments, it must further determine when it has received the last +fragment and how the fragments it has received should be pieced back +together to form the original datagram. To allow the destination host to +perform these reassembly tasks, the designers of IP (version 4) put +identification, flag, and fragmentation offset fields in the IP datagram +header. When a datagram is created, the sending host stamps the datagram +with an identification number as well as source and destination +addresses. Typically, the sending host increments the identification +number for each datagram it sends. When a router needs to fragment a +datagram, each resulting datagram (that is, fragment) is stamped with +the + + source address, destination address, and identification number of the +original datagram. When the destination receives a series of datagrams +from the same sending host, it can examine the identification numbers of +the datagrams to determine which of the datagrams are actually fragments +of the same larger datagram. Because IP is an unreliable service, one or +more of the fragments may never arrive at the destination. For this +reason, in order for the destination host to be absolutely sure it has +received the last fragment of + +Figure 4.17 IP fragmentation and reassembly + +the original datagram, the last fragment has a flag bit set to 0, +whereas all the other fragments have this flag bit set to 1. Also, in +order for the destination host to determine whether a fragment is +missing (and also to be able to reassemble the fragments in their proper +order), the offset field is used to specify where the fragment fits +within the original IP datagram. Figure 4.17 illustrates an example. A +datagram of 4,000 bytes (20 bytes of IP header plus 3,980 bytes of IP +payload) arrives at a router and must be forwarded to a link with an MTU +of 1,500 bytes. This implies that the 3,980 data bytes in the original +datagram must be allocated to three separate fragments (each of which is +also an IP datagram). The online material for this book, and the +problems at the end of this chapter will allow you to explore +fragmentation in more detail. Also, on this book's Web site, we provide +a Java applet that generates fragments. You provide the incoming +datagram size, the MTU, and the incoming datagram identification. + + The applet automatically generates the fragments for you. See +http://www.pearsonhighered.com/csresources/. + +4.3.3 IPv4 Addressing We now turn our attention to IPv4 addressing. +Although you may be thinking that addressing must be a straightforward +topic, hopefully by the end of this section you'll be convinced that +Internet addressing is not only a juicy, subtle, and interesting topic +but also one that is of central importance to the Internet. An excellent +treatment of IPv4 addressing can be found in the first chapter in +\[Stewart 1999\]. Before discussing IP addressing, however, we'll need +to say a few words about how hosts and routers are connected into the +Internet. A host typically has only a single link into the network; when +IP in the host wants to send a datagram, it does so over this link. The +boundary between the host and the physical link is called an interface. +Now consider a router and its interfaces. Because a router's job is to +receive a datagram on one link and forward the datagram on some other +link, a router necessarily has two or more links to which it is +connected. The boundary between the router and any one of its links is +also called an interface. A router thus has multiple interfaces, one for +each of its links. Because every host and router is capable of sending +and receiving IP datagrams, IP requires each host and router interface +to have its own IP address. Thus, an IP address is technically +associated with an interface, rather than with the host or router +containing that interface. Each IP address is 32 bits long +(equivalently, 4 bytes), and there are thus a total of 232 (or +approximately 4 billion) possible IP addresses. These addresses are +typically written in so-called dotted-decimal notation, in which each +byte of the address is written in its decimal form and is separated by a +period (dot) from other bytes in the address. For example, consider the +IP address 193.32.216.9. The 193 is the decimal equivalent of the first +8 bits of the address; the 32 is the decimal equivalent of the second 8 +bits of the address, and so on. Thus, the address 193.32.216.9 in binary +notation is 11000001 00100000 11011000 00001001 Each interface on every +host and router in the global Internet must have an IP address that is +globally unique (except for interfaces behind NATs, as discussed in +Section 4.3.4). These addresses cannot be chosen in a willy-nilly +manner, however. A portion of an interface's IP address will be +determined by the subnet to which it is connected. Figure 4.18 provides +an example of IP addressing and interfaces. In this figure, one router +(with three interfaces) is used to interconnect seven hosts. Take a +close look at the IP addresses assigned to the host and router +interfaces, as there are several things to notice. The three hosts in +the upper-left portion of Figure 4.18, and the router interface to which +they are connected, all have an IP address of the form + + 223.1.1.xxx. That is, they all have the same leftmost 24 bits in their +IP address. These four interfaces are also interconnected to each other +by a network that contains no routers. This network could be +interconnected by an Ethernet LAN, in which case the interfaces would be +interconnected by an Ethernet switch (as we'll discuss in Chapter 6), or +by a wireless access point (as we'll discuss in Chapter 7). We'll +represent this routerless network connecting these hosts as a cloud for +now, and dive into the internals of such networks in Chapters 6 and 7. +In IP terms, this network interconnecting three host interfaces and one +router interface forms a subnet \[RFC 950\]. (A subnet is also called an +IP network or simply + +Figure 4.18 Interface addresses and subnets + +a network in the Internet literature.) IP addressing assigns an address +to this subnet: 223.1.1.0/24, where the /24 ("slash-24") notation, +sometimes known as a subnet mask, indicates that the leftmost 24 bits of +the 32-bit quantity define the subnet address. The 223.1.1.0/24 subnet +thus consists of the three host interfaces (223.1.1.1, 223.1.1.2, and +223.1.1.3) and one router interface (223.1.1.4). Any additional hosts +attached to the 223.1.1.0/24 subnet would be required to have an address +of the form 223.1.1.xxx. There are two additional subnets shown in +Figure 4.18: the 223.1.2.0/24 network and the 223.1.3.0/24 subnet. +Figure 4.19 illustrates the three IP subnets present in Figure 4.18. The +IP definition of a subnet is not restricted to Ethernet segments that +connect multiple hosts to a router interface. To get some insight here, +consider Figure 4.20, which shows three routers that are interconnected +with each other by point-to-point links. Each router has three +interfaces, one for each point-to-point link and one for the broadcast +link that directly connects the router to a pair of hosts. What + + subnets are present here? Three subnets, 223.1.1.0/24, 223.1.2.0/24, and +223.1.3.0/24, are similar to the subnets we encountered in Figure 4.18. +But note that there are three additional subnets in this example as +well: one subnet, 223.1.9.0/24, for the interfaces that connect routers +R1 and R2; another subnet, 223.1.8.0/24, for the interfaces that connect +routers R2 and R3; and a third subnet, 223.1.7.0/24, for the interfaces +that connect routers R3 and R1. For a general interconnected system of +routers and hosts, we can use the following recipe to define the subnets +in the system: + +Figure 4.19 Subnet addresses + +To determine the subnets, detach each interface from its host or router, +creating islands of isolated networks, with interfaces terminating the +end points of the isolated networks. Each of these isolated networks is +called a subnet. If we apply this procedure to the interconnected system +in Figure 4.20, we get six islands or subnets. From the discussion +above, it's clear that an organization (such as a company or academic +institution) with multiple Ethernet segments and point-to-point links +will have multiple subnets, with all of the devices on a given subnet +having the same subnet address. In principle, the different subnets +could have quite different subnet addresses. In practice, however, their +subnet addresses often have much in common. To understand why, let's +next turn our attention to how addressing is handled in the global +Internet. The Internet's address assignment strategy is known as +Classless Interdomain Routing (CIDR--- pronounced cider) \[RFC 4632\]. +CIDR generalizes the notion of subnet addressing. As with subnet + + addressing, the 32-bit IP address is divided into two parts and again +has the dotted-decimal form a.b.c.d/x, where x indicates the number of +bits in the first part of the address. The x most significant bits of an +address of the form a.b.c.d/x constitute the network portion of the IP +address, and are often referred to as the prefix (or network prefix) of +the address. An organization is typically assigned a block of contiguous +addresses, that is, a range of addresses with a common prefix (see the +Principles in Practice feature). In this case, the IP addresses of +devices within the organization will share the common prefix. When we +cover the Internet's BGP routing protocol in + +Figure 4.20 Three routers interconnecting six subnets + +Section 5.4, we'll see that only these x leading prefix bits are +considered by routers outside the organization's network. That is, when +a router outside the organization forwards a datagram whose destination +address is inside the organization, only the leading x bits of the +address need be considered. This considerably reduces the size of the +forwarding table in these routers, since a single entry of the form +a.b.c.d/x will be sufficient to forward packets to any destination +within the organization. The remaining 32-x bits of an address can be +thought of as distinguishing among the devices within the organization, +all of which have the same network prefix. These are the bits that will +be considered when forwarding packets at routers within the +organization. These lower-order bits may (or may not) have an + + additional subnetting structure, such as that discussed above. For +example, suppose the first 21 bits of the CIDRized address a.b.c.d/21 +specify the organization's network prefix and are common to the IP +addresses of all devices in that organization. The remaining 11 bits +then identify the specific hosts in the organization. The organization's +internal structure might be such that these 11 rightmost bits are used +for subnetting within the organization, as discussed above. For example, +a.b.c.d/24 might refer to a specific subnet within the organization. +Before CIDR was adopted, the network portions of an IP address were +constrained to be 8, 16, or 24 bits in length, an addressing scheme +known as classful addressing, since subnets with 8-, 16-, and 24-bit +subnet addresses were known as class A, B, and C networks, respectively. +The requirement that the subnet portion of an IP address be exactly 1, +2, or 3 bytes long turned out to be problematic for supporting the +rapidly growing number of organizations with small and medium-sized +subnets. A class C (/24) subnet could accommodate only up to 28 − 2 = +254 hosts (two of the 28 = 256 addresses are reserved for special +use)---too small for many organizations. However, a class B (/16) +subnet, which supports up to 65,634 hosts, was too large. Under classful +addressing, an organization with, say, 2,000 hosts was typically +allocated a class B (/16) subnet address. This led to a rapid depletion +of the class B address space and poor utilization of the assigned +address space. For example, the organization that used a class B address +for its 2,000 hosts was allocated enough of the address space for up to +65,534 interfaces---leaving more than 63,000 addresses that could not be +used by other organizations. + +PRINCIPLES IN PRACTICE This example of an ISP that connects eight +organizations to the Internet nicely illustrates how carefully allocated +CIDRized addresses facilitate routing. Suppose, as shown in Figure 4.21, +that the ISP (which we'll call Fly-By-Night-ISP) advertises to the +outside world that it should be sent any datagrams whose first 20 +address bits match 200.23.16.0/20. The rest of the world need not know +that within the address block 200.23.16.0/20 there are in fact eight +other organizations, each with its own subnets. This ability to use a +single prefix to advertise multiple networks is often referred to as +address aggregation (also route aggregation or route summarization). +Address aggregation works extremely well when addresses are allocated in +blocks to ISPs and then from ISPs to client organizations. But what +happens when addresses are not allocated in such a hierarchical manner? +What would happen, for example, if Fly-By-Night-ISP acquires ISPs-R-Us +and then has Organization 1 connect to the Internet through its +subsidiary ISPs-RUs? As shown in Figure 4.21, the subsidiary ISPs-R-Us +owns the address block 199.31.0.0/16, but Organization 1's IP addresses +are unfortunately outside of this address block. What should be done +here? Certainly, Organization 1 could renumber all of its routers and +hosts to have addresses within the ISPs-R-Us address block. But this is +a costly solution, and Organization 1 might well be reassigned to +another subsidiary in the future. The solution typically adopted is for +Organization 1 to keep its IP addresses in 200.23.18.0/23. In this case, +as shown in Figure 4.22, + + Fly-By-Night-ISP continues to advertise the address block 200.23.16.0/20 +and ISPs-R-Us continues to advertise 199.31.0.0/16. However, ISPs-R-Us +now also advertises the block of addresses for Organization 1, +200.23.18.0/23. When other routers in the larger Internet see the +address blocks 200.23.16.0/20 (from Fly-By-Night-ISP) and 200.23.18.0/23 +(from ISPs-R-Us) and want to route to an address in the block +200.23.18.0/23, they will use longest prefix matching (see Section +4.2.1), and route toward ISPs-R-Us, as it advertises the longest (i.e., +most-specific) address prefix that matches the destination address. + +Figure 4.21 Hierarchical addressing and route aggregation + + Figure 4.22 ISPs-R-Us has a more specific route to Organization 1 + +We would be remiss if we did not mention yet another type of IP address, +the IP broadcast address 255.255.255.255. When a host sends a datagram +with destination address 255.255.255.255, the message is delivered to +all hosts on the same subnet. Routers optionally forward the message +into neighboring subnets as well (although they usually don't). Having +now studied IP addressing in detail, we need to know how hosts and +subnets get their addresses in the first place. Let's begin by looking +at how an organization gets a block of addresses for its devices, and +then look at how a device (such as a host) is assigned an address from +within the organization's block of addresses. Obtaining a Block of +Addresses In order to obtain a block of IP addresses for use within an +organization's subnet, a network administrator might first contact its +ISP, which would provide addresses from a larger block of addresses that +had already been allocated to the ISP. For example, the ISP may itself +have been allocated the address block 200.23.16.0/20. The ISP, in turn, +could divide its address block into eight equal-sized contiguous address +blocks and give one of these address blocks out to each of up to eight +organizations that are supported by this ISP, as shown below. (We have +underlined the subnet part of these addresses for your convenience.) +ISP's block: + +200.23.16.0/20 + +11001000 00010111 00010000 00000000 + + Organization 0 + +200.23.16.0/23 + +11001000 00010111 00010000 00000000 + +Organization 1 + +200.23.18.0/23 + +11001000 00010111 00010010 00000000 + +Organization 2 + +200.23.20.0/23 + +11001000 00010111 00010100 00000000 + + ... ... Organization 7 + +200.23.30.0/23 + + ... 11001000 00010111 00011110 00000000 + +While obtaining a set of addresses from an ISP is one way to get a block +of addresses, it is not the only way. Clearly, there must also be a way +for the ISP itself to get a block of addresses. Is there a global +authority that has ultimate responsibility for managing the IP address +space and allocating address blocks to ISPs and other organizations? +Indeed there is! IP addresses are managed under the authority of the +Internet Corporation for Assigned Names and Numbers (ICANN) \[ICANN +2016\], based on guidelines set forth in \[RFC 7020\]. The role of the +nonprofit ICANN organization \[NTIA 1998\] is not only to allocate IP +addresses, but also to manage the DNS root servers. It also has the very +contentious job of assigning domain names and resolving domain name +disputes. The ICANN allocates addresses to regional Internet registries +(for example, ARIN, RIPE, APNIC, and LACNIC, which together form the +Address Supporting Organization of ICANN \[ASO-ICANN 2016\]), and handle +the allocation/management of addresses within their regions. Obtaining a +Host Address: The Dynamic Host Configuration Protocol Once an +organization has obtained a block of addresses, it can assign individual +IP addresses to the host and router interfaces in its organization. A +system administrator will typically manually configure the IP addresses +into the router (often remotely, with a network management tool). Host +addresses can also be configured manually, but typically this is done +using the Dynamic Host Configuration Protocol (DHCP) \[RFC 2131\]. DHCP +allows a host to obtain (be allocated) an IP address automatically. A +network administrator can configure DHCP so that a given host receives +the same IP address each time it connects to the network, or a host may +be assigned a temporary IP address that will be different each time the +host connects to the network. In addition to host IP address assignment, +DHCP also allows a host to learn additional information, such as its +subnet mask, the address of its first-hop router (often called the +default gateway), and the address of its local DNS server. Because of +DHCP's ability to automate the network-related aspects of connecting a +host into a network, it is often referred to as a plug-and-play or +zeroconf (zero-configuration) protocol. This capability makes it very +attractive to the network administrator who would otherwise have to +perform these tasks manually! DHCP is also enjoying widespread use in +residential Internet access networks, enterprise + + networks, and in wireless LANs, where hosts join and leave the network +frequently. Consider, for example, the student who carries a laptop from +a dormitory room to a library to a classroom. It is likely that in each +location, the student will be connecting into a new subnet and hence +will need a new IP address at each location. DHCP is ideally suited to +this situation, as there are many users coming and going, and addresses +are needed for only a limited amount of time. The value of DHCP's +plug-and-play capability is clear, since it's unimaginable that a system +administrator would be able to reconfigure laptops at each location, and +few students (except those taking a computer networking class!) would +have the expertise to configure their laptops manually. DHCP is a +client-server protocol. A client is typically a newly arriving host +wanting to obtain network configuration information, including an IP +address for itself. In the simplest case, each subnet (in the addressing +sense of Figure 4.20) will have a DHCP server. If no server is present +on the subnet, a DHCP relay agent (typically a router) that knows the +address of a DHCP server for that network is needed. Figure 4.23 shows a +DHCP server attached to subnet 223.1.2/24, with the router serving as +the relay agent for arriving clients attached to subnets 223.1.1/24 and +223.1.3/24. In our discussion below, we'll assume that a DHCP server is +available on the subnet. For a newly arriving host, the DHCP protocol is +a four-step process, as shown in Figure 4.24 for the network setting +shown in Figure 4.23. In this figure, yiaddr (as in "your Internet +address") indicates the address being allocated to the newly arriving +client. The four steps are: + +Figure 4.23 DHCP client and server + + DHCP server discovery. The first task of a newly arriving host is to +find a DHCP server with which to interact. This is done using a DHCP +discover message, which a client sends within a UDP packet to port 67. +The UDP packet is encapsulated in an IP datagram. But to whom should +this datagram be sent? The host doesn't even know the IP address of the +network to which it is attaching, much less the address of a DHCP server +for this network. Given this, the DHCP client creates an IP datagram +containing its DHCP discover message along with the broadcast +destination IP address of 255.255.255.255 and a "this host" source IP +address of 0.0.0.0. The DHCP client passes the IP datagram to the link +layer, which then broadcasts this frame to all nodes attached to the +subnet (we will cover the details of link-layer broadcasting in Section +6.4). DHCP server offer(s). A DHCP server receiving a DHCP discover +message responds to the client with a DHCP offer message that is +broadcast to all nodes on the subnet, again using the IP broadcast +address of 255.255.255.255. (You might want to think about why this +server reply must also be broadcast). Since several DHCP servers can be +present on the subnet, the client may find itself in the enviable +position of being able to choose from among several offers. Each + + Figure 4.24 DHCP client-server interaction + +server offer message contains the transaction ID of the received +discover message, the proposed IP address for the client, the network +mask, and an IP address lease time---the amount of time for which the IP +address will be valid. It is common for the server to set the lease time +to several hours or days \[Droms 2002\]. DHCP request. The newly +arriving client will choose from among one or more server offers and +respond to its selected offer with a DHCP request message, echoing back +the configuration parameters. DHCP ACK. The server responds to the DHCP +request message with a DHCP ACK message, confirming the requested +parameters. Once the client receives the DHCP ACK, the interaction is +complete and the client can use the DHCPallocated IP address for the +lease duration. Since a client may want to use its address beyond the + + lease's expiration, DHCP also provides a mechanism that allows a client +to renew its lease on an IP address. From a mobility aspect, DHCP does +have one very significant shortcoming. Since a new IP address is +obtained from DHCP each time a node connects to a new subnet, a TCP +connection to a remote application cannot be maintained as a mobile node +moves between subnets. In Chapter 6, we will examine mobile IP---an +extension to the IP infrastructure that allows a mobile node to use a +single permanent address as it moves between subnets. Additional details +about DHCP can be found in \[Droms 2002\] and \[dhc 2016\]. An open +source reference implementation of DHCP is available from the Internet +Systems Consortium \[ISC 2016\]. + +4.3.4 Network Address Translation (NAT) Given our discussion about +Internet addresses and the IPv4 datagram format, we're now well aware +that every IP-capable device needs an IP address. With the proliferation +of small office, home office (SOHO) subnets, this would seem to imply +that whenever a SOHO wants to install a LAN to connect multiple +machines, a range of addresses would need to be allocated by the ISP to +cover all of the SOHO's IP devices (including phones, tablets, gaming +devices, IP TVs, printers and more). If the subnet grew bigger, a larger +block of addresses would have to be allocated. But what if the ISP had +already allocated the contiguous portions of the SOHO network's current +address range? And what typical homeowner wants (or should need) to know +how to manage IP addresses in the first place? Fortunately, there is a +simpler approach to address allocation that has found increasingly +widespread use in such scenarios: network address translation (NAT) +\[RFC 2663; RFC 3022; Huston 2004, Zhang 2007; Cisco NAT 2016\]. Figure +4.25 shows the operation of a NAT-enabled router. The NAT-enabled +router, residing in the home, has an interface that is part of the home +network on the right of Figure 4.25. Addressing within the home network +is exactly as we have seen above---all four interfaces in the home +network have the same subnet address of 10.0.0/24. The address space +10.0.0.0/8 is one of three portions of the IP address space that is +reserved in \[RFC 1918\] for a private network or a realm with private +addresses, such as the home network in Figure 4.25. A realm with private +addresses refers to a network whose addresses only have meaning to +devices within that network. To see why this is important, consider the +fact that there are hundreds of thousands of home networks, many using +the same address space, 10.0.0.0/24. Devices within a given home network +can send packets to each other using 10.0.0.0/24 addressing. However, +packets forwarded beyond the home network into the larger global +Internet clearly cannot use these addresses (as either a source or a +destination address) because there are hundreds of thousands of networks +using this block of addresses. That is, the 10.0.0.0/24 addresses can +only have meaning within the + + Figure 4.25 Network address translation + +given home network. But if private addresses only have meaning within a +given network, how is addressing handled when packets are sent to or +received from the global Internet, where addresses are necessarily +unique? The answer lies in understanding NAT. The NAT-enabled router +does not look like a router to the outside world. Instead the NAT router +behaves to the outside world as a single device with a single IP +address. In Figure 4.25, all traffic leaving the home router for the +larger Internet has a source IP address of 138.76.29.7, and all traffic +entering the home router must have a destination address of 138.76.29.7. +In essence, the NAT-enabled router is hiding the details of the home +network from the outside world. (As an aside, you might wonder where the +home network computers get their addresses and where the router gets its +single IP address. Often, the answer is the same---DHCP! The router gets +its address from the ISP's DHCP server, and the router runs a DHCP +server to provide addresses to computers within the +NAT-DHCP-routercontrolled home network's address space.) If all +datagrams arriving at the NAT router from the WAN have the same +destination IP address (specifically, that of the WAN-side interface of +the NAT router), then how does the router know the internal host to +which it should forward a given datagram? The trick is to use a NAT +translation table at the NAT router, and to include port numbers as well +as IP addresses in the table entries. Consider the example in Figure +4.25. Suppose a user sitting in a home network behind host 10.0.0.1 +requests a Web page on some Web server (port 80) with IP address +128.119.40.186. The host 10.0.0.1 assigns the (arbitrary) source port +number 3345 and sends the datagram into the LAN. The NAT router receives +the datagram, generates a new source port number 5001 for the datagram, +replaces the + + source IP address with its WAN-side IP address 138.76.29.7, and replaces +the original source port number 3345 with the new source port number +5001. When generating a new source port number, the NAT router can +select any source port number that is not currently in the NAT +translation table. (Note that because a port number field is 16 bits +long, the NAT protocol can support over 60,000 simultaneous connections +with a single WAN-side IP address for the router!) NAT in the router +also adds an entry to its NAT translation table. The Web server, +blissfully unaware that the arriving datagram containing the HTTP +request has been manipulated by the NAT router, responds with a datagram +whose destination address is the IP address of the NAT router, and whose +destination port number is 5001. When this datagram arrives at the NAT +router, the router indexes the NAT translation table using the +destination IP address and destination port number to obtain the +appropriate IP address (10.0.0.1) and destination port number (3345) for +the browser in the home network. The router then rewrites the datagram's +destination address and destination port number, and forwards the +datagram into the home network. NAT has enjoyed widespread deployment in +recent years. But NAT is not without detractors. First, one might argue +that, port numbers are meant to be used for addressing processes, not +for addressing hosts. This violation can indeed cause problems for +servers running on the home network, since, as we have seen in Chapter +2, server processes wait for incoming requests at well-known port +numbers and peers in a P2P protocol need to accept incoming connections +when acting as servers. Technical solutions to these problems include +NAT traversal tools \[RFC 5389\] and Universal Plug and Play (UPnP), a +protocol that allows a host to discover and configure a nearby NAT +\[UPnP Forum 2016\]. More "philosophical" arguments have also been +raised against NAT by architectural purists. Here, the concern is that +routers are meant to be layer 3 (i.e., network-layer) devices, and +should process packets only up to the network layer. NAT violates this +principle that hosts should be talking directly with each other, without +interfering nodes modifying IP addresses, much less port numbers. But +like it or not, NAT has not become an important component of the +Internet, as have other so-called middleboxes \[Sekar 2011\] that +operate at the network layer but have functions that are quite different +from routers. Middleboxes do not perform traditional datagram +forwarding, but instead perform functions such as NAT, load balancing of +traffic flows, traffic firewalling (see accompanying sidebar), and more. +The generalized forwarding paradigm that we'll study shortly in Section +4.4 allows a number of these middlebox functions, as well as traditional +router forwarding, to be accomplished in a common, integrated manner. + +FOCUS ON SECURITY INSPECTING DATAGRAMS: FIREWALLS AND INTRUSION +DETECTION SYSTEMS Suppose you are assigned the task of administering a +home, departmental, university, or corporate network. Attackers, knowing +the IP address range of your network, can easily send IP datagrams to +addresses in your range. These datagrams can do all kinds of devious +things, including mapping your network with ping sweeps and port scans, +crashing vulnerable hosts with + + malformed packets, scanning for open TCP/UDP ports on servers in your +network, and infecting hosts by including malware in the packets. As the +network administrator, what are you going to do about all those bad guys +out there, each capable of sending malicious packets into your network? +Two popular defense mechanisms to malicious packet attacks are firewalls +and intrusion detection systems (IDSs). As a network administrator, you +may first try installing a firewall between your network and the +Internet. (Most access routers today have firewall capability.) +Firewalls inspect the datagram and segment header fields, denying +suspicious datagrams entry into the internal network. For example, a +firewall may be configured to block all ICMP echo request packets (see +Section 5.6), thereby preventing an attacker from doing a traditional +port scan across your IP address range. Firewalls can also block packets +based on source and destination IP addresses and port numbers. +Additionally, firewalls can be configured to track TCP connections, +granting entry only to datagrams that belong to approved connections. +Additional protection can be provided with an IDS. An IDS, typically +situated at the network boundary, performs "deep packet inspection," +examining not only header fields but also the payloads in the datagram +(including application-layer data). An IDS has a database of packet +signatures that are known to be part of attacks. This database is +automatically updated as new attacks are discovered. As packets pass +through the IDS, the IDS attempts to match header fields and payloads to +the signatures in its signature database. If such a match is found, an +alert is created. An intrusion prevention system (IPS) is similar to an +IDS, except that it actually blocks packets in addition to creating +alerts. In Chapter 8, we'll explore firewalls and IDSs in more detail. +Can firewalls and IDSs fully shield your network from all attacks? The +answer is clearly no, as attackers continually find new attacks for +which signatures are not yet available. But firewalls and traditional +signature-based IDSs are useful in protecting your network from known +attacks. + +4.3.5 IPv6 In the early 1990s, the Internet Engineering Task Force began +an effort to develop a successor to the IPv4 protocol. A prime +motivation for this effort was the realization that the 32-bit IPv4 +address space was beginning to be used up, with new subnets and IP nodes +being attached to the Internet (and being allocated unique IP addresses) +at a breathtaking rate. To respond to this need for a large IP address +space, a new IP protocol, IPv6, was developed. The designers of IPv6 +also took this opportunity to tweak and augment other aspects of IPv4, +based on the accumulated operational experience with IPv4. The point in +time when IPv4 addresses would be completely allocated (and hence no new +networks + + could attach to the Internet) was the subject of considerable debate. +The estimates of the two leaders of the IETF's Address Lifetime +Expectations working group were that addresses would become exhausted in +2008 and 2018, respectively \[Solensky 1996\]. In February 2011, IANA +allocated out the last remaining pool of unassigned IPv4 addresses to a +regional registry. While these registries still have available IPv4 +addresses within their pool, once these addresses are exhausted, there +are no more available address blocks that can be allocated from a +central pool \[Huston 2011a\]. A recent survey of IPv4 address-space +exhaustion, and the steps taken to prolong the life of the address space +is \[Richter 2015\]. Although the mid-1990s estimates of IPv4 address +depletion suggested that a considerable amount of time might be left +until the IPv4 address space was exhausted, it was realized that +considerable time would be needed to deploy a new technology on such an +extensive scale, and so the process to develop IP version 6 (IPv6) \[RFC +2460\] was begun \[RFC 1752\]. (An often-asked question is what happened +to IPv5? It was initially envisioned that the ST-2 protocol would become +IPv5, but ST-2 was later dropped.) An excellent source of information +about IPv6 is \[Huitema 1998\]. IPv6 Datagram Format The format of the +IPv6 datagram is shown in Figure 4.26. The most important changes +introduced in IPv6 are evident in the datagram format: Expanded +addressing capabilities. IPv6 increases the size of the IP address from +32 to 128 bits. This ensures that the world won't run out of IP +addresses. Now, every grain of sand on the planet can be IP-addressable. +In addition to unicast and multicast addresses, IPv6 has introduced a +new type of address, called an anycast address, that allows a datagram +to be delivered to any one of a group of hosts. (This feature could be +used, for example, to send an HTTP GET to the nearest of a number of +mirror sites that contain a given document.) A streamlined 40-byte +header. As discussed below, a number of IPv4 fields have been dropped or +made optional. The resulting 40-byte fixed-length header allows for +faster processing of the IP datagram by a router. A new encoding of +options allows for more flexible options processing. Flow labeling. IPv6 +has an elusive definition of a flow. RFC 2460 states that this allows +"labeling of packets belonging to particular flows for which the sender + + Figure 4.26 IPv6 datagram format + +requests special handling, such as a non-default quality of service or +real-time service." For example, audio and video transmission might +likely be treated as a flow. On the other hand, the more traditional +applications, such as file transfer and e-mail, might not be treated as +flows. It is possible that the traffic carried by a high-priority user +(for example, someone paying for better service for their traffic) might +also be treated as a flow. What is clear, however, is that the designers +of IPv6 foresaw the eventual need to be able to differentiate among the +flows, even if the exact meaning of a flow had yet to be determined. As +noted above, a comparison of Figure 4.26 with Figure 4.16 reveals the +simpler, more streamlined structure of the IPv6 datagram. The following +fields are defined in IPv6: Version. This 4-bit field identifies the IP +version number. Not surprisingly, IPv6 carries a value of 6 in this +field. Note that putting a 4 in this field does not create a valid IPv4 +datagram. (If it did, life would be a lot simpler---see the discussion +below regarding the transition from IPv4 to IPv6.) Traffic class. The +8-bit traffic class field, like the TOS field in IPv4, can be used to +give priority to certain datagrams within a flow, or it can be used to +give priority to datagrams from certain applications (for example, +voice-over-IP) over datagrams from other applications (for example, SMTP +e-mail). Flow label. As discussed above, this 20-bit field is used to +identify a flow of datagrams. Payload length. This 16-bit value is +treated as an unsigned integer giving the number of bytes in the IPv6 +datagram following the fixed-length, 40-byte datagram header. Next +header. This field identifies the protocol to which the contents (data +field) of this datagram will be delivered (for example, to TCP or UDP). +The field uses the same values as the protocol field in the IPv4 header. +Hop limit. The contents of this field are decremented by one by each +router that forwards the datagram. If the hop limit count reaches zero, +the datagram is discarded. + + Source and destination addresses. The various formats of the IPv6 +128-bit address are described in RFC 4291. Data. This is the payload +portion of the IPv6 datagram. When the datagram reaches its destination, +the payload will be removed from the IP datagram and passed on to the +protocol specified in the next header field. The discussion above +identified the purpose of the fields that are included in the IPv6 +datagram. Comparing the IPv6 datagram format in Figure 4.26 with the +IPv4 datagram format that we saw in Figure 4.16, we notice that several +fields appearing in the IPv4 datagram are no longer present in the IPv6 +datagram: Fragmentation/reassembly. IPv6 does not allow for +fragmentation and reassembly at intermediate routers; these operations +can be performed only by the source and destination. If an IPv6 datagram +received by a router is too large to be forwarded over the outgoing +link, the router simply drops the datagram and sends a "Packet Too Big" +ICMP error message (see Section 5.6) back to the sender. The sender can +then resend the data, using a smaller IP datagram size. Fragmentation +and reassembly is a time-consuming operation; removing this +functionality from the routers and placing it squarely in the end +systems considerably speeds up IP forwarding within the network. Header +checksum. Because the transport-layer (for example, TCP and UDP) and +link-layer (for example, Ethernet) protocols in the Internet layers +perform checksumming, the designers of IP probably felt that this +functionality was sufficiently redundant in the network layer that it +could be removed. Once again, fast processing of IP packets was a +central concern. Recall from our discussion of IPv4 in Section 4.3.1 +that since the IPv4 header contains a TTL field (similar to the hop +limit field in IPv6), the IPv4 header checksum needed to be recomputed +at every router. As with fragmentation and reassembly, this too was a +costly operation in IPv4. Options. An options field is no longer a part +of the standard IP header. However, it has not gone away. Instead, the +options field is one of the possible next headers pointed to from within +the IPv6 header. That is, just as TCP or UDP protocol headers can be the +next header within an IP packet, so too can an options field. The +removal of the options field results in a fixed-length, 40-byte IP +header. Transitioning from IPv4 to IPv6 Now that we have seen the +technical details of IPv6, let us consider a very practical matter: How +will the public Internet, which is based on IPv4, be transitioned to +IPv6? The problem is that while new IPv6capable systems can be made +backward-compatible, that is, can send, route, and receive IPv4 +datagrams, already deployed IPv4-capable systems are not capable of +handling IPv6 datagrams. Several options are possible \[Huston 2011b, +RFC 4213\]. One option would be to declare a flag day---a given time and +date when all Internet machines would be turned off and upgraded from +IPv4 to IPv6. The last major technology transition (from using NCP to + + using TCP for reliable transport service) occurred almost 35 years ago. +Even back then \[RFC 801\], when the Internet was tiny and still being +administered by a small number of "wizards," it was realized that such a +flag day was not possible. A flag day involving billions of devices is +even more unthinkable today. The approach to IPv4-to-IPv6 transition +that has been most widely adopted in practice involves tunneling \[RFC +4213\]. The basic idea behind tunneling---a key concept with +applications in many other scenarios beyond IPv4-to-IPv6 transition, +including wide use in the all-IP cellular networks that we'll cover in +Chapter 7---is the following. Suppose two IPv6 nodes (in this example, B +and E in Figure 4.27) want to interoperate using IPv6 datagrams but are +connected to each other by intervening IPv4 routers. We refer to the +intervening set of IPv4 routers between two IPv6 routers as a tunnel, as +illustrated in Figure 4.27. With tunneling, the IPv6 node on the sending +side of the tunnel (in this example, B) takes the entire IPv6 datagram +and puts it in the data (payload) field of an IPv4 datagram. This IPv4 +datagram is then addressed to the IPv6 node on the receiving side of the +tunnel (in this example, E) and sent to the first node in the tunnel (in +this example, C). The intervening IPv4 routers in the tunnel route this +IPv4 datagram among themselves, just as they would any other datagram, +blissfully unaware that the IPv4 datagram itself contains a complete +IPv6 datagram. The IPv6 node on the receiving side of the tunnel +eventually receives the IPv4 datagram (it is the destination of the IPv4 +datagram!), determines that the IPv4 datagram contains an IPv6 datagram +(by observing that the protocol number field in the IPv4 datagram is 41 +\[RFC 4213\], indicating that the IPv4 payload is a IPv6 datagram), +extracts the IPv6 datagram, and then routes the IPv6 datagram exactly as +it would if it had received the IPv6 datagram from a directly connected +IPv6 neighbor. We end this section by noting that while the adoption of +IPv6 was initially slow to take off \[Lawton 2001; Huston 2008b\], +momentum has been building. NIST \[NIST IPv6 2015\] reports that more +than a third of US government second-level domains are IPv6-enabled. On +the client side, Google reports that only about 8 percent of the clients +accessing Google services do so via IPv6 \[Google IPv6 2015\]. But other +recent measurements \[Czyz 2014\] indicate that IPv6 adoption is +accelerating. The proliferation of devices such as IP-enabled phones and +other portable devices + + Figure 4.27 Tunneling + +provides an additional push for more widespread deployment of IPv6. +Europe's Third Generation Partnership Program \[3GPP 2016\] has +specified IPv6 as the standard addressing scheme for mobile multimedia. +One important lesson that we can learn from the IPv6 experience is that +it is enormously difficult to change network-layer protocols. Since the +early 1990s, numerous new network-layer protocols have been trumpeted as +the next major revolution for the Internet, but most of these protocols +have had limited penetration to date. These protocols include IPv6, +multicast protocols, and resource reservation protocols; a discussion of +these latter two protocols can be found in the online supplement to this +text. Indeed, introducing new protocols into the network layer is like +replacing the foundation of a house---it is difficult to do without +tearing the whole house down or at least temporarily relocating the +house's residents. On the other hand, the Internet has witnessed rapid +deployment of new protocols at the application layer. The classic +examples, of course, are the Web, instant messaging, streaming media, +distributed games, and various forms of social media. Introducing new +application-layer protocols is like adding a new layer of paint to a +house---it is relatively easy to do, and if you choose an attractive +color, others in the neighborhood will copy you. In summary, in the +future we can certainly expect to see changes in the Internet's network +layer, but these changes will likely occur on a time scale that is much +slower than the changes that will occur at the application layer. + + 4.4 Generalized Forwarding and SDN In Section 4.2.1, we noted that an +Internet router's forwarding decision has traditionally been based +solely on a packet's destination address. In the previous section, +however, we've also seen that there has been a proliferation of +middleboxes that perform many layer-3 functions. NAT boxes rewrite +header IP addresses and port numbers; firewalls block traffic based on +header-field values or redirect packets for additional processing, such +as deep packet inspection (DPI). Load-balancers forward packets +requesting a given service (e.g., an HTTP request) to one of a set of a +set of servers that provide that service. \[RFC 3234\] lists a number of +common middlebox functions. This proliferation of middleboxes, layer-2 +switches, and layer-3 routers \[Qazi 2013\]---each with its own +specialized hardware, software and management interfaces---has +undoubtedly resulted in costly headaches for many network operators. +However, recent advances in software-defined networking have promised, +and are now delivering, a unified approach towards providing many of +these network-layer functions, and certain link-layer functions as well, +in a modern, elegant, and integrated manner. Recall that Section 4.2.1 +characterized destination-based forwarding as the two steps of looking +up a destination IP address ("match"), then sending the packet into the +switching fabric to the specified output port ("action"). Let's now +consider a significantly more general "match-plus-action" paradigm, +where the "match" can be made over multiple header fields associated +with different protocols at different layers in the protocol stack. The +"action" can include forwarding the packet to one or more output ports +(as in destination-based forwarding), load balancing packets across +multiple outgoing interfaces that lead to a service (as in load +balancing), rewriting header values (as in NAT), purposefully +blocking/dropping a packet (as in a firewall), sending a packet to a +special server for further processing and action (as in DPI), and more. +In generalized forwarding, a match-plus-action table generalizes the +notion of the destination-based forwarding table that we encountered in +Section 4.2.1. Because forwarding decisions may be made using +network-layer and/or link-layer source and destination addresses, the +forwarding devices shown in Figure 4.28 are more accurately described as +"packet switches" rather than layer 3 "routers" or layer 2 "switches." +Thus, in the remainder of this section, and in Section 5.5, we'll refer + + Figure 4.28 Generalized forwarding: Each packet switch contains a +match-plus-action table that is computed and distributed by a remote +controller + +to these devices as packet switches, adopting the terminology that is +gaining widespread adoption in SDN literature. Figure 4.28 shows a +match-plus-action table in each packet switch, with the table being +computed, installed, and updated by a remote controller. We note that +while it is possible for the control components at the individual packet +switch to interact with each other (e.g., in a manner similar to that in +Figure 4.2), in practice generalized match-plus-action capabilities are +implemented via a remote controller that computes, installs, and updates +these tables. You might take a minute to compare Figures 4.2, 4.3 and +4.28---what similarities and differences do you notice between +destination-based forwarding shown in Figure 4.2 and 4.3, and +generalized forwarding shown in Figure 4.28? Our following discussion of +generalized forwarding will be based on OpenFlow \[McKeown 2008, +OpenFlow 2009, Casado 2014, Tourrilhes 2014\]---a highly visible and +successful standard that has pioneered the notion of the +match-plus-action forwarding abstraction and controllers, as well as the +SDN revolution more generally \[Feamster 2013\]. We'll primarily +consider OpenFlow 1.0, which introduced key SDN abstractions and +functionality in a particularly clear and concise manner. Later versions +of + + OpenFlow introduced additional capabilities as a result of experience +gained through implementation and use; current and earlier versions of +the OpenFlow standard can be found at \[ONF 2016\]. Each entry in the +match-plus-action forwarding table, known as a flow table in OpenFlow, +includes: A set of header field values to which an incoming packet will +be matched. As in the case of destination-based forwarding, +hardware-based matching is most rapidly performed in TCAM memory, with +more than a million destination address entries being possible +\[Bosshart 2013\]. A packet that matches no flow table entry can be +dropped or sent to the remote controller for more processing. In +practice, a flow table may be implemented by multiple flow tables for +performance or cost reasons \[Bosshart 2013\], but we'll focus here on +the abstraction of a single flow table. A set of counters that are +updated as packets are matched to flow table entries. These counters +might include the number of packets that have been matched by that table +entry, and the time since the table entry was last updated. A set of +actions to be taken when a packet matches a flow table entry. These +actions might be to forward the packet to a given output port, to drop +the packet, makes copies of the packet and sent them to multiple output +ports, and/or to rewrite selected header fields. We'll explore matching +and actions in more detail in Sections 4.4.1 and 4.4.2, respectively. +We'll then study how the network-wide collection of per-packet switch +matching rules can be used to implement a wide range of functions +including routing, layer-2 switching, firewalling, load-balancing, +virtual networks, and more in Section 4.4.3. In closing, we note that +the flow table is essentially an API, the abstraction through which an +individual packet switch's behavior can be programmed; we'll see in +Section 4.4.3 that network-wide behaviors can similarly be programmed by +appropriately programming/configuring these tables in a collection of +network packet switches \[Casado 2014\]. + +4.4.1 Match Figure 4.29 shows the eleven packet-header fields and the +incoming port ID that can be matched in an OpenFlow 1.0 +match-plus-action rule. Recall from + +Figure 4.29 Packet matching fields, OpenFlow 1.0 flow table + + Section 1.5.2 that a link-layer (layer 2) frame arriving to a packet +switch will contain a network-layer (layer 3) datagram as its payload, +which in turn will typically contain a transport-layer (layer 4) +segment. The first observation we make is that OpenFlow's match +abstraction allows for a match to be made on selected fields from three +layers of protocol headers (thus rather brazenly defying the layering +principle we studied in Section 1.5). Since we've not yet covered the +link layer, suffice it to say that the source and destination MAC +addresses shown in Figure 4.29 are the link-layer addresses associated +with the frame's sending and receiving interfaces; by forwarding on the +basis of Ethernet addresses rather than IP addresses, we can see that an +OpenFlow-enabled device can equally perform as a router (layer-3 device) +forwarding datagrams as well as a switch (layer-2 device) forwarding +frames. The Ethernet type field corresponds to the upper layer protocol +(e.g., IP) to which the frame's payload will be demultiplexed, and the +VLAN fields are concerned with so-called virtual local area networks +that we'll study in Chapter 6. The set of twelve values that can be +matched in the OpenFlow 1.0 specification has grown to 41 values in more +recent OpenFlow specifications \[Bosshart 2014\]. The ingress port +refers to the input port at the packet switch on which a packet is +received. The packet's IP source address, IP destination address, IP +protocol field, and IP type of service fields were discussed earlier in +Section 4.3.1. The transport-layer source and destination port number +fields can also be matched. Flow table entries may also have wildcards. +For example, an IP address of 128.119.*.* in a flow table will match the +corresponding address field of any datagram that has 128.119 as the +first 16 bits of its address. Each flow table entry also has an +associated priority. If a packet matches multiple flow table entries, +the selected match and corresponding action will be that of the highest +priority entry with which the packet matches. Lastly, we observe that +not all fields in an IP header can be matched. For example OpenFlow does +not allow matching on the basis of TTL field or datagram length field. +Why are some fields allowed for matching, while others are not? +Undoubtedly, the answer has to do with the tradeoff between +functionality and complexity. The "art" in choosing an abstraction is to +provide for enough functionality to accomplish a task (in this case to +implement, configure, and manage a wide range of network-layer functions +that had previously been implemented through an assortment of +network-layer devices), without over-burdening the abstraction with so +much detail and generality that it becomes bloated and unusable. Butler +Lampson has famously noted \[Lampson 1983\]: Do one thing at a time, and +do it well. An interface should capture the minimum essentials of an +abstraction. Don't generalize; generalizations are generally wrong. +Given OpenFlow's success, one can surmise that its designers indeed +chose their abstraction well. Additional details of OpenFlow matching +can be found in \[OpenFlow 2009, ONF 2016\]. + + 4.4.2 Action As shown in Figure 4.28, each flow table entry has a list +of zero or more actions that determine the processing that is to be +applied to a packet that matches a flow table entry. If there are +multiple actions, they are performed in the order specified in the list. +Among the most important possible actions are: Forwarding. An incoming +packet may be forwarded to a particular physical output port, broadcast +over all ports (except the port on which it arrived) or multicast over a +selected set of ports. The packet may be encapsulated and sent to the +remote controller for this device. That controller then may (or may not) +take some action on that packet, including installing new flow table +entries, and may return the packet to the device for forwarding under +the updated set of flow table rules. Dropping. A flow table entry with +no action indicates that a matched packet should be dropped. +Modify-field. The values in ten packet header fields (all layer 2, 3, +and 4 fields shown in Figure 4.29 except the IP Protocol field) may be +re-written before the packet is forwarded to the chosen output port. + +4.4.3 OpenFlow Examples of Match-plus-action in Action Having now +considered both the match and action components of generalized +forwarding, let's put these ideas together in the context of the sample +network shown in Figure 4.30. The network has 6 hosts (h1, h2, h3, h4, +h5 and h6) and three packet switches (s1, s2 and s3), each with four +local interfaces (numbered 1 through 4). We'll consider a number of +network-wide behaviors that we'd like to implement, and the flow table +entries in s1, s2 and s3 needed to implement this behavior. + + Figure 4.30 OpenFlow match-plus-action network with three packet +switches, 6 hosts, and an OpenFlow controller + +A First Example: Simple Forwarding As a very simple example, suppose +that the desired forwarding behavior is that packets from h5 or h6 +destined to h3 or h4 are to be forwarded from s3 to s1, and then from s1 +to s2 (thus completely avoiding the use of the link between s3 and s2). +The flow table entry in s1 would be: + +s1 Flow Table (Example 1) Match + +Action + +Ingress Port = 1 ; IP Src = 10.3.*.* ; IP Dst = 10.2.*.* + +Forward(4) + +... + +... + +Of course, we'll also need a flow table entry in s3 so that datagrams +sent from h5 or h6 are forwarded to s1 over outgoing interface 3: + +s3 Flow Table (Example 1) Match + +Action + +IP Src = 10.3.*.* ; IP Dst = 10.2.*.* + +Forward(3) + +... + +... + +Lastly, we'll also need a flow table entry in s2 to complete this first +example, so that datagrams arriving from s1 are forwarded to their +destination, either host h3 or h4: + +s2 Flow Table (Example 1) Match + +Action + +Ingress port = 2 ; IP Dst = 10.2.0.3 + +Forward(3) + +Ingress port = 2 ; IP Dst = 10.2.0.4 + +Forward(4) + + ... + +... + +A Second Example: Load Balancing As a second example, let's consider a +load-balancing scenario, where datagrams from h3 destined to 10.1.*.* +are to be forwarded over the direct link between s2 and s1, while +datagrams from h4 destined to 10.1.*.* are to be forwarded over the link +between s2 and s3 (and then from s3 to s1). Note that this behavior +couldn't be achieved with IP's destination-based forwarding. In this +case, the flow table in s2 would be: + +s2 Flow Table (Example 2) Match + +Action + +Ingress port = 3; IP Dst = 10.1.*.* + +Forward(2) + +Ingress port = 4; IP Dst = 10.1.*.* + +Forward(1) + +... + +... + +Flow table entries are also needed at s1 to forward the datagrams +received from s2 to either h1 or h2; and flow table entries are needed +at s3 to forward datagrams received on interface 4 from s2 over +interface 3 towards s1. See if you can figure out these flow table +entries at s1 and s3. A Third Example: Firewalling As a third example, +let's consider a firewall scenario in which s2 wants only to receive (on +any of its interfaces) traffic sent from hosts attached to s3. + +s2 Flow Table (Example 3) Match + +Action + +IP Src = 10.3.*.* IP Dst = 10.2.0.3 + +Forward(3) + +IP Src = 10.3.*.* IP Dst = 10.2.0.4 + +Forward(4) + +... + +... + + If there were no other entries in s2's flow table, then only traffic +from 10.3.*.* would be forwarded to the hosts attached to s2. Although +we've only considered a few basic scenarios here, the versatility and +advantages of generalized forwarding are hopefully apparent. In homework +problems, we'll explore how flow tables can be used to create many +different logical behaviors, including virtual networks---two or more +logically separate networks (each with their own independent and +distinct forwarding behavior)---that use the same physical set of packet +switches and links. In Section 5.5, we'll return to flow tables when we +study the SDN controllers that compute and distribute the flow tables, +and the protocol used for communicating between a packet switch and its +controller. + + 4.5 Summary In this chapter we've covered the data plane functions of +the network layer---the per-router functions that determine how packets +arriving on one of a router's input links are forwarded to one of that +router's output links. We began by taking a detailed look at the +internal operations of a router, studying input and output port +functionality and destination-based forwarding, a router's internal +switching mechanism, packet queue management and more. We covered both +traditional IP forwarding (where forwarding is based on a datagram's +destination address) and generalized forwarding (where forwarding and +other functions may be performed using values in several different +fields in the datagram's header) and seen the versatility of the latter +approach. We also studied the IPv4 and IPv6 protocols in detail, and +Internet addressing, which we found to be much deeper, subtler, and more +interesting than we might have expected. With our newfound understanding +of the network-layer's data plane, we're now ready to dive into the +network layer's control plane in Chapter 5! + + Homework Problems and Questions + +Chapter 4 Review Questions + +SECTION 4.1 R1. Let's review some of the terminology used in this +textbook. Recall that the name of a transport-layer packet is segment +and that the name of a link-layer packet is frame. What is the name of a +network-layer packet? Recall that both routers and link-layer switches +are called packet switches. What is the fundamental difference between a +router and link-layer switch? R2. We noted that network layer +functionality can be broadly divided into data plane functionality and +control plane functionality. What are the main functions of the data +plane? Of the control plane? R3. We made a distinction between the +forwarding function and the routing function performed in the network +layer. What are the key differences between routing and forwarding? R4. +What is the role of the forwarding table within a router? R5. We said +that a network layer's service model "defines the characteristics of +end-to-end transport of packets between sending and receiving hosts." +What is the service model of the Internet's network layer? What +guarantees are made by the Internet's service model regarding the +host-to-host delivery of datagrams? + +SECTION 4.2 R6. In Section 4.2 , we saw that a router typically consists +of input ports, output ports, a switching fabric and a routing +processor. Which of these are implemented in hardware and which are +implemented in software? Why? Returning to the notion of the network +layer's data plane and control plane, which are implemented in hardware +and which are implemented in software? Why? R7. Discuss why each input +port in a high-speed router stores a shadow copy of the forwarding +table. R8. What is meant by destination-based forwarding? How does this +differ from generalized forwarding (assuming you've read Section 4.4 , +which of the two approaches are adopted by Software-Defined Networking)? +R9. Suppose that an arriving packet matches two or more entries in a +router's forwarding table. With traditional destination-based +forwarding, what rule does a router apply to determine which + + of these rules should be applied to determine the output port to which +the arriving packet should be switched? R10. Three types of switching +fabrics are discussed in Section 4.2 . List and briefly describe each +type. Which, if any, can send multiple packets across the fabric in +parallel? R11. Describe how packet loss can occur at input ports. +Describe how packet loss at input ports can be eliminated (without using +infinite buffers). R12. Describe how packet loss can occur at output +ports. Can this loss be prevented by increasing the switch fabric speed? +R13. What is HOL blocking? Does it occur in input ports or output ports? +R14. In Section 4.2 , we studied FIFO, Priority, Round Robin (RR), and +Weighted Fair Queueing (WFQ) packet scheduling disciplines? Which of +these queueing disciplines ensure that all packets depart in the order +in which they arrived? R15. Give an example showing why a network +operator might want one class of packets to be given priority over +another class of packets. R16. What is an essential different between RR +and WFQ packet scheduling? Is there a case (Hint: Consider the WFQ +weights) where RR and WFQ will behave exactly the same? + +SECTION 4.3 R17. Suppose Host A sends Host B a TCP segment encapsulated +in an IP datagram. When Host B receives the datagram, how does the +network layer in Host B know it should pass the segment (that is, the +payload of the datagram) to TCP rather than to UDP or to some other +upper-layer protocol? R18. What field in the IP header can be used to +ensure that a packet is forwarded through no more than N routers? R19. +Recall that we saw the Internet checksum being used in both +transport-layer segment (in UDP and TCP headers, Figures 3.7 and 3.29 +respectively) and in network-layer datagrams (IP header, Figure 4.16 ). +Now consider a transport layer segment encapsulated in an IP datagram. +Are the checksums in the segment header and datagram header computed +over any common bytes in the IP datagram? Explain your answer. R20. When +a large datagram is fragmented into multiple smaller datagrams, where +are these smaller datagrams reassembled into a single larger datagram? +R21. Do routers have IP addresses? If so, how many? R22. What is the +32-bit binary equivalent of the IP address 223.1.3.27? R23. Visit a host +that uses DHCP to obtain its IP address, network mask, default router, +and IP address of its local DNS server. List these values. R24. Suppose +there are three routers between a source host and a destination host. +Ignoring fragmentation, an IP datagram sent from the source host to the +destination host will travel over how many interfaces? How many +forwarding tables will be indexed to move the datagram from the source +to the destination? + + R25. Suppose an application generates chunks of 40 bytes of data every +20 msec, and each chunk gets encapsulated in a TCP segment and then an +IP datagram. What percentage of each datagram will be overhead, and what +percentage will be application data? R26. Suppose you purchase a +wireless router and connect it to your cable modem. Also suppose that +your ISP dynamically assigns your connected device (that is, your +wireless router) one IP address. Also suppose that you have five PCs at +home that use 802.11 to wirelessly connect to your wireless router. How +are IP addresses assigned to the five PCs? Does the wireless router use +NAT? Why or why not? R27. What is meant by the term "route aggregation"? +Why is it useful for a router to perform route aggregation? R28. What is +meant by a "plug-and-play" or "zeroconf" protocol? R29. What is a +private network address? Should a datagram with a private network +address ever be present in the larger public Internet? Explain. R30. +Compare and contrast the IPv4 and the IPv6 header fields. Do they have +any fields in common? R31. It has been said that when IPv6 tunnels +through IPv4 routers, IPv6 treats the IPv4 tunnels as link-layer +protocols. Do you agree with this statement? Why or why not? + +SECTION 4.4 R32. How does generalized forwarding differ from +destination-based forwarding? R33. What is the difference between a +forwarding table that we encountered in destinationbased forwarding in +Section 4.1 and OpenFlow's flow table that we encountered in Section 4.4 +? R34. What is meant by the "match plus action" operation of a router or +switch? In the case of destination-based forwarding packet switch, what +is matched and what is the action taken? In the case of an SDN, name +three fields that can be matched, and three actions that can be taken. +R35. Name three header fields in an IP datagram that can be "matched" in +OpenFlow 1.0 generalized forwarding. What are three IP datagram header +fields that cannot be "matched" in OpenFlow? + +Problems P1. Consider the network below. + +a. Show the forwarding table in router A, such that all traffic + destined to host H3 is forwarded through interface 3. + +b. Can you write down a forwarding table in router A, such that all + traffic from H1 destined to host H3 is forwarded through interface + 3, while all traffic from H2 destined to host H3 is forwarded + through interface 4? (Hint: This is a trick question.) + + P2. Suppose two packets arrive to two different input ports of a router +at exactly the same time. Also suppose there are no other packets +anywhere in the router. + +a. Suppose the two packets are to be forwarded to two different output + ports. Is it possible to forward the two packets through the switch + fabric at the same time when the fabric uses a shared bus? + +b. Suppose the two packets are to be forwarded to two different output + ports. Is it possible to forward the two packets through the switch + fabric at the same time when the fabric uses switching via memory? + +c. Suppose the two packets are to be forwarded to the same output port. + Is it possible to forward the two packets through the switch fabric + at the same time when the fabric uses a crossbar? P3. In Section 4.2 + , we noted that the maximum queuing delay is (n--1)D if the + switching fabric is n times faster than the input line rates. + Suppose that all packets are of the same length, n packets arrive at + the same time to the n input ports, and all n packets want to be + forwarded to different output ports. What is the maximum delay for a + packet for the (a) memory, (b) bus, and + +```{=html} +<!-- --> +``` +(c) crossbar switching fabrics? P4. Consider the switch shown below. + Suppose that all datagrams have the same fixed length, that the + switch operates in a slotted, synchronous manner, and that in one + time slot a datagram can be transferred from an input port to an + output port. The switch fabric is a crossbar so that at most one + datagram can be transferred to a given output port in a time slot, + but different output ports can receive datagrams from different + input ports in a single time slot. What is the minimal number of + time slots needed to transfer the packets shown from input ports to + their output ports, assuming any input queue scheduling order you + want (i.e., it need not have HOL blocking)? What is the largest + number of slots needed, assuming the worst-case scheduling order you + can devise, assuming that a non-empty input queue is never idle? + + P5. Consider a datagram network using 32-bit host addresses. Suppose a +router has four links, numbered 0 through 3, and packets are to be +forwarded to the link interfaces as follows: Destination Address Range + +Link Interface + +11100000 00000000 00000000 00000000 + +0 + +through 11100000 00111111 11111111 11111111 11100000 01000000 00000000 +00000000 + +1 + +through 11100000 01000000 11111111 11111111 2 + +11100000 01000001 00000000 00000000 through 11100001 01111111 11111111 +11111111 otherwise + +3 + +a. Provide a forwarding table that has five entries, uses longest + prefix matching, and forwards packets to the correct link + interfaces. + +b. Describe how your forwarding table determines the appropriate link + interface for datagrams with destination addresses: 11001000 + 10010001 01010001 01010101 11100001 01000000 11000011 00111100 + 11100001 10000000 00010001 01110111 P6. Consider a datagram network + using 8-bit host addresses. Suppose a router uses longest prefix + matching and has the following forwarding table: Prefix Match + +Interface + + 00 + +0 + +010 + +1 + +011 + +2 + +10 + +2 + +11 + +3 + +For each of the four interfaces, give the associated range of +destination host addresses and the number of addresses in the range. P7. +Consider a datagram network using 8-bit host addresses. Suppose a router +uses longest prefix matching and has the following forwarding table: +Prefix Match + +Interface + +1 + +0 + +10 + +1 + +111 + +2 + +otherwise + +3 + +For each of the four interfaces, give the associated range of +destination host addresses and the number of addresses in the range. P8. +Consider a router that interconnects three subnets: Subnet 1, Subnet 2, +and Subnet 3. Suppose all of the interfaces in each of these three +subnets are required to have the prefix 223.1.17/24. Also suppose that +Subnet 1 is required to support at least 60 interfaces, Subnet 2 is to +support at least 90 interfaces, and Subnet 3 is to support at least 12 +interfaces. Provide three network addresses (of the form a.b.c.d/x) that +satisfy these constraints. P9. In Section 4.2.2 an example forwarding +table (using longest prefix matching) is given. Rewrite this forwarding +table using the a.b.c.d/x notation instead of the binary string +notation. P10. In Problem P5 you are asked to provide a forwarding table +(using longest prefix matching). Rewrite this forwarding table using the +a.b.c.d/x notation instead of the binary string notation. P11. Consider +a subnet with prefix 128.119.40.128/26. Give an example of one IP +address (of form xxx.xxx.xxx.xxx) that can be assigned to this network. +Suppose an ISP owns the block of addresses of the form 128.119.40.64/26. +Suppose it wants to create four subnets from this block, with each block +having the same number of IP addresses. What are the prefixes (of form + + a.b.c.d/x) for the four subnets? P12. Consider the topology shown in +Figure 4.20 . Denote the three subnets with hosts (starting clockwise at +12:00) as Networks A, B, and C. Denote the subnets without hosts as +Networks D, E, and F. + +a. Assign network addresses to each of these six subnets, with the + following constraints: All addresses must be allocated from + 214.97.254/23; Subnet A should have enough addresses to support 250 + interfaces; Subnet B should have enough addresses to support 120 + interfaces; and Subnet C should have enough addresses to support 120 + interfaces. Of course, subnets D, E and F should each be able to + support two interfaces. For each subnet, the assignment should take + the form a.b.c.d/x or a.b.c.d/x -- e.f.g.h/y. + +b. Using your answer to part (a), provide the forwarding tables (using + longest prefix matching) for each of the three routers. P13. Use the + whois service at the American Registry for Internet Numbers + (http://www.arin.net/ whois) to determine the IP address blocks for + three universities. Can the whois services be used to determine with + certainty the geographical location of a specific IP address? Use + www.maxmind.com to determine the locations of the Web servers at + each of these universities. P14. Consider sending a 2400-byte + datagram into a link that has an MTU of 700 bytes. Suppose the + original datagram is stamped with the identification number 422. How + many fragments are generated? What are the values in the various + fields in the IP datagram(s) generated related to fragmentation? + P15. Suppose datagrams are limited to 1,500 bytes (including header) + between source Host A and destination Host B. Assuming a 20-byte IP + header, how many datagrams would be required to send an MP3 + consisting of 5 million bytes? Explain how you computed your answer. + P16. Consider the network setup in Figure 4.25 . Suppose that the + ISP instead assigns the router the address 24.34.112.235 and that + the network address of the home network is 192.168.1/24. + +c. Assign addresses to all interfaces in the home network. + +d. Suppose each host has two ongoing TCP connections, all to port 80 at + host 128.119.40.86. Provide the six corresponding entries in the NAT + translation table. P17. Suppose you are interested in detecting the + number of hosts behind a NAT. You observe that the IP layer stamps + an identification number sequentially on each IP packet. The + identification number of the first IP packet generated by a host is + a random number, and the identification numbers of the subsequent IP + packets are sequentially assigned. Assume all IP packets generated + by hosts behind the NAT are sent to the outside world. + +e. Based on this observation, and assuming you can sniff all packets + sent by the NAT to the outside, can you outline a simple technique + that detects the number of unique hosts behind a NAT? Justify your + answer. + +f. If the identification numbers are not sequentially assigned but + randomly assigned, would + + your technique work? Justify your answer. P18. In this problem we'll +explore the impact of NATs on P2P applications. Suppose a peer with +username Arnold discovers through querying that a peer with username +Bernard has a file it wants to download. Also suppose that Bernard and +Arnold are both behind a NAT. Try to devise a technique that will allow +Arnold to establish a TCP connection with Bernard without +applicationspecific NAT configuration. If you have difficulty devising +such a technique, discuss why. P19. Consider the SDN OpenFlow network +shown in Figure 4.30 . Suppose that the desired forwarding behavior for +datagrams arriving at s2 is as follows: any datagrams arriving on input +port 1 from hosts h5 or h6 that are destined to hosts h1 or h2 should be +forwarded over output port 2; any datagrams arriving on input port 2 +from hosts h1 or h2 that are destined to hosts h5 or h6 should be +forwarded over output port 1; any arriving datagrams on input ports 1 or +2 and destined to hosts h3 or h4 should be delivered to the host +specified; hosts h3 and h4 should be able to send datagrams to each +other. Specify the flow table entries in s2 that implement this +forwarding behavior. P20. Consider again the SDN OpenFlow network shown +in Figure 4.30 . Suppose that the desired forwarding behavior for +datagrams arriving from hosts h3 or h4 at s2 is as follows: any +datagrams arriving from host h3 and destined for h1, h2, h5 or h6 should +be forwarded in a clockwise direction in the network; any datagrams +arriving from host h4 and destined for h1, h2, h5 or h6 should be +forwarded in a counter-clockwise direction in the network. Specify the +flow table entries in s2 that implement this forwarding behavior. P21. +Consider again the scenario from P19 above. Give the flow tables entries +at packet switches s1 and s3, such that any arriving datagrams with a +source address of h3 or h4 are routed to the destination hosts specified +in the destination address field in the IP datagram. (Hint: Your +forwarding table rules should include the cases that an arriving +datagram is destined for a directly attached host or should be forwarded +to a neighboring router for eventual host delivery there.) P22. Consider +again the SDN OpenFlow network shown in Figure 4.30 . Suppose we want +switch s2 to function as a firewall. Specify the flow table in s2 that +implements the following firewall behaviors (specify a different flow +table for each of the four firewalling behaviors below) for delivery of +datagrams destined to h3 and h4. You do not need to specify the +forwarding behavior in s2 that forwards traffic to other routers. Only +traffic arriving from hosts h1 and h6 should be delivered to hosts h3 or +h4 (i.e., that arriving traffic from hosts h2 and h5 is blocked). Only +TCP traffic is allowed to be delivered to hosts h3 or h4 (i.e., that UDP +traffic is blocked). + + Only traffic destined to h3 is to be delivered (i.e., all traffic to h4 +is blocked). Only UDP traffic from h1 and destined to h3 is to be +delivered. All other traffic is blocked. + +Wireshark Lab In the Web site for this textbook, +www.pearsonhighered.com/cs-resources, you'll find a Wireshark lab +assignment that examines the operation of the IP protocol, and the IP +datagram format in particular. + +AN INTERVIEW WITH... Vinton G. Cerf Vinton G. Cerf is Vice President and +Chief Internet Evangelist for Google. He served for over 16 years at MCI +in various positions, ending up his tenure there as Senior Vice +President for Technology Strategy. He is widely known as the co-designer +of the TCP/IP protocols and the architecture of the Internet. During his +time from 1976 to 1982 at the US Department of Defense Advanced Research +Projects Agency (DARPA), he played a key role leading the development of +Internet and Internet-related data packet and security techniques. He +received the US Presidential Medal of Freedom in 2005 and the US +National Medal of Technology in 1997. He holds a BS in Mathematics from +Stanford University and an MS and PhD in computer science from UCLA. + +What brought you to specialize in networking? I was working as a +programmer at UCLA in the late 1960s. My job was supported by the US +Defense Advanced Research Projects Agency (called ARPA then, called +DARPA now). I was working in the laboratory of Professor Leonard +Kleinrock on the Network Measurement Center of the newly created +ARPAnet. The first node of the ARPAnet was installed at UCLA on +September 1, 1969. I was responsible for programming a computer that was +used to capture performance information about the ARPAnet and to report +this information back for comparison with mathematical models and +predictions of the performance of the network. Several of the other +graduate students and I were made responsible for working on the +so-called + + host-level protocols of the ARPAnet---the procedures and formats that +would allow many different kinds of computers on the network to interact +with each other. It was a fascinating exploration into a new world (for +me) of distributed computing and communication. Did you imagine that IP +would become as pervasive as it is today when you first designed the +protocol? When Bob Kahn and I first worked on this in 1973, I think we +were mostly very focused on the central question: How can we make +heterogeneous packet networks interoperate with one another, assuming we +cannot actually change the networks themselves? We hoped that we could +find a way to permit an arbitrary collection of packet-switched networks +to be interconnected in a transparent fashion, so that host computers +could communicate end-to-end without having to do any translations in +between. I think we knew that we were dealing with powerful and +expandable technology, but I doubt we had a clear image of what the +world would be like with hundreds of millions of computers all +interlinked on the Internet. What do you now envision for the future of +networking and the Internet? What major challenges/obstacles do you +think lie ahead in their development? I believe the Internet itself and +networks in general will continue to proliferate. Already there is +convincing evidence that there will be billions of Internet-enabled +devices on the Internet, including appliances like cell phones, +refrigerators, personal digital assistants, home servers, televisions, +as well as the usual array of laptops, servers, and so on. Big +challenges include support for mobility, battery life, capacity of the +access links to the network, and ability to scale the optical core of +the network up in an unlimited fashion. Designing an interplanetary +extension of the Internet is a project in which I am deeply engaged at +the Jet Propulsion Laboratory. We will need to cut over from IPv4 +\[32-bit addresses\] to IPv6 \[128 bits\]. The list is long! Who has +inspired you professionally? My colleague Bob Kahn; my thesis advisor, +Gerald Estrin; my best friend, Steve Crocker (we met in high school and +he introduced me to computers in 1960!); and the thousands of engineers +who continue to evolve the Internet today. Do you have any advice for +students entering the networking/Internet field? Think outside the +limitations of existing systems---imagine what might be possible; but +then do the hard work of figuring out how to get there from the current +state of affairs. Dare to dream: A half dozen colleagues and I at the +Jet Propulsion Laboratory have been working on the design of an +interplanetary extension of the terrestrial Internet. It may take +decades to implement this, + + mission by mission, but to paraphrase: "A man's reach should exceed his +grasp, or what are the heavens for?" + + Chapter 5 The Network Layer: Control Plane + +In this chapter, we'll complete our journey through the network layer by +covering the control-plane component of the network layer---the +network-wide logic that controls not only how a datagram is forwarded +among routers along an end-to-end path from the source host to the +destination host, but also how network-layer components and services are +configured and managed. In Section 5.2, we'll cover traditional routing +algorithms for computing least cost paths in a graph; these algorithms +are the basis for two widely deployed Internet routing protocols: OSPF +and BGP, that we'll cover in Sections 5.3 and 5.4, respectively. As +we'll see, OSPF is a routing protocol that operates within a single +ISP's network. BGP is a routing protocol that serves to interconnect all +of the networks in the Internet; BGP is thus often referred to as the +"glue" that holds the Internet together. Traditionally, control-plane +routing protocols have been implemented together with data-plane +forwarding functions, monolithically, within a router. As we learned in +the introduction to Chapter 4, software-defined networking (SDN) makes a +clear separation between the data and control planes, implementing +control-plane functions in a separate "controller" service that is +distinct, and remote, from the forwarding components of the routers it +controls. We'll cover SDN controllers in Section 5.5. In Sections 5.6 +and 5.7 we'll cover some of the nuts and bolts of managing an IP +network: ICMP (the Internet Control Message Protocol) and SNMP (the +Simple Network Management Protocol). + + 5.1 Introduction Let's quickly set the context for our study of the +network control plane by recalling Figures 4.2 and 4.3. There, we saw +that the forwarding table (in the case of destination-based forwarding) +and the flow table (in the case of generalized forwarding) were the +principal elements that linked the network layer's data and control +planes. We learned that these tables specify the local data-plane +forwarding behavior of a router. We saw that in the case of generalized +forwarding, the actions taken (Section 4.4.2) could include not only +forwarding a packet to a router's output port, but also dropping a +packet, replicating a packet, and/or rewriting layer 2, 3 or 4 +packet-header fields. In this chapter, we'll study how those forwarding +and flow tables are computed, maintained and installed. In our +introduction to the network layer in Section 4.1, we learned that there +are two possible approaches for doing so. Per-router control. Figure 5.1 +illustrates the case where a routing algorithm runs in each and every +router; both a forwarding and a routing function are contained + +Figure 5.1 Per-router control: Individual routing algorithm components +interact in the control plane + + within each router. Each router has a routing component that +communicates with the routing components in other routers to compute the +values for its forwarding table. This per-router control approach has +been used in the Internet for decades. The OSPF and BGP protocols that +we'll study in Sections 5.3 and 5.4 are based on this per-router +approach to control. Logically centralized control. Figure 5.2 +illustrates the case in which a logically centralized controller +computes and distributes the forwarding tables to be used by each and +every router. As we saw in Section 4.4, the generalized +match-plus-action abstraction allows the router to perform traditional +IP forwarding as well as a rich set of other functions (load sharing, +firewalling, and NAT) that had been previously implemented in separate +middleboxes. + +Figure 5.2 Logically centralized control: A distinct, typically remote, +controller interacts with local control agents (CAs) + +The controller interacts with a control agent (CA) in each of the +routers via a well-defined protocol to configure and manage that +router's flow table. Typically, the CA has minimum functionality; its +job is to communicate with the controller, and to do as the controller +commands. Unlike the routing algorithms in Figure 5.1, the CAs do not +directly interact with each other nor do they actively take part in +computing + + the forwarding table. This is a key distinction between per-router +control and logically centralized control. By "logically centralized" +control \[Levin 2012\] we mean that the routing control service is +accessed as if it were a single central service point, even though the +service is likely to be implemented via multiple servers for +fault-tolerance, and performance scalability reasons. As we will see in +Section 5.5, SDN adopts this notion of a logically centralized +controller---an approach that is finding increased use in production +deployments. Google uses SDN to control the routers in its internal B4 +global wide-area network that interconnects its data centers \[Jain +2013\]. SWAN \[Hong 2013\], from Microsoft Research, uses a logically +centralized controller to manage routing and forwarding between a wide +area network and a data center network. China Telecom and China Unicom +are using SDN both within data centers and between data centers \[Li +2015\]. AT&T has noted \[AT&T 2013\] that it "supports many SDN +capabilities and independently defined, proprietary mechanisms that fall +under the SDN architectural framework." + + 5.2 Routing Algorithms In this section we'll study routing algorithms, +whose goal is to determine good paths (equivalently, routes), from +senders to receivers, through the network of routers. Typically, a +"good" path is one that has the least cost. We'll see that in practice, +however, real-world concerns such as policy issues (for example, a rule +such as "router x, belonging to organization Y, should not forward any +packets originating from the network owned by organization Z") also come +into play. We note that whether the network control plane adopts a +per-router control approach or a logically centralized approach, there +must always be a welldefined sequence of routers that a packet will +cross in traveling from sending to receiving host. Thus, the routing +algorithms that compute these paths are of fundamental importance, and +another candidate for our top-10 list of fundamentally important +networking concepts. A graph is used to formulate routing problems. +Recall that a graph G=(N, E) is a set N of nodes and a collection E of +edges, where each edge is a pair of nodes from N. In the context of +network-layer routing, the nodes in the graph represent + +Figure 5.3 Abstract graph model of a computer network + +routers---the points at which packet-forwarding decisions are made---and +the edges connecting these nodes represent the physical links between +these routers. Such a graph abstraction of a computer network is shown +in Figure 5.3. To view some graphs representing real network maps, see +\[Dodge 2016, Cheswick 2000\]; for a discussion of how well different +graph-based models model the Internet, see \[Zegura 1997, Faloutsos +1999, Li 2004\]. As shown in Figure 5.3, an edge also has a value +representing its cost. Typically, an edge's cost may reflect the +physical length of the corresponding link (for example, a transoceanic +link might have a higher + + cost than a short-haul terrestrial link), the link speed, or the +monetary cost associated with a link. For our purposes, we'll simply +take the edge costs as a given and won't worry about how they are +determined. For any edge (x, y) in E, we denote c(x, y) as the cost of +the edge between nodes x and y. If the pair (x, y) does not belong to E, +we set c(x, y)=∞. Also, we'll only consider undirected graphs (i.e., +graphs whose edges do not have a direction) in our discussion here, so +that edge (x, y) is the same as edge (y, x) and that c(x, y)=c(y, x); +however, the algorithms we'll study can be easily extended to the case +of directed links with a different cost in each direction. Also, a node +y is said to be a neighbor of node x if (x, y) belongs to E. Given that +costs are assigned to the various edges in the graph abstraction, a +natural goal of a routing algorithm is to identify the least costly +paths between sources and destinations. To make this problem more +precise, recall that a path in a graph G=(N, E) is a sequence of nodes +(x1,x2,⋯,xp) such that each of the pairs (x1,x2),(x2,x3),⋯,(xp−1,xp) are +edges in E. The cost of a path (x1,x2,⋯, xp) is simply the sum of all +the edge costs along the path, that is, c(x1,x2)+c(x2,x3)+⋯+c(xp−1,xp). +Given any two nodes x and y, there are typically many paths between the +two nodes, with each path having a cost. One or more of these paths is a +least-cost path. The least-cost problem is therefore clear: Find a path +between the source and destination that has least cost. In Figure 5.3, +for example, the least-cost path between source node u and destination +node w is (u, x, y, w) with a path cost of 3. Note that if all edges in +the graph have the same cost, the least-cost path is also the shortest +path (that is, the path with the smallest number of links between the +source and the destination). As a simple exercise, try finding the +least-cost path from node u to z in Figure 5.3 and reflect for a moment +on how you calculated that path. If you are like most people, you found +the path from u to z by examining Figure 5.3, tracing a few routes from +u to z, and somehow convincing yourself that the path you had chosen had +the least cost among all possible paths. (Did you check all of the 17 +possible paths between u and z? Probably not!) Such a calculation is an +example of a centralized routing algorithm---the routing algorithm was +run in one location, your brain, with complete information about the +network. Broadly, one way in which we can classify routing algorithms is +according to whether they are centralized or decentralized. A +centralized routing algorithm computes the least-cost path between a +source and destination using complete, global knowledge about the +network. That is, the algorithm takes the connectivity between all nodes +and all link costs as inputs. This then requires that the algorithm +somehow obtain this information before actually performing the +calculation. The calculation itself can be run at one site (e.g., a +logically centralized controller as in Figure 5.2) or could be +replicated in the routing component of each and every router (e.g., as +in Figure 5.1). The key distinguishing feature here, however, is that +the algorithm has complete information about connectivity and link +costs. Algorithms with global state information are often referred to as +link-state (LS) algorithms, since the algorithm must be aware of the +cost of each link in the network. We'll study LS algorithms in Section +5.2.1. In a decentralized routing algorithm, the calculation of the +least-cost path is carried out in an + + iterative, distributed manner by the routers. No node has complete +information about the costs of all network links. Instead, each node +begins with only the knowledge of the costs of its own directly attached +links. Then, through an iterative process of calculation and exchange of +information with its neighboring nodes, a node gradually calculates the +least-cost path to a destination or set of destinations. The +decentralized routing algorithm we'll study below in Section 5.2.2 is +called a distance-vector (DV) algorithm, because each node maintains a +vector of estimates of the costs (distances) to all other nodes in the +network. Such decentralized algorithms, with interactive message +exchange between neighboring routers is perhaps more naturally suited to +control planes where the routers interact directly with each other, as +in Figure 5.1. A second broad way to classify routing algorithms is +according to whether they are static or dynamic. In static routing +algorithms, routes change very slowly over time, often as a result of +human intervention (for example, a human manually editing a link costs). +Dynamic routing algorithms change the routing paths as the network +traffic loads or topology change. A dynamic algorithm can be run either +periodically or in direct response to topology or link cost changes. +While dynamic algorithms are more responsive to network changes, they +are also more susceptible to problems such as routing loops and route +oscillation. A third way to classify routing algorithms is according to +whether they are load-sensitive or loadinsensitive. In a load-sensitive +algorithm, link costs vary dynamically to reflect the current level of +congestion in the underlying link. If a high cost is associated with a +link that is currently congested, a routing algorithm will tend to +choose routes around such a congested link. While early ARPAnet routing +algorithms were load-sensitive \[McQuillan 1980\], a number of +difficulties were encountered \[Huitema 1998\]. Today's Internet routing +algorithms (such as RIP, OSPF, and BGP) are load-insensitive, as a +link's cost does not explicitly reflect its current (or recent past) +level of congestion. + +5.2.1 The Link-State (LS) Routing Algorithm Recall that in a link-state +algorithm, the network topology and all link costs are known, that is, +available as input to the LS algorithm. In practice this is accomplished +by having each node broadcast link-state packets to all other nodes in +the network, with each link-state packet containing the identities and +costs of its attached links. In practice (for example, with the +Internet's OSPF routing protocol, discussed in Section 5.3) this is +often accomplished by a link-state broadcast algorithm \[Perlman 1999\]. +The result of the nodes' broadcast is that all nodes have an identical +and complete view of the network. Each node can then run the LS +algorithm and compute the same set of least-cost paths as every other +node. The link-state routing algorithm we present below is known as +Dijkstra's algorithm, named after its inventor. A closely related +algorithm is Prim's algorithm; see \[Cormen 2001\] for a general +discussion of graph algorithms. Dijkstra's algorithm computes the +least-cost path from one node (the source, which we will refer to as u) +to all other nodes in the network. Dijkstra's algorithm is iterative and +has the property that + + after the kth iteration of the algorithm, the least-cost paths are known +to k destination nodes, and among the least-cost paths to all +destination nodes, these k paths will have the k smallest costs. Let us +define the following notation: D(v): cost of the least-cost path from +the source node to destination v as of this iteration of the algorithm. +p(v): previous node (neighbor of v) along the current least-cost path +from the source to v. N′: subset of nodes; v is in N′ if the least-cost +path from the source to v is definitively known. The centralized routing +algorithm consists of an initialization step followed by a loop. The +number of times the loop is executed is equal to the number of nodes in +the network. Upon termination, the algorithm will have calculated the +shortest paths from the source node u to every other node in the +network. + +Link-State (LS) Algorithm for Source Node u + +1 + +Initialization: + +2 + +N' = {u} + +3 + +for all nodes v + +4 + +if v is a neighbor of u + +5 + +then D(v) = c(u, v) + +6 + +else D(v) = ∞ + +7 8 + +Loop + +9 + +find w not in N' such that D(w) is a minimum + +10 + +add w to N' + +11 + +update D(v) for each neighbor v of w and not in N': + +12 + +D(v) = min(D(v), D(w)+ c(w, v) ) + +13 + +/\* new cost to v is either old cost to v or known + +14 + +least path cost to w plus cost from w to v \*/ + +15 until N'= N + +As an example, let's consider the network in Figure 5.3 and compute the +least-cost paths from u to all possible destinations. A tabular summary +of the algorithm's computation is shown in Table 5.1, where each line in +the table gives the values of the algorithm's variables at the end of +the iteration. Let's consider the few first steps in detail. In the +initialization step, the currently known least-cost paths from u to its +directly attached neighbors, + + v, x, and w, are initialized to 2, 1, and 5, respectively. Note in Table +5.1 Running the link-state algorithm on the network in Figure 5.3 step + +N' + +D (v), p (v) + +D (w), p (w) + +D (x), p (x) + +D (y), p (y) + +D (z), p (z) + +0 + +u + +2, u + +5, u + +1,u + +∞ + +∞ + +1 + +ux + +2, u + +4, x + +2, x + +∞ + +2 + +uxy + +2, u + +3, y + +4, y + +3 + +uxyv + +3, y + +4, y + +4 + +uxyvw + +5 + +uxyvwz + +4, y + +particular that the cost to w is set to 5 (even though we will soon see +that a lesser-cost path does indeed exist) since this is the cost of the +direct (one hop) link from u to w. The costs to y and z are set to +infinity because they are not directly connected to u. In the first +iteration, we look among those nodes not yet added to the set N′ and +find that node with the least cost as of the end of the previous +iteration. That node is x, with a cost of 1, and thus x is added to the +set N′. Line 12 of the LS algorithm is then performed to update D(v) for +all nodes v, yielding the results shown in the second line (Step 1) in +Table 5.1. The cost of the path to v is unchanged. The cost of the path +to w (which was 5 at the end of the initialization) through node x is +found to have a cost of 4. Hence this lower-cost path is selected and +w's predecessor along the shortest path from u is set to x. Similarly, +the cost to y (through x) is computed to be 2, and the table is updated +accordingly. In the second iteration, nodes v and y are found to have +the least-cost paths (2), and we break the tie arbitrarily and add y to +the set N′ so that N′ now contains u, x, and y. The cost to the +remaining nodes not yet in N′, that is, nodes v, w, and z, are updated +via line 12 of the LS algorithm, yielding the results shown in the third +row in Table 5.1. And so on . . . When the LS algorithm terminates, we +have, for each node, its predecessor along the least-cost path from the +source node. For each predecessor, we also have its predecessor, and so +in this manner we can construct the entire path from the source to all +destinations. The forwarding table in a node, say node u, can then be +constructed from this information by storing, for each destination, the +next-hop node on the least-cost path from u to the destination. Figure +5.4 shows the resulting least-cost paths and forwarding table in u for +the network in Figure 5.3. + + Figure 5.4 Least cost path and forwarding table for node u + +What is the computational complexity of this algorithm? That is, given n +nodes (not counting the source), how much computation must be done in +the worst case to find the least-cost paths from the source to all +destinations? In the first iteration, we need to search through all n +nodes to determine the node, w, not in N′ that has the minimum cost. In +the second iteration, we need to check n−1 nodes to determine the +minimum cost; in the third iteration n−2 nodes, and so on. Overall, the +total number of nodes we need to search through over all the iterations +is n(n+1)/2, and thus we say that the preceding implementation of the LS +algorithm has worst-case complexity of order n squared: O(n2). (A more +sophisticated implementation of this algorithm, using a data structure +known as a heap, can find the minimum in line 9 in logarithmic rather +than linear time, thus reducing the complexity.) Before completing our +discussion of the LS algorithm, let us consider a pathology that can +arise. Figure 5.5 shows a simple network topology where link costs are +equal to the load carried on the link, for example, reflecting the delay +that would be experienced. In this example, link costs are not +symmetric; that is, c(u, v) equals c(v, u) only if the load carried on +both directions on the link (u, v) is the same. In this example, node z +originates a unit of traffic destined for w, node x also originates a +unit of traffic destined for w, and node y injects an amount of traffic +equal to e, also destined for w. The initial routing is shown in Figure +5.5(a) with the link costs corresponding to the amount of traffic +carried. When the LS algorithm is next run, node y determines (based on +the link costs shown in Figure 5.5(a)) that the clockwise path to w has +a cost of 1, while the counterclockwise path to w (which it had been +using) has a cost of 1+e. Hence y's least-cost path to w is now +clockwise. Similarly, x determines that its new least-cost path to w is +also clockwise, resulting in costs shown in Figure 5.5(b). When the LS +algorithm is run next, nodes x, y, and z all detect a zero-cost path to +w in the counterclockwise direction, and all route their traffic to the +counterclockwise routes. The next time the LS algorithm is run, x, y, +and z all then route their traffic to the clockwise routes. What can be +done to prevent such oscillations (which can occur in any algorithm, not +just an LS algorithm, that uses a congestion or delay-based link +metric)? One solution would be to mandate that link costs not depend on +the amount of traffic + + Figure 5.5 Oscillations with congestion-sensitive routing + + carried---an unacceptable solution since one goal of routing is to avoid +highly congested (for example, high-delay) links. Another solution is to +ensure that not all routers run the LS algorithm at the same time. This +seems a more reasonable solution, since we would hope that even if +routers ran the LS algorithm with the same periodicity, the execution +instance of the algorithm would not be the same at each node. +Interestingly, researchers have found that routers in the Internet can +self-synchronize among themselves \[Floyd Synchronization 1994\]. That +is, even though they initially execute the algorithm with the same +period but at different instants of time, the algorithm execution +instance can eventually become, and remain, synchronized at the routers. +One way to avoid such self-synchronization is for each router to +randomize the time it sends out a link advertisement. Having studied the +LS algorithm, let's consider the other major routing algorithm that is +used in practice today---the distance-vector routing algorithm. + +5.2.2 The Distance-Vector (DV) Routing Algorithm Whereas the LS +algorithm is an algorithm using global information, the distance-vector +(DV) algorithm is iterative, asynchronous, and distributed. It is +distributed in that each node receives some information from one or more +of its directly attached neighbors, performs a calculation, and then +distributes the results of its calculation back to its neighbors. It is +iterative in that this process continues on until no more information is +exchanged between neighbors. (Interestingly, the algorithm is also +self-terminating---there is no signal that the computation should stop; +it just stops.) The algorithm is asynchronous in that it does not +require all of the nodes to operate in lockstep with each other. We'll +see that an asynchronous, iterative, selfterminating, distributed +algorithm is much more interesting and fun than a centralized algorithm! +Before we present the DV algorithm, it will prove beneficial to discuss +an important relationship that exists among the costs of the least-cost +paths. Let dx(y) be the cost of the least-cost path from node x to node +y. Then the least costs are related by the celebrated Bellman-Ford +equation, namely, + + (5.1) + +dx(y)=minv{c(x,v)+dv(y)}, where the minv in the equation is taken over +all of x's neighbors. The Bellman-Ford equation is rather + +intuitive. Indeed, after traveling from x to v, if we then take the +least-cost path from v to y, the path cost will be c(x,v)+dv(y). Since +we must begin by traveling to some neighbor v, the least cost from x to +y is the minimum of c(x,v)+dv(y) taken over all neighbors v. But for +those who might be skeptical about the validity of the equation, let's +check it for source node u and destination node z in Figure 5.3. The +source node u has three neighbors: nodes v, x, and w. By walking along +various paths in the graph, it is easy to see that dv(z)=5, dx(z)=3, and +dw(z)=3. Plugging these values into Equation 5.1, along with the costs +c(u,v)=2, c(u,x)=1, and c(u,w)=5, gives du(z)=min{2+5,5+3,1+3}=4, which +is obviously true and which is exactly what the Dijskstra algorithm gave +us for the same network. This quick verification should help relieve any +skepticism you may have. The Bellman-Ford equation is not just an +intellectual curiosity. It actually has significant practical +importance: the solution to the Bellman-Ford equation provides the +entries in node x's forwarding table. To see this, let v\* be any +neighboring node that achieves the minimum in Equation 5.1. Then, if +node x wants to send a packet to node y along a least-cost path, it +should first forward the packet to node v*. Thus, node x's forwarding +table would specify node v* as the next-hop router for the ultimate +destination y. Another important practical contribution of the +Bellman-Ford equation is that it suggests the form of the +neighborto-neighbor communication that will take place in the DV +algorithm. The basic idea is as follows. Each node x begins with Dx(y), +an estimate of the cost of the least-cost path from itself to node y, +for all nodes, y, in N. Let Dx=\[Dx(y): y in N\] be node x's distance +vector, which is the vector of cost estimates from x to all other nodes, +y, in N. With the DV algorithm, each node x maintains the following +routing information: For each neighbor v, the cost c(x, v) from x to +directly attached neighbor, v Node x's distance vector, that is, +Dx=\[Dx(y): y in N\], containing x's estimate of its cost to all +destinations, y, in N The distance vectors of each of its neighbors, +that is, Dv=\[Dv(y): y in N\] for each neighbor v of x In the +distributed, asynchronous algorithm, from time to time, each node sends +a copy of its distance vector to each of its neighbors. When a node x +receives a new distance vector from any of its neighbors w, it saves w's +distance vector, and then uses the Bellman-Ford equation to update its +own distance vector as follows: Dx(y)=minv{c(x,v)+Dv(y)} + +for each node y in N + +If node x's distance vector has changed as a result of this update step, +node x will then send its updated + + distance vector to each of its neighbors, which can in turn update their +own distance vectors. Miraculously enough, as long as all the nodes +continue to exchange their distance vectors in an asynchronous fashion, +each cost estimate Dx(y) converges to dx(y), the actual cost of the +least-cost path from node x to node y \[Bertsekas 1991\]! +Distance-Vector (DV) Algorithm At each node, x: + +1 2 + +Initialization: for all destinations y in N: + +3 4 + +Dx(y)= c(x, y)/\* if y is not a neighbor then c(x, y)= ∞ \*/ for each +neighbor w + +5 6 + +Dw(y) = ? for all destinations y in N for each neighbor w + +7 + +send distance vector + +Dx = \[Dx(y): y in N\] to w + +8 9 10 + +loop wait + +11 + +(until I see a link cost change to some neighbor w or until I receive a +distance vector from some neighbor w) + +12 13 + +for each y in N: + +14 + +Dx(y) = minv{c(x, v) + Dv(y)} + +15 16 if Dx(y) changed for any destination y 17 + +send distance vector Dx + += \[Dx(y): y in N\] to all neighbors + +18 19 forever + +In the DV algorithm, a node x updates its distance-vector estimate when +it either sees a cost change in one of its directly attached links or +receives a distance-vector update from some neighbor. But to update its +own forwarding table for a given destination y, what node x really needs +to know is not the shortest-path distance to y but instead the +neighboring node v*(y) that is the next-hop router along the shortest +path to y. As you might expect, the next-hop router v*(y) is the +neighbor v that achieves the minimum in Line 14 of the DV algorithm. (If +there are multiple neighbors v that achieve the minimum, then v*(y) can +be any of the minimizing neighbors.) Thus, in Lines 13--14, for each +destination y, node x also determines v*(y) and updates its forwarding +table for destination y. + + Recall that the LS algorithm is a centralized algorithm in the sense +that it requires each node to first obtain a complete map of the network +before running the Dijkstra algorithm. The DV algorithm is decentralized +and does not use such global information. Indeed, the only information a +node will have is the costs of the links to its directly attached +neighbors and information it receives from these neighbors. Each node +waits for an update from any neighbor (Lines 10--11), calculates its new +distance vector when receiving an update (Line 14), and distributes its +new distance vector to its neighbors (Lines 16--17). DV-like algorithms +are used in many routing protocols in practice, including the Internet's +RIP and BGP, ISO IDRP, Novell IPX, and the original ARPAnet. Figure 5.6 +illustrates the operation of the DV algorithm for the simple three-node +network shown at the top of the figure. The operation of the algorithm +is illustrated in a synchronous manner, where all nodes simultaneously +receive distance vectors from their neighbors, compute their new +distance vectors, and inform their neighbors if their distance vectors +have changed. After studying this example, you should convince yourself +that the algorithm operates correctly in an asynchronous manner as well, +with node computations and update generation/reception occurring at any +time. The leftmost column of the figure displays three initial routing +tables for each of the three nodes. For example, the table in the +upper-left corner is node x's initial routing table. Within a specific +routing table, each row is a distance vector--- specifically, each +node's routing table includes its own distance vector and that of each +of its neighbors. Thus, the first row in node x's initial routing table +is Dx=\[Dx(x),Dx(y),Dx(z)\]=\[0,2,7\]. The second and third rows in this +table are the most recently received distance vectors from nodes y and +z, respectively. Because at initialization node x has not received +anything from node y or z, the entries in the second and third rows are +initialized to infinity. After initialization, each node sends its +distance vector to each of its two neighbors. This is illustrated in +Figure 5.6 by the arrows from the first column of tables to the second +column of tables. For example, node x sends its distance vector Dx = +\[0, 2, 7\] to both nodes y and z. After receiving the updates, each +node recomputes its own distance vector. For example, node x computes +Dx(x)=0Dx(y)=min{c(x,y)+Dy(y),c(x,z)+Dz(y)}=min{2+0, +7+1}=2Dx(z)=min{c(x,y)+Dy(z),c(x,z)+Dz(z)}=min{2+1,7+0}=3 The second +column therefore displays, for each node, the node's new distance vector +along with distance vectors just received from its neighbors. Note, for +example, that + + Figure 5.6 Distance-vector (DV) algorithm in operation + +node x's estimate for the least cost to node z, Dx(z), has changed from +7 to 3. Also note that for node x, neighboring node y achieves the +minimum in line 14 of the DV algorithm; thus at this stage of the +algorithm, we have at node x that v*(y)=y and v*(z)=y. After the nodes +recompute their distance vectors, they again send their updated distance +vectors to their neighbors (if there has been a change). This is +illustrated in Figure 5.6 by the arrows from the second column of tables +to the third column of tables. Note that only nodes x and z send +updates: node y's distance vector didn't change so node y doesn't send +an update. After receiving the updates, the nodes then recompute their +distance vectors and update their routing tables, which are shown in the +third column. + + The process of receiving updated distance vectors from neighbors, +recomputing routing table entries, and informing neighbors of changed +costs of the least-cost path to a destination continues until no update +messages are sent. At this point, since no update messages are sent, no +further routing table calculations will occur and the algorithm will +enter a quiescent state; that is, all nodes will be performing the wait +in Lines 10--11 of the DV algorithm. The algorithm remains in the +quiescent state until a link cost changes, as discussed next. +Distance-Vector Algorithm: Link-Cost Changes and Link Failure When a +node running the DV algorithm detects a change in the link cost from +itself to a neighbor (Lines 10--11), it updates its distance vector +(Lines 13--14) and, if there's a change in the cost of the least-cost +path, informs its neighbors (Lines 16--17) of its new distance vector. +Figure 5.7(a) illustrates a scenario where the link cost from y to x +changes from 4 to 1. We focus here only on y' and z's distance table +entries to destination x. The DV algorithm causes the following sequence +of events to occur: At time t0, y detects the link-cost change (the cost +has changed from 4 to 1), updates its distance vector, and informs its +neighbors of this change since its distance vector has changed. At time +t1, z receives the update from y and updates its table. It computes a +new least cost to x (it has decreased from a cost of 5 to a cost of 2) +and sends its new distance vector to its neighbors. At time t2, y +receives z's update and updates its distance table. y's least costs do +not change and hence y does not send any message to z. The algorithm +comes to a quiescent state. Thus, only two iterations are required for +the DV algorithm to reach a quiescent state. The good news about the +decreased cost between x and y has propagated quickly through the +network. + +Figure 5.7 Changes in link cost + +Let's now consider what can happen when a link cost increases. Suppose +that the link cost between x and y increases from 4 to 60, as shown in +Figure 5.7(b). + +1. Before the link cost changes, Dy(x)=4, Dy(z)=1, Dz(y)=1, and + Dz(x)=5. At time t0, y detects the link- + + cost change (the cost has changed from 4 to 60). y computes its new +minimum-cost path to x to have a cost of Dy(x)=min{c(y,x)+Dx(x), +c(y,z)+Dz(x)}=min{60+0,1+5}=6 Of course, with our global view of the +network, we can see that this new cost via z is wrong. But the only +information node y has is that its direct cost to x is 60 and that z has +last told y that z could get to x with a cost of 5. So in order to get +to x, y would now route through z, fully expecting that z will be able +to get to x with a cost of 5. As of t1 we have a routing loop---in order +to get to x, y routes through z, and z routes through y. A routing loop +is like a black hole---a packet destined for x arriving at y or z as of +t1 will bounce back and forth between these two nodes forever (or until +the forwarding tables are changed). + +2. Since node y has computed a new minimum cost to x, it informs z of + its new distance vector at time t1. + +3. Sometime after t1, z receives y's new distance vector, which + indicates that y's minimum cost to x is + +4. z knows it can get to y with a cost of 1 and hence computes a new + least cost to x of Dz(x)=min{50+0,1+6}=7. Since z's least cost to x + has increased, it then informs y of its new distance vector at t2. + +5. In a similar manner, after receiving z's new distance vector, y + determines Dy(x)=8 and sends z its distance vector. z then + determines Dz(x)=9 and sends y its distance vector, and so on. How + long will the process continue? You should convince yourself that + the loop will persist for 44 iterations (message exchanges between y + and z)---until z eventually computes the cost of its path via y to + be greater than 50. At this point, z will (finally!) determine that + its least-cost path to x is via its direct connection to x. y will + then route to x via z. The result of the bad news about the increase + in link cost has indeed traveled slowly! What would have happened if + the link cost c(y, x) had changed from 4 to 10,000 and the cost c(z, + +```{=html} +<!-- --> +``` +x) had been 9,999? Because of such scenarios, the problem we have seen + is sometimes referred to as the count-to-infinity problem. + Distance-Vector Algorithm: Adding Poisoned Reverse The specific + looping scenario just described can be avoided using a technique + known as poisoned reverse. The idea is simple---if z routes through + y to get to destination x, then z will advertise to y that its + distance to x is infinity, that is, z will advertise to y that + Dz(x)=∞ (even though z knows Dz(x)=5 in truth). z will continue + telling this little white lie to y as long as it routes to x via y. + Since y believes that z has no path to x, y will never attempt to + route to x via z, as long as z continues to route to x via y (and + lies about doing so). Let's now see how poisoned reverse solves the + particular looping problem we encountered before in Figure 5.5(b). + As a result of the poisoned reverse, y's distance table indicates + Dz(x)=∞. When the cost of the (x, y) link changes from 4 to 60 at + time t0, y updates its table and continues to route directly to x, + albeit + + at a higher cost of 60, and informs z of its new cost to x, that is, +Dy(x)=60. After receiving the update at t1, z immediately shifts its +route to x to be via the direct (z, x) link at a cost of 50. Since this +is a new least-cost path to x, and since the path no longer passes +through y, z now informs y that Dz(x)=50 at t2. After receiving the +update from z, y updates its distance table with Dy(x)=51. Also, since z +is now on y's leastcost path to x, y poisons the reverse path from z to +x by informing z at time t3 that Dy(x)=∞ (even though y knows that +Dy(x)=51 in truth). Does poisoned reverse solve the general +count-to-infinity problem? It does not. You should convince yourself +that loops involving three or more nodes (rather than simply two +immediately neighboring nodes) will not be detected by the poisoned +reverse technique. A Comparison of LS and DV Routing Algorithms The DV +and LS algorithms take complementary approaches toward computing +routing. In the DV algorithm, each node talks to only its directly +connected neighbors, but it provides its neighbors with leastcost +estimates from itself to all the nodes (that it knows about) in the +network. The LS algorithm requires global information. Consequently, +when implemented in each and every router, e.g., as in Figure 4.2 and +5.1, each node would need to communicate with all other nodes (via +broadcast), but it tells them only the costs of its directly connected +links. Let's conclude our study of LS and DV algorithms with a quick +comparison of some of their attributes. Recall that N is the set of +nodes (routers) and E is the set of edges (links). Message complexity. +We have seen that LS requires each node to know the cost of each link in +the network. This requires O(\|N\| \|E\|) messages to be sent. Also, +whenever a link cost changes, the new link cost must be sent to all +nodes. The DV algorithm requires message exchanges between directly +connected neighbors at each iteration. We have seen that the time needed +for the algorithm to converge can depend on many factors. When link +costs change, the DV algorithm will propagate the results of the changed +link cost only if the new link cost results in a changed least-cost path +for one of the nodes attached to that link. Speed of convergence. We +have seen that our implementation of LS is an O(\|N\|2) algorithm +requiring O(\|N\| \|E\|)) messages. The DV algorithm can converge slowly +and can have routing loops while the algorithm is converging. DV also +suffers from the count-to-infinity problem. Robustness. What can happen +if a router fails, misbehaves, or is sabotaged? Under LS, a router could +broadcast an incorrect cost for one of its attached links (but no +others). A node could also corrupt or drop any packets it received as +part of an LS broadcast. But an LS node is computing only its own +forwarding tables; other nodes are performing similar calculations for +themselves. This means route calculations are somewhat separated under +LS, providing a degree of robustness. Under DV, a node can advertise +incorrect least-cost paths to any or all destinations. (Indeed, in 1997, +a malfunctioning router in a small ISP provided national backbone +routers with erroneous routing information. This caused other routers to +flood the malfunctioning router with traffic and caused large portions +of the + + Internet to become disconnected for up to several hours \[Neumann +1997\].) More generally, we note that, at each iteration, a node's +calculation in DV is passed on to its neighbor and then indirectly to +its neighbor's neighbor on the next iteration. In this sense, an +incorrect node calculation can be diffused through the entire network +under DV. In the end, neither algorithm is an obvious winner over the +other; indeed, both algorithms are used in the Internet. + + 5.3 Intra-AS Routing in the Internet: OSPF In our study of routing +algorithms so far, we've viewed the network simply as a collection of +interconnected routers. One router was indistinguishable from another in +the sense that all routers executed the same routing algorithm to +compute routing paths through the entire network. In practice, this +model and its view of a homogenous set of routers all executing the same +routing algorithm is simplistic for two important reasons: Scale. As the +number of routers becomes large, the overhead involved in communicating, +computing, and storing routing information becomes prohibitive. Today's +Internet consists of hundreds of millions of routers. Storing routing +information for possible destinations at each of these routers would +clearly require enormous amounts of memory. The overhead required to +broadcast connectivity and link cost updates among all of the routers +would be huge! A distance-vector algorithm that iterated among such a +large number of routers would surely never converge. Clearly, something +must be done to reduce the complexity of route computation in a network +as large as the Internet. Administrative autonomy. As described in +Section 1.3, the Internet is a network of ISPs, with each ISP consisting +of its own network of routers. An ISP generally desires to operate its +network as it pleases (for example, to run whatever routing algorithm it +chooses within its network) or to hide aspects of its network's internal +organization from the outside. Ideally, an organization should be able +to operate and administer its network as it wishes, while still being +able to connect its network to other outside networks. Both of these +problems can be solved by organizing routers into autonomous systems +(ASs), with each AS consisting of a group of routers that are under the +same administrative control. Often the routers in an ISP, and the links +that interconnect them, constitute a single AS. Some ISPs, however, +partition their network into multiple ASs. In particular, some tier-1 +ISPs use one gigantic AS for their entire network, whereas others break +up their ISP into tens of interconnected ASs. An autonomous system is +identified by its globally unique autonomous system number (ASN) \[RFC +1930\]. AS numbers, like IP addresses, are assigned by ICANN regional +registries \[ICANN 2016\]. Routers within the same AS all run the same +routing algorithm and have information about each other. The routing +algorithm running within an autonomous system is called an +intra-autonomous system routing protocol. Open Shortest Path First +(OSPF) + + OSPF routing and its closely related cousin, IS-IS, are widely used for +intra-AS routing in the Internet. The Open in OSPF indicates that the +routing protocol specification is publicly available (for example, as +opposed to Cisco's EIGRP protocol, which was only recently became open +\[Savage 2015\], after roughly 20 years as a Cisco-proprietary +protocol). The most recent version of OSPF, version 2, is defined in +\[RFC 2328\], a public document. OSPF is a link-state protocol that uses +flooding of link-state information and a Dijkstra's least-cost path +algorithm. With OSPF, each router constructs a complete topological map +(that is, a graph) of the entire autonomous system. Each router then +locally runs Dijkstra's shortest-path algorithm to determine a +shortest-path tree to all subnets, with itself as the root node. +Individual link costs are configured by the network administrator (see +sidebar, Principles and Practice: Setting OSPF Weights). The +administrator might choose to set all link costs to 1, + +PRINCIPLES IN PRACTICE SETTING OSPF LINK WEIGHTS Our discussion of +link-state routing has implicitly assumed that link weights are set, a +routing algorithm such as OSPF is run, and traffic flows according to +the routing tables computed by the LS algorithm. In terms of cause and +effect, the link weights are given (i.e., they come first) and result +(via Dijkstra's algorithm) in routing paths that minimize overall cost. +In this viewpoint, link weights reflect the cost of using a link (e.g., +if link weights are inversely proportional to capacity, then the use of +high-capacity links would have smaller weight and thus be more +attractive from a routing standpoint) and Dijsktra's algorithm serves to +minimize overall cost. In practice, the cause and effect relationship +between link weights and routing paths may be reversed, with network +operators configuring link weights in order to obtain routing paths that +achieve certain traffic engineering goals \[Fortz 2000, Fortz 2002\]. +For example, suppose a network operator has an estimate of traffic flow +entering the network at each ingress point and destined for each egress +point. The operator may then want to put in place a specific routing of +ingress-to-egress flows that minimizes the maximum utilization over all +of the network's links. But with a routing algorithm such as OSPF, the +operator's main "knobs" for tuning the routing of flows through the +network are the link weights. Thus, in order to achieve the goal of +minimizing the maximum link utilization, the operator must find the set +of link weights that achieves this goal. This is a reversal of the cause +and effect relationship---the desired routing of flows is known, and the +OSPF link weights must be found such that the OSPF routing algorithm +results in this desired routing of flows. + +thus achieving minimum-hop routing, or might choose to set the link +weights to be inversely proportional to link capacity in order to +discourage traffic from using low-bandwidth links. OSPF does not mandate +a policy for how link weights are set (that is the job of the network +administrator), but instead provides + + the mechanisms (protocol) for determining least-cost path routing for +the given set of link weights. With OSPF, a router broadcasts routing +information to all other routers in the autonomous system, not just to +its neighboring routers. A router broadcasts link-state information +whenever there is a change in a link's state (for example, a change in +cost or a change in up/down status). It also broadcasts a link's state +periodically (at least once every 30 minutes), even if the link's state +has not changed. RFC 2328 notes that "this periodic updating of link +state advertisements adds robustness to the link state algorithm." OSPF +advertisements are contained in OSPF messages that are carried directly +by IP, with an upper-layer protocol of 89 for OSPF. Thus, the OSPF +protocol must itself implement functionality such as reliable message +transfer and link-state broadcast. The OSPF protocol also checks that +links are operational (via a HELLO message that is sent to an attached +neighbor) and allows an OSPF router to obtain a neighboring router's +database of network-wide link state. Some of the advances embodied in +OSPF include the following: Security. Exchanges between OSPF routers +(for example, link-state updates) can be authenticated. With +authentication, only trusted routers can participate in the OSPF +protocol within an AS, thus preventing malicious intruders (or +networking students taking their newfound knowledge out for a joyride) +from injecting incorrect information into router tables. By default, +OSPF packets between routers are not authenticated and could be forged. +Two types of authentication can be configured--- simple and MD5 (see +Chapter 8 for a discussion on MD5 and authentication in general). With +simple authentication, the same password is configured on each router. +When a router sends an OSPF packet, it includes the password in +plaintext. Clearly, simple authentication is not very secure. MD5 +authentication is based on shared secret keys that are configured in all +the routers. For each OSPF packet that it sends, the router computes the +MD5 hash of the content of the OSPF packet appended with the secret key. +(See the discussion of message authentication codes in Chapter 8.) Then +the router includes the resulting hash value in the OSPF packet. The +receiving router, using the preconfigured secret key, will compute an +MD5 hash of the packet and compare it with the hash value that the +packet carries, thus verifying the packet's authenticity. Sequence +numbers are also used with MD5 authentication to protect against replay +attacks. Multiple same-cost paths. When multiple paths to a destination +have the same cost, OSPF allows multiple paths to be used (that is, a +single path need not be chosen for carrying all traffic when multiple +equal-cost paths exist). Integrated support for unicast and multicast +routing. Multicast OSPF (MOSPF) \[RFC 1584\] provides simple extensions +to OSPF to provide for multicast routing. MOSPF uses the existing OSPF +link database and adds a new type of link-state advertisement to the +existing OSPF link-state broadcast mechanism. Support for hierarchy +within a single AS. An OSPF autonomous system can be configured +hierarchically into areas. Each area runs its own OSPF link-state +routing algorithm, with each router in an area broadcasting its link +state to all other routers in that area. Within each area, one or more + + area border routers are responsible for routing packets outside the +area. Lastly, exactly one OSPF area in the AS is configured to be the +backbone area. The primary role of the backbone area is to route traffic +between the other areas in the AS. The backbone always contains all area +border routers in the AS and may contain non-border routers as well. +Inter-area routing within the AS requires that the packet be first +routed to an area border router (intra-area routing), then routed +through the backbone to the area border router that is in the +destination area, and then routed to the final destination. OSPF is a +relatively complex protocol, and our coverage here has been necessarily +brief; \[Huitema 1998; Moy 1998; RFC 2328\] provide additional details. + + 5.4 Routing Among the ISPs: BGP We just learned that OSPF is an example +of an intra-AS routing protocol. When routing a packet between a source +and destination within the same AS, the route the packet follows is +entirely determined by the intra-AS routing protocol. However, to route +a packet across multiple ASs, say from a smartphone in Timbuktu to a +server in a datacenter in Silicon Valley, we need an inter-autonomous +system routing protocol. Since an inter-AS routing protocol involves +coordination among multiple ASs, communicating ASs must run the same +inter-AS routing protocol. In fact, in the Internet, all ASs run the +same inter-AS routing protocol, called the Border Gateway Protocol, more +commonly known as BGP \[RFC 4271; Stewart 1999\]. BGP is arguably the +most important of all the Internet protocols (the only other contender +would be the IP protocol that we studied in Section 4.3), as it is the +protocol that glues the thousands of ISPs in the Internet together. As +we will soon see, BGP is a decentralized and asynchronous protocol in +the vein of distance-vector routing described in Section 5.2.2. Although +BGP is a complex and challenging protocol, to understand the Internet on +a deep level, we need to become familiar with its underpinnings and +operation. The time we devote to learning BGP will be well worth the +effort. + +5.4.1 The Role of BGP To understand the responsibilities of BGP, +consider an AS and an arbitrary router in that AS. Recall that every +router has a forwarding table, which plays the central role in the +process of forwarding arriving packets to outbound router links. As we +have learned, for destinations that are within the same AS, the entries +in the router's forwarding table are determined by the AS's intra-AS +routing protocol. But what about destinations that are outside of the +AS? This is precisely where BGP comes to the rescue. In BGP, packets are +not routed to a specific destination address, but instead to CIDRized +prefixes, with each prefix representing a subnet or a collection of +subnets. In the world of BGP, a destination may take the form +138.16.68/22, which for this example includes 1,024 IP addresses. Thus, +a router's forwarding table will have entries of the form (x, I), where +x is a prefix (such as 138.16.68/22) and I is an interface number for +one of the router's interfaces. As an inter-AS routing protocol, BGP +provides each router a means to: + +1. Obtain prefix reachability information from neighboring ASs. In + particular, BGP allows each + + subnet to advertise its existence to the rest of the Internet. A subnet +screams, "I exist and I am here," and BGP makes sure that all the +routers in the Internet know about this subnet. If it weren't for BGP, +each subnet would be an isolated island---alone, unknown and unreachable +by the rest of the Internet. + +2. Determine the "best" routes to the prefixes. A router may learn + about two or more different routes to a specific prefix. To + determine the best route, the router will locally run a BGP + routeselection procedure (using the prefix reachability information + it obtained via neighboring routers). The best route will be + determined based on policy as well as the reachability information. + Let us now delve into how BGP carries out these two tasks. + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + +5.4.2 Advertising BGP Route Information Consider the network shown in +Figure 5.8. As we can see, this simple network has three autonomous +systems: AS1, AS2, and AS3. As shown, AS3 includes a subnet with prefix +x. For each AS, each router is either a gateway router or an internal +router. A gateway router is a router on the edge of an AS that directly +connects to one or more routers in other ASs. An internal router +connects only to hosts and routers within its own AS. In AS1, for +example, router 1c is a gateway router; routers 1a, 1b, and 1d are +internal routers. Let's consider the task of advertising reachability +information for prefix x to all of the routers shown in Figure 5.8. At a +high level, this is straightforward. First, AS3 sends a BGP message to +AS2, saying that x exists and is in AS3; let's denote this message as +"AS3 x". Then AS2 sends a BGP message to AS1, saying that x exists and +that you can get to x by first passing through AS2 and then going to +AS3; let's denote that message as "AS2 AS3 x". In this manner, each of +the autonomous systems will not only learn about the existence of x, but +also learn about a path of autonomous systems that leads to x. Although +the discussion in the above paragraph about advertising BGP reachability +information should get the general idea across, it is not precise in the +sense that autonomous systems do not actually send messages to each +other, but instead routers do. To understand this, let's now re-examine +the example in Figure 5.8. In BGP, + + Figure 5.8 Network with three autonomous systems. AS3 includes a subnet +with prefix x + +pairs of routers exchange routing information over semi-permanent TCP +connections using port 179. Each such TCP connection, along with all the +BGP messages sent over the connection, is called a BGP connection. +Furthermore, a BGP connection that spans two ASs is called an external +BGP (eBGP) connection, and a BGP session between routers in the same AS +is called an internal BGP (iBGP) connection. Examples of BGP connections +for the network in Figure 5.8 are shown in Figure 5.9. There is +typically one eBGP connection for each link that directly connects +gateway routers in different ASs; thus, in Figure 5.9, there is an eBGP +connection between gateway routers 1c and 2a and an eBGP connection +between gateway routers 2c and 3a. There are also iBGP connections +between routers within each of the ASs. In particular, Figure 5.9 +displays a common configuration of one BGP connection for each pair of +routers internal to an AS, creating a mesh of TCP connections within +each AS. In Figure 5.9, the eBGP connections are shown with the long +dashes; the iBGP connections are shown with the short dashes. Note that +iBGP connections do not always correspond to physical links. In order to +propagate the reachability information, both iBGP and eBGP sessions are +used. Consider again advertising the reachability information for prefix +x to all routers in AS1 and AS2. In this process, gateway router 3a +first sends an eBGP message "AS3 x" to gateway router 2c. Gateway router +2c then sends the iBGP message "AS3 x" to all of the other routers in +AS2, including to gateway router 2a. Gateway router 2a then sends the +eBGP message "AS2 AS3 x" to gateway router 1c. + + Figure 5.9 eBGP and iBGP connections + +Finally, gateway router 1c uses iBGP to send the message "AS2 AS3 x" to +all the routers in AS1. After this process is complete, each router in +AS1 and AS2 is aware of the existence of x and is also aware of an AS +path that leads to x. Of course, in a real network, from a given router +there may be many different paths to a given destination, each through a +different sequence of ASs. For example, consider the network in Figure +5.10, which is the original network in Figure 5.8, with an additional +physical link from router 1d to router 3d. In this case, there are two +paths from AS1 to x: the path "AS2 AS3 x" via router 1c; and the new +path "AS3 x" via the router 1d. + +5.4.3 Determining the Best Routes As we have just learned, there may be +many paths from a given router to a destination subnet. In fact, in the +Internet, routers often receive reachability information about dozens of +different possible paths. How does a router choose among these paths +(and then configure its forwarding table accordingly)? Before addressing +this critical question, we need to introduce a little more BGP +terminology. When a router advertises a prefix across a BGP connection, +it includes with the prefix several BGP attributes. In BGP jargon, a +prefix along with its attributes is called a route. Two of the more +important attributes are AS-PATH and NEXT-HOP. The AS-PATH attribute +contains the list of ASs through which the + + Figure 5.10 Network augmented with peering link between AS1 and AS3 + +advertisement has passed, as we've seen in our examples above. To +generate the AS-PATH value, when a prefix is passed to an AS, the AS +adds its ASN to the existing list in the AS-PATH. For example, in Figure +5.10, there are two routes from AS1 to subnet x: one which uses the +AS-PATH "AS2 AS3"; and another that uses the AS-PATH "A3". BGP routers +also use the AS-PATH attribute to detect and prevent looping +advertisements; specifically, if a router sees that its own AS is +contained in the path list, it will reject the advertisement. Providing +the critical link between the inter-AS and intra-AS routing protocols, +the NEXT-HOP attribute has a subtle but important use. The NEXT-HOP is +the IP address of the router interface that begins the AS-PATH. To gain +insight into this attribute, let's again refer to Figure 5.10. As +indicated in Figure 5.10, the NEXT-HOP attribute for the route "AS2 AS3 +x" from AS1 to x that passes through AS2 is the IP address of the left +interface on router 2a. The NEXT-HOP attribute for the route "AS3 x" +from AS1 to x that bypasses AS2 is the IP address of the leftmost +interface of router 3d. In summary, in this toy example, each router in +AS1 becomes aware of two BGP routes to prefix x: IP address of leftmost +interface for router 2a; AS2 AS3; x IP address of leftmost interface of +router 3d; AS3; x Here, each BGP route is written as a list with three +components: NEXT-HOP; AS-PATH; destination prefix. In practice, a BGP +route includes additional attributes, which we will ignore for the time +being. Note that the NEXT-HOP attribute is an IP address of a router +that does not belong to AS1; however, the subnet that contains this IP +address directly attaches to AS1. Hot Potato Routing + + We are now finally in position to talk about BGP routing algorithms in a +precise manner. We will begin with one of the simplest routing +algorithms, namely, hot potato routing. Consider router 1b in the +network in Figure 5.10. As just described, this router will learn about +two possible BGP routes to prefix x. In hot potato routing, the route +chosen (from among all possible routes) is that route with the least +cost to the NEXT-HOP router beginning that route. In this example, +router 1b will consult its intra-AS routing information to find the +least-cost intra-AS path to NEXT-HOP router 2a and the least-cost +intra-AS path to NEXT-HOP router 3d, and then select the route with the +smallest of these least-cost paths. For example, suppose that cost is +defined as the number of links traversed. Then the least cost from +router 1b to router 2a is 2, the least cost from router 1b to router 2d +is 3, and router 2a would therefore be selected. Router 1b would then +consult its forwarding table (configured by its intra-AS algorithm) and +find the interface I that is on the least-cost path to router 2a. It +then adds (x, I) to its forwarding table. The steps for adding an +outside-AS prefix in a router's forwarding table for hot potato routing +are summarized in Figure 5.11. It is important to note that when adding +an outside-AS prefix into a forwarding table, both the inter-AS routing +protocol (BGP) and the intra-AS routing protocol (e.g., OSPF) are used. +The idea behind hot-potato routing is for router 1b to get packets out +of its AS as quickly as possible (more specifically, with the least cost +possible) without worrying about the cost of the remaining portions of +the path outside of its AS to the destination. In the name "hot potato +routing," a packet is analogous to a hot potato that is burning in your +hands. Because it is burning hot, you want to pass it off to another +person (another AS) as quickly as possible. Hot potato routing is thus + +Figure 5.11 Steps in adding outside-AS destination in a router's +forwarding table + +a selfish algorithm---it tries to reduce the cost in its own AS while +ignoring the other components of the end-to-end costs outside its AS. +Note that with hot potato routing, two routers in the same AS may choose +two different AS paths to the same prefix. For example, we just saw that +router 1b would send packets through AS2 to reach x. However, router 1d +would bypass AS2 and send packets directly to AS3 to reach x. +Route-Selection Algorithm + + In practice, BGP uses an algorithm that is more complicated than hot +potato routing, but nevertheless incorporates hot potato routing. For +any given destination prefix, the input into BGP's route-selection +algorithm is the set of all routes to that prefix that have been learned +and accepted by the router. If there is only one such route, then BGP +obviously selects that route. If there are two or more routes to the +same prefix, then BGP sequentially invokes the following elimination +rules until one route remains: + +1. A route is assigned a local preference value as one of its + attributes (in addition to the AS-PATH and NEXT-HOP attributes). The + local preference of a route could have been set by the router or + could have been learned from another router in the same AS. The + value of the local preference attribute is a policy decision that is + left entirely up to the AS's network administrator. (We will shortly + discuss BGP policy issues in some detail.) The routes with the + highest local preference values are selected. + +2. From the remaining routes (all with the same highest local + preference value), the route with the shortest AS-PATH is selected. + If this rule were the only rule for route selection, then BGP would + be using a DV algorithm for path determination, where the distance + metric uses the number of AS hops rather than the number of router + hops. + +3. From the remaining routes (all with the same highest local + preference value and the same ASPATH length), hot potato routing is + used, that is, the route with the closest NEXT-HOP router is + selected. + +4. If more than one route still remains, the router uses BGP + identifiers to select the route; see \[Stewart 1999\]. As an + example, let's again consider router 1b in Figure 5.10. Recall that + there are exactly two BGP routes to prefix x, one that passes + through AS2 and one that bypasses AS2. Also recall that if hot + potato routing on its own were used, then BGP would route packets + through AS2 to prefix x. But in the above route-selection algorithm, + rule 2 is applied before rule 3, causing BGP to select the route + that bypasses AS2, since that route has a shorter AS PATH. So we see + that with the above route-selection algorithm, BGP is no longer a + selfish algorithm---it first looks for routes with short AS paths + (thereby likely reducing end-to-end delay). As noted above, BGP is + the de facto standard for inter-AS routing for the Internet. To see + the contents of various BGP routing tables (large!) extracted from + routers in tier-1 ISPs, see http:// www.routeviews.org. BGP routing + tables often contain over half a million routes (that is, prefixes + and corresponding attributes). Statistics about the size and + characteristics of BGP routing tables are presented in \[Potaroo + 2016\]. + +5.4.4 IP-Anycast + + In addition to being the Internet's inter-AS routing protocol, BGP is +often used to implement the IPanycast service \[RFC 1546, RFC 7094\], +which is commonly used in DNS. To motivate IP-anycast, consider that in +many applications, we are interested in (1) replicating the same content +on different servers in many different dispersed geographical locations, +and (2) having each user access the content from the server that is +closest. For example, a CDN may replicate videos and other objects on +servers in different countries. Similarly, the DNS system can replicate +DNS records on DNS servers throughout the world. When a user wants to +access this replicated content, it is desirable to point the user to the +"nearest" server with the replicated content. BGP's route-selection +algorithm provides an easy and natural mechanism for doing so. To make +our discussion concrete, let's describe how a CDN might use IP-anycast. +As shown in Figure 5.12, during the IP-anycast configuration stage, the +CDN company assigns the same IP address to each of its servers, and uses +standard BGP to advertise this IP address from each of the servers. When +a BGP router receives multiple route advertisements for this IP address, +it treats these advertisements as providing different paths to the same +physical location (when, in fact, the advertisements are for different +paths to different physical locations). When configuring its routing +table, each router will locally use the BGP route-selection algorithm to +pick the "best" (for example, closest, as determined by AS-hop counts) +route to that IP address. For example, if one BGP route (corresponding +to one location) is only one AS hop away from the router, and all other +BGP routes (corresponding to other locations) are two or more AS hops +away, then the BGP router would choose to route packets to the location +that is one hop away. After this initial BGP address-advertisement +phase, the CDN can do its main job of distributing content. When a +client requests the video, the CDN returns to the client the common IP +address used by the geographically dispersed servers, no matter where +the client is located. When the client sends a request to that IP +address, Internet routers then forward the request packet to the +"closest" server, as defined by the BGP route-selection algorithm. +Although the above CDN example nicely illustrates how IP-anycast can be +used, in practice CDNs generally choose not to use IP-anycast because +BGP routing changes can result in different packets of the same TCP +connection arriving at different instances of the Web server. But +IP-anycast is extensively used by the DNS system to direct DNS queries +to the closest root DNS server. Recall from Section 2.4, there are +currently 13 IP addresses for root DNS servers. But corresponding + + Figure 5.12 Using IP-anycast to bring users to the closest CDN server + +to each of these addresses, there are multiple DNS root servers, with +some of these addresses having over 100 DNS root servers scattered over +all corners of the world. When a DNS query is sent to one of these 13 IP +addresses, IP anycast is used to route the query to the nearest of the +DNS root servers that is responsible for that address. + +5.4.5 Routing Policy When a router selects a route to a destination, the +AS routing policy can trump all other considerations, such as shortest +AS path or hot potato routing. Indeed, in the route-selection algorithm, +routes are first selected according to the local-preference attribute, +whose value is fixed by the policy of the local AS. Let's illustrate +some of the basic concepts of BGP routing policy with a simple example. +Figure 5.13 shows six interconnected autonomous systems: A, B, C, W, X, +and Y. It is important to note that A, B, C, W, X, and Y are ASs, not +routers. Let's + + Figure 5.13 A simple BGP policy scenario + +assume that autonomous systems W, X, and Y are access ISPs and that A, +B, and C are backbone provider networks. We'll also assume that A, B, +and C, directly send traffic to each other, and provide full BGP +information to their customer networks. All traffic entering an ISP +access network must be destined for that network, and all traffic +leaving an ISP access network must have originated in that network. W +and Y are clearly access ISPs. X is a multi-homed access ISP, since it +is connected to the rest of the network via two different providers (a +scenario that is becoming increasingly common in practice). However, +like W and Y, X itself must be the source/destination of all traffic +leaving/entering X. But how will this stub network behavior be +implemented and enforced? How will X be prevented from forwarding +traffic between B and C? This can easily be accomplished by controlling +the manner in which BGP routes are advertised. In particular X will +function as an access ISP network if it advertises (to its neighbors B +and C) that it has no paths to any other destinations except itself. +That is, even though X may know of a path, say XCY, that reaches network +Y, it will not advertise this path to B. Since B is unaware that X has a +path to Y, B would never forward traffic destined to Y (or C) via X. +This simple example illustrates how a selective route advertisement +policy can be used to implement customer/provider routing relationships. +Let's next focus on a provider network, say AS B. Suppose that B has +learned (from A) that A has a path AW to W. B can thus install the route +AW into its routing information base. Clearly, B also wants to advertise +the path BAW to its customer, X, so that X knows that it can route to W +via B. But should B advertise the path BAW to C? If it does so, then C +could route traffic to W via BAW. If A, B, and C are all backbone +providers, than B might rightly feel that it should not have to shoulder +the burden (and cost!) of carrying transit traffic between A and C. B +might rightly feel that it is A's and C's job (and cost!) to make sure +that C can route to/from A's customers via a direct connection between A +and C. There are currently no official standards that govern how +backbone ISPs route among themselves. However, a rule of thumb followed +by commercial ISPs is that any traffic flowing across an ISP's backbone +network must have either a source or a destination (or both) in a +network that is a customer of that ISP; otherwise the traffic would be +getting a free ride on the ISP's network. Individual peering agreements +(that would govern questions such as + +PRINCIPLES IN PRACTICE + + WHY ARE THERE DIFFERENT INTER-AS AND INTRA-AS ROUTING PROTOCOLS? Having +now studied the details of specific inter-AS and intra-AS routing +protocols deployed in today's Internet, let's conclude by considering +perhaps the most fundamental question we could ask about these protocols +in the first place (hopefully, you have been wondering this all along, +and have not lost the forest for the trees!): Why are different inter-AS +and intra-AS routing protocols used? The answer to this question gets at +the heart of the differences between the goals of routing within an AS +and among ASs: Policy. Among ASs, policy issues dominate. It may well be +important that traffic originating in a given AS not be able to pass +through another specific AS. Similarly, a given AS may well want to +control what transit traffic it carries between other ASs. We have seen +that BGP carries path attributes and provides for controlled +distribution of routing information so that such policy-based routing +decisions can be made. Within an AS, everything is nominally under the +same administrative control, and thus policy issues play a much less +important role in choosing routes within the AS. Scale. The ability of a +routing algorithm and its data structures to scale to handle routing +to/among large numbers of networks is a critical issue in inter-AS +routing. Within an AS, scalability is less of a concern. For one thing, +if a single ISP becomes too large, it is always possible to divide it +into two ASs and perform inter-AS routing between the two new ASs. +(Recall that OSPF allows such a hierarchy to be built by splitting an AS +into areas.) Performance. Because inter-AS routing is so policy +oriented, the quality (for example, performance) of the routes used is +often of secondary concern (that is, a longer or more costly route that +satisfies certain policy criteria may well be taken over a route that is +shorter but does not meet that criteria). Indeed, we saw that among ASs, +there is not even the notion of cost (other than AS hop count) +associated with routes. Within a single AS, however, such policy +concerns are of less importance, allowing routing to focus more on the +level of performance realized on a route. + +those raised above) are typically negotiated between pairs of ISPs and +are often confidential; \[Huston 1999a\] provides an interesting +discussion of peering agreements. For a detailed description of how +routing policy reflects commercial relationships among ISPs, see \[Gao +2001; Dmitiropoulos 2007\]. For a discussion of BGP routing polices from +an ISP standpoint, see \[Caesar 2005b\]. This completes our brief +introduction to BGP. Understanding BGP is important because it plays a +central role in the Internet. We encourage you to see the references +\[Griffin 2012; Stewart 1999; Labovitz 1997; Halabi 2000; Huitema 1998; +Gao 2001; Feamster 2004; Caesar 2005b; Li 2007\] to learn more about +BGP. + + 5.4.6 Putting the Pieces Together: Obtaining Internet Presence Although +this subsection is not about BGP per se, it brings together many of the +protocols and concepts we've seen thus far, including IP addressing, +DNS, and BGP. Suppose you have just created a small company that has a +number of servers, including a public Web server that describes your +company's products and services, a mail server from which your employees +obtain their e-mail messages, and a DNS server. Naturally, you would +like the entire world to be able to visit your Web site in order to +learn about your exciting products and services. Moreover, you would +like your employees to be able to send and receive e-mail to potential +customers throughout the world. To meet these goals, you first need to +obtain Internet connectivity, which is done by contracting with, and +connecting to, a local ISP. Your company will have a gateway router, +which will be connected to a router in your local ISP. This connection +might be a DSL connection through the existing telephone infrastructure, +a leased line to the ISP's router, or one of the many other access +solutions described in Chapter 1. Your local ISP will also provide you +with an IP address range, e.g., a /24 address range consisting of 256 +addresses. Once you have your physical connectivity and your IP address +range, you will assign one of the IP addresses (in your address range) +to your Web server, one to your mail server, one to your DNS server, one +to your gateway router, and other IP addresses to other servers and +networking devices in your company's network. In addition to contracting +with an ISP, you will also need to contract with an Internet registrar +to obtain a domain name for your company, as described in Chapter 2. For +example, if your company's name is, say, Xanadu Inc., you will naturally +try to obtain the domain name xanadu.com. Your company must also obtain +presence in the DNS system. Specifically, because outsiders will want to +contact your DNS server to obtain the IP addresses of your servers, you +will also need to provide your registrar with the IP address of your DNS +server. Your registrar will then put an entry for your DNS server +(domain name and corresponding IP address) in the .com top-level-domain +servers, as described in Chapter 2. After this step is completed, any +user who knows your domain name (e.g., xanadu.com) will be able to +obtain the IP address of your DNS server via the DNS system. So that +people can discover the IP addresses of your Web server, in your DNS +server you will need to include entries that map the host name of your +Web server (e.g., www.xanadu.com) to its IP address. You will want to +have similar entries for other publicly available servers in your +company, including your mail server. In this manner, if Alice wants to +browse your Web server, the DNS system will contact your DNS server, +find the IP address of your Web server, and give it to Alice. Alice can +then establish a TCP connection directly with your Web server. However, +there still remains one other necessary and crucial step to allow +outsiders from around the + + world to access your Web server. Consider what happens when Alice, who +knows the IP address of your Web server, sends an IP datagram (e.g., a +TCP SYN segment) to that IP address. This datagram will be routed +through the Internet, visiting a series of routers in many different +ASs, and eventually reach your Web server. When any one of the routers +receives the datagram, it is going to look for an entry in its +forwarding table to determine on which outgoing port it should forward +the datagram. Therefore, each of the routers needs to know about the +existence of your company's /24 prefix (or some aggregate entry). How +does a router become aware of your company's prefix? As we have just +seen, it becomes aware of it from BGP! Specifically, when your company +contracts with a local ISP and gets assigned a prefix (i.e., an address +range), your local ISP will use BGP to advertise your prefix to the ISPs +to which it connects. Those ISPs will then, in turn, use BGP to +propagate the advertisement. Eventually, all Internet routers will know +about your prefix (or about some aggregate that includes your prefix) +and thus be able to appropriately forward datagrams destined to your Web +and mail servers. + + 5.5 The SDN Control Plane In this section, we'll dive into the SDN +control plane---the network-wide logic that controls packet forwarding +among a network's SDN-enabled devices, as well as the configuration and +management of these devices and their services. Our study here builds on +our earlier discussion of generalized SDN forwarding in Section 4.4, so +you might want to first review that section, as well as Section 5.1 of +this chapter, before continuing on. As in Section 4.4, we'll again adopt +the terminology used in the SDN literature and refer to the network's +forwarding devices as "packet switches" (or just switches, with "packet" +being understood), since forwarding decisions can be made on the basis +of network-layer source/destination addresses, link-layer +source/destination addresses, as well as many other values in +transport-, network-, and link-layer packet-header fields. Four key +characteristics of an SDN architecture can be identified \[Kreutz +2015\]: Flow-based forwarding. Packet forwarding by SDN-controlled +switches can be based on any number of header field values in the +transport-layer, network-layer, or link-layer header. We saw in Section +4.4 that the OpenFlow1.0 abstraction allows forwarding based on eleven +different header field values. This contrasts sharply with the +traditional approach to router-based forwarding that we studied in +Sections 5.2--5.4, where forwarding of IP datagrams was based solely on +a datagram's destination IP address. Recall from Figure 5.2 that packet +forwarding rules are specified in a switch's flow table; it is the job +of the SDN control plane to compute, manage and install flow table +entries in all of the network's switches. Separation of data plane and +control plane. This separation is shown clearly in Figures 5.2 and 5.14. +The data plane consists of the network's switches--- relatively simple +(but fast) devices that execute the "match plus action" rules in their +flow tables. The control plane consists of servers and software that +determine and manage the switches' flow tables. Network control +functions: external to data-plane switches. Given that the "S" in SDN is +for "software," it's perhaps not surprising that the SDN control plane +is implemented in software. Unlike traditional routers, however, this +software executes on servers that are both distinct and remote from the +network's switches. As shown in Figure 5.14, the control plane itself +consists of two components ---an SDN controller (or network operating +system \[Gude 2008\]) and a set of network-control applications. The +controller maintains accurate network state information (e.g., the state +of remote links, switches, and hosts); provides this information to the +network-control applications running in the control plane; and provides +the means through which these applications can monitor, program, and +control the underlying network devices. Although the controller in +Figure 5.14 is shown as a single central server, in practice the +controller is only logically centralized; it is typically implemented on +several servers that provide coordinated, scalable performance and high +availability. + + A programmable network. The network is programmable through the +network-control applications running in the control plane. These +applications represent the "brains" of the SDN control plane, using the +APIs provided by the SDN controller to specify and control the data +plane in the network devices. For example, a routing network-control +application might determine the end-end paths between sources and +destinations (e.g., by executing Dijkstra's algorithm using the +node-state and link-state information maintained by the SDN controller). +Another network application might perform access control, i.e., +determine which packets are to be blocked at a switch, as in our third +example in Section 4.4.3. Yet another application might forward packets +in a manner that performs server load balancing (the second example we +considered in Section 4.4.3). From this discussion, we can see that SDN +represents a significant "unbundling" of network functionality ---data +plane switches, SDN controllers, and network-control applications are +separate entities that may each be provided by different vendors and +organizations. This contrasts with the pre-SDN model in which a +switch/router (together with its embedded control plane software and +protocol implementations) was monolithic, vertically integrated, and +sold by a single vendor. This unbundling of network functionality in SDN +has been likened to the earlier evolution from mainframe computers +(where hardware, system software, and applications were provided by a +single vendor) to personal computers (with their separate hardware, +operating systems, and applications). The unbundling of computing +hardware, system software, and applications has arguably led to a rich, +open ecosystem driven by innovation in all three of these areas; one +hope for SDN is that it too will lead to a such rich innovation. Given +our understanding of the SDN architecture of Figure 5.14, many questions +naturally arise. How and where are the flow tables actually computed? +How are these tables updated in response to events at SDN-controlled +devices (e.g., an attached link going up/down)? And how are the flow +table entries at multiple switches coordinated in such a way as to +result in orchestrated and consistent network-wide functionality (e.g., +end-to-end paths for forwarding packets from sources to destinations, or +coordinated distributed firewalls)? It is the role of the SDN control +plane to provide these, and many other, capabilities. + + Figure 5.14 Components of the SDN architecture: SDN-controlled switches, +the SDN controller, network-control applications + +5.5.2 The SDN Control Plane: SDN Controller and SDN Network-control +Applications Let's begin our discussion of the SDN control plane in the +abstract, by considering the generic capabilities that the control plane +must provide. As we'll see, this abstract, "first principles" approach +will lead us to an overall architecture that reflects how SDN control +planes have been implemented in practice. As noted above, the SDN +control plane divides broadly into two components---the SDN controller +and the SDN network-control applications. Let's explore the controller +first. Many SDN controllers have been developed since the earliest SDN +controller \[Gude 2008\]; see \[Kreutz 2015\] for an extremely thorough +and up-to-date survey. Figure 5.15 provides a more detailed view of a +generic SDN controller. A controller's functionality can be broadly +organized into three layers. Let's consider these layers in an +uncharacteristically bottom-up fashion: A communication layer: +communicating between the SDN controller and controlled network devices. +Clearly, if an SDN controller is going to control the operation of a +remote SDN-enabled + + switch, host, or other device, a protocol is needed to transfer +information between the controller and that device. In addition, a +device must be able to communicate locally-observed events to the +controller (e.g., a message indicating that an attached link has gone up +or down, that a device has just joined the network, or a heartbeat +indicating that a device is up and operational). These events provide +the SDN controller with an up-to-date view of the network's state. This +protocol constitutes the lowest layer of the controller architecture, as +shown in Figure 5.15. The communication between the controller and the +controlled devices cross what has come to be known as the controller's +"southbound" interface. In Section 5.5.2, we'll study OpenFlow---a +specific protocol that provides this communication functionality. +OpenFlow is implemented in most, if not all, SDN controllers. A +network-wide state-management layer. The ultimate control decisions made +by the SDN control plane---e.g., configuring flow tables in all switches +to achieve the desired end-end forwarding, to implement load balancing, +or to implement a particular firewalling capability---will require that +the controller have up-to-date information about state of the networks' +hosts, links, switches, and other SDN-controlled devices. A switch's +flow table contains counters whose values might also be profitably used +by network-control applications; these values should thus be available +to the applications. Since the ultimate aim of the control plane is to +determine flow tables for the various controlled devices, a controller +might also maintain a copy of these tables. These pieces of information +all constitute examples of the network-wide "state" maintained by the +SDN controller. The interface to the network-control application layer. +The controller interacts with networkcontrol applications through its +"northbound" interface. This API + + Figure 5.15 Components of an SDN controller + +allows network-control applications to read/write network state and flow +tables within the statemanagement layer. Applications can register to be +notified when state-change events occur, so that they can take actions +in response to network event notifications sent from SDN-controlled +devices. Different types of APIs may be provided; we'll see that two +popular SDN controllers communicate with their applications using a REST +\[Fielding 2000\] request-response interface. We have noted several +times that an SDN controller can be considered to be "logically +centralized," i.e., that the controller may be viewed externally (e.g., +from the point of view of SDN-controlled devices and external +network-control applications) as a single, monolithic service. However, +these services and the databases used to hold state information are +implemented in practice by a distributed set of servers for fault +tolerance, high availability, or for performance reasons. With +controller functions being implemented by a set of servers, the +semantics of the controller's internal operations (e.g., maintaining +logical time ordering of events, consistency, consensus, and more) must +be considered \[Panda 2013\]. + + Such concerns are common across many different distributed systems; see +\[Lamport 1989, Lampson 1996\] for elegant solutions to these +challenges. Modern controllers such as OpenDaylight \[OpenDaylight +Lithium 2016\] and ONOS \[ONOS 2016\] (see sidebar) have placed +considerable emphasis on architecting a logically centralized but +physically distributed controller platform that provides scalable +services and high availability to the controlled devices and +network-control applications alike. The architecture depicted in Figure +5.15 closely resembles the architecture of the originally proposed NOX +controller in 2008 \[Gude 2008\], as well as that of today's +OpenDaylight \[OpenDaylight Lithium 2016\] and ONOS \[ONOS 2016\] SDN +controllers (see sidebar). We'll cover an example of controller +operation in Section 5.5.3. First, however, let's examine the OpenFlow +protocol, which lies in the controller's communication layer. + +5.5.2 OpenFlow Protocol The OpenFlow protocol \[OpenFlow 2009, ONF +2016\] operates between an SDN controller and an SDN-controlled switch +or other device implementing the OpenFlow API that we studied earlier in +Section 4.4. The OpenFlow protocol operates over TCP, with a default +port number of 6653. Among the important messages flowing from the +controller to the controlled switch are the following: Configuration. +This message allows the controller to query and set a switch's +configuration parameters. Modify-State. This message is used by a +controller to add/delete or modify entries in the switch's flow table, +and to set switch port properties. Read-State. This message is used by a +controller to collect statistics and counter values from the switch's +flow table and ports. Send-Packet. This message is used by the +controller to send a specific packet out of a specified port at the +controlled switch. The message itself contains the packet to be sent in +its payload. Among the messages flowing from the SDN-controlled switch +to the controller are the following: Flow-Removed. This message informs +the controller that a flow table entry has been removed, for example by +a timeout or as the result of a received modify-state message. +Port-status. This message is used by a switch to inform the controller +of a change in port status. Packet-in. Recall from Section 4.4 that a +packet arriving at a switch port and not matching any flow table entry +is sent to the controller for additional processing. Matched packets may +also be sent to the controller, as an action to be taken on a match. The +packet-in message is used to send such packets to the controller. + + Additional OpenFlow messages are defined in \[OpenFlow 2009, ONF 2016\]. +Principles in Practice Google's Software-Defined Global Network Recall +from the case study in Section 2.6 that Google deploys a dedicated +wide-area network (WAN) that interconnects its data centers and server +clusters (in IXPs and ISPs). This network, called B4, has a +Google-designed SDN control plane built on OpenFlow. Google's network is +able to drive WAN links at near 70% utilization over the long run (a two +to three fold increase over typical link utilizations) and split +application flows among multiple paths based on application priority and +existing flow demands \[Jain 2013\]. The Google B4 network is +particularly it well-suited for SDN: (i) Google controls all devices +from the edge servers in IXPs and ISPs to routers in their network core; +(ii) the most bandwidthintensive applications are large-scale data +copies between sites that can defer to higher-priority interactive +applications during times of resource congestion; (iii) with only a few +dozen data centers being connected, centralized control is feasible. +Google's B4 network uses custom-built switches, each implementing a +slightly extended version of OpenFlow, with a local Open Flow Agent +(OFA) that is similar in spirit to the control agent we encountered in +Figure 5.2. Each OFA in turn connects to an Open Flow Controller (OFC) +in the network control server (NCS), using a separate "out of band" +network, distinct from the network that carries data-center traffic +between data centers. The OFC thus provides the services used by the NCS +to communicate with its controlled switches, similar in spirit to the +lowest layer in the SDN architecture shown in Figure 5.15. In B4, the +OFC also performs state management functions, keeping node and link +status in a Network Information Base (NIB). Google's implementation of +the OFC is based on the ONIX SDN controller \[Koponen 2010\]. Two +routing protocols, BGP (for routing between the data centers) and IS-IS +(a close relative of OSPF, for routing within a data center), are +implemented. Paxos \[Chandra 2007\] is used to execute hot replicas of +NCS components to protect against failure. A traffic engineering +network-control application, sitting logically above the set of network +control servers, interacts with these servers to provide global, +network-wide bandwidth provisioning for groups of application flows. +With B4, SDN made an important leap forward into the operational +networks of a global network provider. See \[Jain 2013\] for a detailed +description of B4. + +5.5.3 Data and Control Plane Interaction: An Example + + In order to solidify our understanding of the interaction between +SDN-controlled switches and the SDN controller, let's consider the +example shown in Figure 5.16, in which Dijkstra's algorithm (which we +studied in Section 5.2) is used to determine shortest path routes. The +SDN scenario in Figure 5.16 has two important differences from the +earlier per-router-control scenario of Sections 5.2.1 and 5.3, where +Dijkstra's algorithm was implemented in each and every router and +link-state updates were flooded among all network routers: Dijkstra's +algorithm is executed as a separate application, outside of the packet +switches. Packet switches send link updates to the SDN controller and +not to each other. In this example, let's assume that the link between +switch s1 and s2 goes down; that shortest path routing is implemented, +and consequently and that incoming and outgoing flow forwarding rules at +s1, s3, and s4 are affected, but that s2's + +Figure 5.16 SDN controller scenario: Link-state change + +operation is unchanged. Let's also assume that OpenFlow is used as the +communication layer protocol, and that the control plane performs no +other function other than link-state routing. + + 1. Switch s1, experiencing a link failure between itself and s2, +notifies the SDN controller of the link-state change using the OpenFlow +port-status message. + +2. The SDN controller receives the OpenFlow message indicating the + link-state change, and notifies the link-state manager, which + updates a link-state database. + +3. The network-control application that implements Dijkstra's + link-state routing has previously registered to be notified when + link state changes. That application receives the notification of + the link-state change. + +4. The link-state routing application interacts with the link-state + manager to get updated link state; it might also consult other + components in the state-management layer. It then computes the new + least-cost paths. + +5. The link-state routing application then interacts with the flow + table manager, which determines the flow tables to be updated. + +6. The flow table manager then uses the OpenFlow protocol to update + flow table entries at affected switches---s1 (which will now route + packets destined to s2 via s4), s2 (which will now begin receiving + packets from s1 via intermediate switch s4), and s4 (which must now + forward packets from s1 destined to s2). This example is simple but + illustrates how the SDN control plane provides control-plane + services (in this case network-layer routing) that had been + previously implemented with per-router control exercised in each and + every network router. One can now easily appreciate how an + SDN-enabled ISP could easily switch from least-cost path routing to + a more hand-tailored approach to routing. Indeed, since the + controller can tailor the flow tables as it pleases, it can + implement any form of forwarding that it pleases ---simply by + changing its application-control software. This ease of change + should be contrasted to the case of a traditional per-router control + plane, where software in all routers (which might be provided to the + ISP by multiple independent vendors) must be changed. + +5.5.4 SDN: Past and Future Although the intense interest in SDN is a +relatively recent phenomenon, the technical roots of SDN, and the +separation of the data and control planes in particular, go back +considerably further. In 2004, \[Feamster 2004, Lakshman 2004, RFC +3746\] all argued for the separation of the network's data and control +planes. \[van der Merwe 1998\] describes a control framework for ATM +networks \[Black 1995\] with multiple controllers, each controlling a +number of ATM switches. The Ethane project \[Casado 2007\] pioneered the +notion of a network of simple flow-based Ethernet switches with +match-plus-action flow tables, a centralized controller that managed +flow admission and routing, and the forwarding of unmatched packets from +the switch to the controller. A network of more than 300 Ethane switches +was operational in 2007. Ethane quickly evolved into the OpenFlow +project, and the rest (as the saying goes) is history! + + Numerous research efforts are aimed at developing future SDN +architectures and capabilities. As we have seen, the SDN revolution is +leading to the disruptive replacement of dedicated monolithic switches +and routers (with both data and control planes) by simple commodity +switching hardware and a sophisticated software control plane. A +generalization of SDN known as network functions virtualization (NFV) +similarly aims at disruptive replacement of sophisticated middleboxes +(such as middleboxes with dedicated hardware and proprietary software +for media caching/service) with simple commodity servers, switching, and +storage \[Gember-Jacobson 2014\]. A second area of important research +seeks to extend SDN concepts from the intra-AS setting to the inter-AS +setting \[Gupta 2014\]. PRINCIPLES IN PRACTICE SDN Controller Case +Studies: The OpenDaylight and ONOS Controllers In the earliest days of +SDN, there was a single SDN protocol (OpenFlow \[McKeown 2008; OpenFlow +2009\]) and a single SDN controller (NOX \[Gude 2008\]). Since then, the +number of SDN controllers in particular has grown significantly \[Kreutz +2015\]. Some SDN controllers are company-specific and proprietary, e.g., +ONIX \[Koponen 2010\], Juniper Networks Contrail \[Juniper Contrail +2016\], and Google's controller \[Jain 2013\] for its B4 wide-area +network. But many more controllers are open-source and implemented in a +variety of programming languages \[Erickson 2013\]. Most recently, the +OpenDaylight controller \[OpenDaylight Lithium 2016\] and the ONOS +controller \[ONOS 2016\] have found considerable industry support. They +are both open-source and are being developed in partnership with the +Linux Foundation. The OpenDaylight Controller Figure 5.17 presents a +simplified view of the OpenDaylight Lithium SDN controller platform +\[OpenDaylight Lithium 2016\]. ODL's main set of controller components +correspond closely to those we developed in Figure 5.15. Network-Service +Applications are the applications that determine how data-plane +forwarding and other services, such as firewalling and load balancing, +are accomplished in the controlled switches. Unlike the canonical +controller in Figure 5.15, the ODL controller has two interfaces through +which applications may communicate with native controller services and +each other: external applications communicate with controller modules +using a REST request-response API running over HTTP. Internal +applications communicate with each other via the Service Abstraction +Layer (SAL). The choice as to whether a controller application is +implemented externally or internally is up to the application designer; + + Figure 5.17 The OpenDaylight controller + +the particular configuration of applications shown in Figure 5.17 is +only meant as an example. ODL's Basic Network-Service Functions are at +the heart of the controller, and they correspond closely to the +network-wide state management capabilities that we encountered in Figure +5.15. The SAL is the controller's nerve center, allowing controller +components and applications to invoke each other's services and to +subscribe to events they generate. It also provides a uniform abstract +interface to the specific underlying communications protocols in the +communication layer, including OpenFlow and SNMP (the Simple Network +Management Protocol---a network management protocol that we will cover +in Section 5.7). OVSDB is a protocol used to manage data center +switching, an important application area for SDN technology. We'll +introduce data center networking in Chapter 6. + + Figure 5.18 ONOS controller architecture + +The ONOS Controller Figure 5.18 presents a simplified view of the ONOS +controller ONOS 2016\]. Similar to the canonical controller in Figure +5.15, three layers can be identified in the ONOS controller: Northbound +abstractions and protocols. A unique feature of ONOS is its intent +framework, which allows an application to request a high-level service +(e.g., to setup a connection between host A and Host B, or conversely to +not allow Host A and host B to communicate) without having to know the +details of how this service is performed. State information is provided +to network-control applications across the northbound API either +synchronously (via query) or asynchronously (via listener callbacks, +e.g., when network state changes). Distributed core. The state of the +network's links, hosts, and devices is maintained in ONOS's distributed +core. ONOS is deployed as a service on a set of interconnected servers, +with each server running an identical copy of the ONOS software; an +increased number of servers offers an increased service capacity. The +ONOS core provides the mechanisms for service replication and +coordination among instances, providing the applications above and the +network devices below with the abstraction of logically centralized core +services. + + Southbound abstractions and protocols. The southbound abstractions mask +the heterogeneity of the underlying hosts, links, switches, and +protocols, allowing the distributed core to be both device and protocol +agnostic. Because of this abstraction, the southbound interface below +the distributed core is logically higher than in our canonical +controller in Figure 5.14 or the ODL controller in Figure 5.17. + + 5.6 ICMP: The Internet Control Message Protocol The Internet Control +Message Protocol (ICMP), specified in \[RFC 792\], is used by hosts and +routers to communicate network-layer information to each other. The most +typical use of ICMP is for error reporting. For example, when running an +HTTP session, you may have encountered an error message such as +"Destination network unreachable." This message had its origins in ICMP. +At some point, an IP router was unable to find a path to the host +specified in your HTTP request. That router created and sent an ICMP +message to your host indicating the error. ICMP is often considered part +of IP, but architecturally it lies just above IP, as ICMP messages are +carried inside IP datagrams. That is, ICMP messages are carried as IP +payload, just as TCP or UDP segments are carried as IP payload. +Similarly, when a host receives an IP datagram with ICMP specified as +the upper-layer protocol (an upper-layer protocol number of 1), it +demultiplexes the datagram's contents to ICMP, just as it would +demultiplex a datagram's content to TCP or UDP. ICMP messages have a +type and a code field, and contain the header and the first 8 bytes of +the IP datagram that caused the ICMP message to be generated in the +first place (so that the sender can determine the datagram that caused +the error). Selected ICMP message types are shown in Figure 5.19. Note +that ICMP messages are used not only for signaling error conditions. The +well-known ping program sends an ICMP type 8 code 0 message to the +specified host. The destination host, seeing the echo request, sends +back a type 0 code 0 ICMP echo reply. Most TCP/IP implementations +support the ping server directly in the operating system; that is, the +server is not a process. Chapter 11 of \[Stevens 1990\] provides the +source code for the ping client program. Note that the client program +needs to be able to instruct the operating system to generate an ICMP +message of type 8 code 0. Another interesting ICMP message is the source +quench message. This message is seldom used in practice. Its original +purpose was to perform congestion control---to allow a congested router +to send an ICMP source quench message to a host to force + + Figure 5.19 ICMP message types + +that host to reduce its transmission rate. We have seen in Chapter 3 +that TCP has its own congestioncontrol mechanism that operates at the +transport layer, without the use of network-layer feedback such as the +ICMP source quench message. In Chapter 1 we introduced the Traceroute +program, which allows us to trace a route from a host to any other host +in the world. Interestingly, Traceroute is implemented with ICMP +messages. To determine the names and addresses of the routers between +source and destination, Traceroute in the source sends a series of +ordinary IP datagrams to the destination. Each of these datagrams +carries a UDP segment with an unlikely UDP port number. The first of +these datagrams has a TTL of 1, the second of 2, the third of 3, and so +on. The source also starts timers for each of the datagrams. When the +nth datagram arrives at the nth router, the nth router observes that the +TTL of the datagram has just expired. According to the rules of the IP +protocol, the router discards the datagram and sends an ICMP warning +message to the source (type 11 code 0). This warning message includes +the name of the router and its IP address. When this ICMP message +arrives back at the source, the source obtains the round-trip time from +the timer and the name and IP address of the nth router from the ICMP +message. How does a Traceroute source know when to stop sending UDP +segments? Recall that the source increments the TTL field for each +datagram it sends. Thus, one of the datagrams will eventually make it +all the way to the destination host. Because this datagram contains a +UDP segment with an unlikely port + + number, the destination host sends a port unreachable ICMP message (type +3 code 3) back to the source. When the source host receives this +particular ICMP message, it knows it does not need to send additional +probe packets. (The standard Traceroute program actually sends sets of +three packets with the same TTL; thus the Traceroute output provides +three results for each TTL.) In this manner, the source host learns the +number and the identities of routers that lie between it and the +destination host and the round-trip time between the two hosts. Note +that the Traceroute client program must be able to instruct the +operating system to generate UDP datagrams with specific TTL values and +must also be able to be notified by its operating system when ICMP +messages arrive. Now that you understand how Traceroute works, you may +want to go back and play with it some more. A new version of ICMP has +been defined for IPv6 in RFC 4443. In addition to reorganizing the +existing ICMP type and code definitions, ICMPv6 also added new types and +codes required by the new IPv6 functionality. These include the "Packet +Too Big" type and an "unrecognized IPv6 options" error code. + + 5.7 Network Management and SNMP Having now made our way to the end of +our study of the network layer, with only the link-layer before us, +we're well aware that a network consists of many complex, interacting +pieces of hardware and software ---from the links, switches, routers, +hosts, and other devices that comprise the physical components of the +network to the many protocols that control and coordinate these devices. +When hundreds or thousands of such components are brought together by an +organization to form a network, the job of the network administrator to +keep the network "up and running" is surely a challenge. We saw in +Section 5.5 that the logically centralized controller can help with this +process in an SDN context. But the challenge of network management has +been around long before SDN, with a rich set of network management tools +and approaches that help the network administrator monitor, manage, and +control the network. We'll study these tools and techniques in this +section. An often-asked question is "What is network management?" A +well-conceived, single-sentence (albeit a rather long run-on sentence) +definition of network management from \[Saydam 1996\] is: Network +management includes the deployment, integration, and coordination of the +hardware, software, and human elements to monitor, test, poll, +configure, analyze, evaluate, and control the network and element +resources to meet the real-time, operational performance, and Quality of +Service requirements at a reasonable cost. Given this broad definition, +we'll cover only the rudiments of network management in this +section---the architecture, protocols, and information base used by a +network administrator in performing their task. We'll not cover the +administrator's decision-making processes, where topics such as fault +identification \[Labovitz 1997; Steinder 2002; Feamster 2005; Wu 2005; +Teixeira 2006\], anomaly detection \[Lakhina 2005; Barford 2009\], +network design/engineering to meet contracted Service Level Agreements +(SLA's) \[Huston 1999a\], and more come into consideration. Our focus is +thus purposefully narrow; the interested reader should consult these +references, the excellent network-management text by Subramanian +\[Subramanian 2000\], and the more detailed treatment of network +management available on the Web site for this text. + +5.7.1 The Network Management Framework Figure 5.20 shows the key +components of network management: + + The managing server is an application, typically with a human in the +loop, running in a centralized network management station in the network +operations center (NOC). The managing server is the locus of activity +for network management; it controls the collection, processing, +analysis, and/or display of network management information. It is here +that actions are initiated to control network behavior and here that the +human network administrator interacts with the network's devices. A +managed device is a piece of network equipment (including its software) +that resides on a managed network. A managed device might be a host, +router, switch, middlebox, modem, thermometer, or other +network-connected device. There may be several so-called managed objects +within a managed device. These managed objects are the actual pieces of +hardware within the managed device (for example, a network interface +card is but one component of a host or router), and configuration +parameters for these hardware and software components (for example, an +intraAS routing protocol such as OSPF). Each managed object within a +managed device associated information that is collected into a +Management Information Base (MIB); we'll see that the values of these +pieces of information are available to (and in many cases able to be set +by) the managing server. A MIB object might be a counter, such as the +number of IP datagrams discarded at a router due to errors in an IP +datagram header, or the number of UDP segments received at a host; +descriptive information such as the version of the software running on a +DNS server; status information such as whether a particular device is +functioning correctly; or protocol-specific information such as a +routing path to a destination. MIB objects are specified in a data +description language known as SMI (Structure of Management Information) +\[RFC 2578; RFC 2579; RFC 2580\]. A formal definition language is used +to ensure that the syntax and semantics of the network management data +are well defined and unambiguous. Related MIB objects are gathered into +MIB modules. As of mid-2015, there were nearly 400 MIB modules defined +by RFCs, and a much larger number of vendor-specific (private) MIB +modules. Also resident in each managed device is a network management +agent, a process running in the managed device that communicates with +the managing server, + + Figure 5.20 Elements of network management: Managing server, managed +devices, MIB data, remote agents, SNMP + +taking local actions at the managed device under the command and control +of the managing server. The network management agent is similar to the +routing agent that we saw in Figure 5.2. The final component of a +network management framework is the network management protocol. The +protocol runs between the managing server and the managed devices, +allowing the managing server to query the status of managed devices and +indirectly take actions at these devices via its agents. Agents can use +the network management protocol to inform the managing server of +exceptional events (for example, component failures or violation of +performance thresholds). It's important to note that the network +management protocol does not itself manage the network. Instead, it +provides capabilities that a network administrator can use to manage +("monitor, test, poll, configure, analyze, evaluate, and control") the +network. This is a subtle, but important, distinction. In the following +section, we'll cover the Internet's SNMP (Simple Network Management +Protocol) protocol. + +5.7.2 The Simple Network Management Protocol (SNMP) + + The Simple Network Management Protocol version 2 (SNMPv2) \[RFC 3416\] +is an application-layer protocol used to convey network-management +control and information messages between a managing server and an agent +executing on behalf of that managing server. The most common usage of +SNMP is in a request-response mode in which an SNMP managing server +sends a request to an SNMP agent, who receives the request, performs +some action, and sends a reply to the request. Typically, a request will +be used to query (retrieve) or modify (set) MIB object values associated +with a managed device. A second common usage of SNMP is for an agent to +send an unsolicited message, known as a trap message, to a managing +server. Trap messages are used to notify a managing server of an +exceptional situation (e.g., a link interface going up or down) that has +resulted in changes to MIB object values. SNMPv2 defines seven types of +messages, known generically as protocol data units---PDUs---as shown in +Table 5.2 and described below. The format of the PDU is shown in Figure +5.21. The GetRequest , GetNextRequest, and GetBulkRequest PDUs are all +sent from a managing server to an agent to request the value of one or +more MIB objects at the agent's managed device. The MIB objects whose +values are being Table 5.2 SNMPv2 PDU types SNMPv2 PDU + +Sender-receiver + +Description + +manager-to- + +get value of one or more MIB object instances + +Type GetRequest + +agent GetNextRequest + +manager-to- + +get value of next MIB object instance in list or table + +agent GetBulkRequest + +InformRequest + +SetRequest + +manager-to- + +get values in large block of data, for example, values + +agent + +in a large table + +manager-to- + +inform remote managing entity of MIB values remote + +manager + +to its access + +manager-to- + +set value of one or more MIB object instances + +agent Response + +agent-to- + +generated in response to + +manager or manager-tomanager + +GetRequest, + + GetNextRequest, GetBulkRequest, SetRequest PDU, or InformRequest +SNMPv2-Trap + +agent-to- + +inform manager of an exceptional event \# + +manager + +Figure 5.21 SNMP PDU format + +requested are specified in the variable binding portion of the PDU. +GetRequest , GetNextRequest , and GetBulkRequest differ in the +granularity of their data requests. GetRequest can request an arbitrary +set of MIB values; multiple GetNextRequest s can be used to sequence +through a list or table of MIB objects; GetBulkRequest allows a large +block of data to be returned, avoiding the overhead incurred if multiple +GetRequest or GetNextRequest messages were to be sent. In all three +cases, the agent responds with a Response PDU containing the object +identifiers and their associated values. The SetRequest PDU is used by a +managing server to set the value of one or more MIB objects in a managed +device. An agent replies with a Response PDU with the "noError" error +status to confirm that the value has indeed been set. The InformRequest +PDU is used by a managing server to notify another managing server of +MIB + + information that is remote to the receiving server. The Response PDU is +typically sent from a managed device to the managing server in response +to a request message from that server, returning the requested +information. The final type of SNMPv2 PDU is the trap message. Trap +messages are generated asynchronously; that is, they are not generated +in response to a received request but rather in response to an event for +which the managing server requires notification. RFC 3418 defines +well-known trap types that include a cold or warm start by a device, a +link going up or down, the loss of a neighbor, or an authentication +failure event. A received trap request has no required response from a +managing server. Given the request-response nature of SNMP, it is worth +noting here that although SNMP PDUs can be carried via many different +transport protocols, the SNMP PDU is typically carried in the payload of +a UDP datagram. Indeed, RFC 3417 states that UDP is "the preferred +transport mapping." However, since UDP is an unreliable transport +protocol, there is no guarantee that a request, or its response, will be +received at the intended destination. The request ID field of the PDU +(see Figure 5.21) is used by the managing server to number its requests +to an agent; the agent's response takes its request ID from that of the +received request. Thus, the request ID field can be used by the managing +server to detect lost requests or replies. It is up to the managing +server to decide whether to retransmit a request if no corresponding +response is received after a given amount of time. In particular, the +SNMP standard does not mandate any particular procedure for +retransmission, or even if retransmission is to be done in the first +place. It only requires that the managing server "needs to act +responsibly in respect to the frequency and duration of +retransmissions." This, of course, leads one to wonder how a +"responsible" protocol should act! SNMP has evolved through three +versions. The designers of SNMPv3 have said that "SNMPv3 can be thought +of as SNMPv2 with additional security and administration capabilities" +\[RFC 3410\]. Certainly, there are changes in SNMPv3 over SNMPv2, but +nowhere are those changes more evident than in the area of +administration and security. The central role of security in SNMPv3 was +particularly important, since the lack of adequate security resulted in +SNMP being used primarily for monitoring rather than control (for +example, SetRequest is rarely used in SNMPv1). Once again, we see that +security---a topic we'll cover in detail in Chapter 8 --- is of critical +concern, but once again a concern whose importance had been realized +perhaps a bit late and only then "added on." + + 5.7 Summary We have now completed our two-chapter journey into the +network core---a journey that began with our study of the network +layer's data plane in Chapter 4 and finished here with our study of the +network layer's control plane. We learned that the control plane is the +network-wide logic that controls not only how a datagram is forwarded +among routers along an end-to-end path from the source host to the +destination host, but also how network-layer components and services are +configured and managed. We learned that there are two broad approaches +towards building a control plane: traditional per-router control (where +a routing algorithm runs in each and every router and the routing +component in the router communicates with the routing components in +other routers) and software-defined networking (SDN) control (where a +logically centralized controller computes and distributes the forwarding +tables to be used by each and every router). We studied two fundamental +routing algorithms for computing least cost paths in a +graph---link-state routing and distance-vector routing---in Section 5.2; +these algorithms find application in both per-router control and in SDN +control. These algorithms are the basis for two widelydeployed Internet +routing protocols, OSPF and BGP, that we covered in Sections 5.3 and +5.4. We covered the SDN approach to the network-layer control plane in +Section 5.5, investigating SDN network-control applications, the SDN +controller, and the OpenFlow protocol for communicating between the +controller and SDN-controlled devices. In Sections 5.6 and 5.7, we +covered some of the nuts and bolts of managing an IP network: ICMP (the +Internet Control Message Protocol) and SNMP (the Simple Network +Management Protocol). Having completed our study of the network layer, +our journey now takes us one step further down the protocol stack, +namely, to the link layer. Like the network layer, the link layer is +part of each and every network-connected device. But we will see in the +next chapter that the link layer has the much more localized task of +moving packets between nodes on the same link or LAN. Although this task +may appear on the surface to be rather simple compared with that of the +network layer's tasks, we will see that the link layer involves a number +of important and fascinating issues that can keep us busy for a long +time. + + Homework Problems and Questions + +Chapter 5 Review Questions + +SECTION 5.1 R1. What is meant by a control plane that is based on +per-router control? In such cases, when we say the network control and +data planes are implemented "monolithically," what do we mean? R2. What +is meant by a control plane that is based on logically centralized +control? In such cases, are the data plane and the control plane +implemented within the same device or in separate devices? Explain. + +SECTION 5.2 R3. Compare and contrast the properties of a centralized and +a distributed routing algorithm. Give an example of a routing protocol +that takes a centralized and a decentralized approach. R4. Compare and +contrast link-state and distance-vector routing algorithms. R5. What is +the "count to infinity" problem in distance vector routing? R6. Is it +necessary that every autonomous system use the same intra-AS routing +algorithm? Why or why not? + +SECTIONS 5.3--5.4 R7. Why are different inter-AS and intra-AS protocols +used in the Internet? R8. True or false: When an OSPF route sends its +link state information, it is sent only to those nodes directly attached +neighbors. Explain. R9. What is meant by an area in an OSPF autonomous +system? Why was the concept of an area introduced? R10. Define and +contrast the following terms: subnet, prefix, and BGP route. R11. How +does BGP use the NEXT-HOP attribute? How does it use the AS-PATH +attribute? R12. Describe how a network administrator of an upper-tier +ISP can implement policy when configuring BGP. R13. True or false: When +a BGP router receives an advertised path from its neighbor, it must add +its own identity to the received path and then send that new path on to +all of its neighbors. + + Explain. + +SECTION 5.5 R14. Describe the main role of the communication layer, the +network-wide state-management layer, and the network-control application +layer in an SDN controller. R15. Suppose you wanted to implement a new +routing protocol in the SDN control plane. At which layer would you +implement that protocol? Explain. R16. What types of messages flow +across an SDN controller's northbound and southbound APIs? Who is the +recipient of these messages sent from the controller across the +southbound interface, and who sends messages to the controller across +the northbound interface? R17. Describe the purpose of two types of +OpenFlow messages (of your choosing) that are sent from a controlled +device to the controller. Describe the purpose of two types of Openflow +messages (of your choosing) that are send from the controller to a +controlled device. R18. What is the purpose of the service abstraction +layer in the OpenDaylight SDN controller? + +SECTIONS 5.6--5.7 R19. Names four different types of ICMP messages R20. +What two types of ICMP messages are received at the sending host +executing the Traceroute program? R21. Define the following terms in the +context of SNMP: managing server, managed device, network management +agent and MIB. R22. What are the purposes of the SNMP GetRequest and +SetRequest messages? R23. What is the purpose of the SNMP trap message? + +Problems P1. Looking at Figure 5.3 , enumerate the paths from y to u +that do not contain any loops. P2. Repeat Problem P1 for paths from x to +z, z to u, and z to w. P3. Consider the following network. With the +indicated link costs, use Dijkstra's shortest-path algorithm to compute +the shortest path from x to all network nodes. Show how the algorithm +works by computing a table similar to Table 5.1 . + +Dijkstra's algorithm: discussion and example + + P4. Consider the network shown in Problem P3. Using Dijkstra's +algorithm, and showing your work using a table similar to Table 5.1 , do +the following: + +a. Compute the shortest path from t to all network nodes. +b. Compute the shortest path from u to all network nodes. +c. Compute the shortest path from v to all network nodes. +d. Compute the shortest path from w to all network nodes. +e. Compute the shortest path from y to all network nodes. +f. Compute the shortest path from z to all network nodes. P5. Consider + the network shown below, and assume that each node initially knows + the costs to each of its neighbors. Consider the distance-vector + algorithm and show the distance table entries at node z. + +P6. Consider a general topology (that is, not the specific network shown +above) and a + + synchronous version of the distance-vector algorithm. Suppose that at +each iteration, a node exchanges its distance vectors with its neighbors +and receives their distance vectors. Assuming that the algorithm begins +with each node knowing only the costs to its immediate neighbors, what +is the maximum number of iterations required before the distributed +algorithm converges? Justify your answer. P7. Consider the network +fragment shown below. x has only two attached neighbors, w and y. w has +a minimum-cost path to destination u (not shown) of 5, and y has a +minimum-cost path to u of 6. The complete paths from w and y to u (and +between w and y) are not shown. All link costs in the network have +strictly positive integer values. + +a. Give x's distance vector for destinations w, y, and u. + +b. Give a link-cost change for either c(x, w) or c(x, y) such that x + will inform its neighbors of a new minimum-cost path to u as a + result of executing the distance-vector algorithm. + +c. Give a link-cost change for either c(x, w) or c(x, y) such that x + will not inform its neighbors of a new minimum-cost path to u as a + result of executing the distance-vector algorithm. P8. Consider the + three-node topology shown in Figure 5.6 . Rather than having the + link costs shown in Figure 5.6 , the link costs are c(x,y)=3, + c(y,z)=6, c(z,x)=4. Compute the distance tables after the + initialization step and after each iteration of a synchronous + version of the distancevector algorithm (as we did in our earlier + discussion of Figure 5.6 ). P9. Consider the count-to-infinity + problem in the distance vector routing. Will the count-to-infinity + problem occur if we decrease the cost of a link? Why? How about if + we connect two nodes which do not have a link? P10. Argue that for + the distance-vector algorithm in Figure 5.6 , each value in the + distance vector D(x) is non-increasing and will eventually stabilize + in a finite number of steps. P11. Consider Figure 5.7. Suppose there + is another router w, connected to router y and z. The costs of all + links are given as follows: c(x,y)=4, c(x,z)=50, c(y,w)=1, c(z,w)=1, + c(y,z)=3. Suppose that poisoned reverse is used in the + distance-vector routing algorithm. + +d. When the distance vector routing is stabilized, router w, y, and z + inform their distances to x to each other. What distance values do + they tell each other? + +e. Now suppose that the link cost between x and y increases to 60. Will + there be a count-toinfinity problem even if poisoned reverse is + used? Why or why not? If there is a count-toinfinity problem, then + how many iterations are needed for the distance-vector routing to + + reach a stable state again? Justify your answer. + +c. How do you modify c(y, z) such that there is no count-to-infinity + problem at all if c(y,x) changes from 4 to 60? P12. Describe how + loops in paths can be detected in BGP. P13. Will a BGP router always + choose the loop-free route with the shortest ASpath length? Justify + your answer. P14. Consider the network shown below. Suppose AS3 and + AS2 are running OSPF for their intra-AS routing protocol. Suppose + AS1 and AS4 are running RIP for their intra-AS routing protocol. + Suppose eBGP and iBGP are used for the inter-AS routing protocol. + Initially suppose there is no physical link between AS2 and AS4. + +d. Router 3c learns about prefix x from which routing protocol: OSPF, + RIP, eBGP, or iBGP? + +e. Router 3a learns about x from which routing protocol? + +f. Router 1c learns about x from which routing protocol? + +g. Router 1d learns about x from which routing protocol? + +P15. Referring to the previous problem, once router 1d learns about x it +will put an entry (x, I) in its forwarding table. + +a. Will I be equal to I1 or I2 for this entry? Explain why in one + sentence. + +b. Now suppose that there is a physical link between AS2 and AS4, shown + by the dotted line. Suppose router 1d learns that x is accessible + via AS2 as well as via AS3. Will I be set to I1 or I2? Explain why + in one sentence. + +c. Now suppose there is another AS, called AS5, which lies on the path + between AS2 and AS4 (not shown in diagram). Suppose router 1d learns + that x is accessible via AS2 AS5 AS4 as well as via AS3 AS4. Will I + be set to I1 or I2? Explain why in one sentence. + + P16. Consider the following network. ISP B provides national backbone +service to regional ISP A. ISP C provides national backbone service to +regional ISP D. Each ISP consists of one AS. B and C peer with each +other in two places using BGP. Consider traffic going from A to D. B +would prefer to hand that traffic over to C on the West Coast (so that C +would have to absorb the cost of carrying the traffic cross-country), +while C would prefer to get the traffic via its East Coast peering point +with B (so that B would have carried the traffic across the country). +What BGP mechanism might C use, so that B would hand over A-to-D traffic +at its East Coast peering point? To answer this question, you will need +to dig into the BGP specification. + +P17. In Figure 5.13 , consider the path information that reaches stub +networks W, X, and Y. Based on the information available at W and X, +what are their respective views of the network topology? Justify your +answer. The topology view at Y is shown below. + +P18. Consider Figure 5.13 . B would never forward traffic destined to Y +via X based on BGP routing. But there are some very popular applications +for which data packets go to X first and then flow to Y. Identify one +such application, and describe how data packets follow a path not given +by BGP routing. + + P19. In Figure 5.13 , suppose that there is another stub network V that +is a customer of ISP A. Suppose that B and C have a peering +relationship, and A is a customer of both B and C. Suppose that A would +like to have the traffic destined to W to come from B only, and the +traffic destined to V from either B or C. How should A advertise its +routes to B and C? What AS routes does C receive? P20. Suppose ASs X and +Z are not directly connected but instead are connected by AS Y. Further +suppose that X has a peering agreement with Y, and that Y has a peering +agreement with Z. Finally, suppose that Z wants to transit all of Y's +traffic but does not want to transit X's traffic. Does BGP allow Z to +implement this policy? P21. Consider the two ways in which communication +occurs between a managing entity and a managed device: request-response +mode and trapping. What are the pros and cons of these two approaches, +in terms of (1) overhead, (2) notification time when exceptional events +occur, and (3) robustness with respect to lost messages between the +managing entity and the device? P22. In Section 5.7 we saw that it was +preferable to transport SNMP messages in unreliable UDP datagrams. Why +do you think the designers of SNMP chose UDP rather than TCP as the +transport protocol of choice for SNMP? + +Socket Programming Assignment At the end of Chapter 2, there are four +socket programming assignments. Below, you will find a fifth assignment +which employs ICMP, a protocol discussed in this chapter. Assignment 5: +ICMP Ping Ping is a popular networking application used to test from a +remote location whether a particular host is up and reachable. It is +also often used to measure latency between the client host and the +target host. It works by sending ICMP "echo request" packets (i.e., ping +packets) to the target host and listening for ICMP "echo response" +replies (i.e., pong packets). Ping measures the RRT, records packet +loss, and calculates a statistical summary of multiple ping-pong +exchanges (the minimum, mean, max, and standard deviation of the +round-trip times). In this lab, you will write your own Ping application +in Python. Your application will use ICMP. But in order to keep your +program simple, you will not exactly follow the official specification +in RFC 1739. Note that you will only need to write the client side of +the program, as the functionality needed on the server side is built +into almost all operating systems. You can find full details of this +assignment, as well as important snippets of the Python code, at the Web +site http://www.pearsonhighered.com/csresources. Programming Assignment + + In this programming assignment, you will be writing a "distributed" set +of procedures that implements a distributed asynchronous distance-vector +routing for the network shown below. You are to write the following +routines that will "execute" asynchronously within the emulated +environment provided for this assignment. For node 0, you will write the +routines: + +rtinit0(). This routine will be called once at the beginning of the +emulation. rtinit0() has no arguments. It should initialize your +distance table in node 0 to reflect the direct costs of 1, 3, and 7 to +nodes 1, 2, and 3, respectively. In the figure above, all links are +bidirectional and the costs in both directions are identical. After +initializing the distance table and any other data structures needed by +your node 0 routines, it should then send its directly connected +neighbors (in this case, 1, 2, and 3) the cost of its minimum-cost paths +to all other network nodes. This minimum-cost information is sent to +neighboring nodes in a routing update packet by calling the routine +tolayer2(), as described in the full assignment. The format of the +routing update packet is also described in the full assignment. +rtupdate0(struct rtpkt *rcvdpkt). This routine will be called when node +0 receives a routing packet that was sent to it by one of its directly +connected neighbors. The parameter *rcvdpkt is a pointer to the packet +that was received. rtupdate0() is the "heart" of the distance-vector +algorithm. The values it receives in a routing update packet from some +other node i contain i's current shortest-path costs to all other +network nodes. rtupdate0() uses these received values to update its own +distance table (as specified by the distance-vector algorithm). If its +own minimum cost to another node changes as a result of the update, node +0 informs its directly connected neighbors of this change in minimum +cost by sending them a routing packet. Recall that in the +distance-vector algorithm, only directly connected nodes will exchange +routing packets. Thus, nodes 1 and 2 will communicate with each other, +but nodes 1 and 3 will not communicate with each other. Similar routines +are defined for nodes 1, 2, and 3. Thus, you will write eight procedures +in all: rtinit0(), rtinit1(), rtinit2(), rtinit3(), rtupdate0(), +rtupdate1(), rtupdate2(), and rtupdate3(). These routines will together +implement a distributed, asynchronous computation of the distance tables +for the topology and costs shown in the figure on the preceding page. +You can find the full details of the programming assignment, as well as +C code that you will need to create the simulated hardware/software +environment, at http://www.pearsonhighered.com/cs-resource. A Java +version of the assignment is also available. + + Wireshark Lab In the Web site for this textbook, +www.pearsonhighered.com/cs-resources, you'll find a Wireshark lab +assignment that examines the use of the ICMP protocol in the ping and +traceroute commands. + +An Interview With... Jennifer Rexford Jennifer Rexford is a Professor in +the Computer Science department at Princeton University. Her research +has the broad goal of making computer networks easier to design and +manage, with particular emphasis on routing protocols. From 1996--2004, +she was a member of the Network Management and Performance department at +AT&T Labs--Research. While at AT&T, she designed techniques and tools +for network measurement, traffic engineering, and router configuration +that were deployed in AT&T's backbone network. Jennifer is co-author of +the book "Web Protocols and Practice: Networking Protocols, Caching, and +Traffic Measurement," published by Addison-Wesley in May 2001. She +served as the chair of ACM SIGCOMM from 2003 to 2007. She received her +BSE degree in electrical engineering from Princeton University in 1991, +and her PhD degree in electrical engineering and computer science from +the University of Michigan in 1996. In 2004, Jennifer was the winner of +ACM's Grace Murray Hopper Award for outstanding young computer +professional and appeared on the MIT TR-100 list of top innovators under +the age of 35. + +Please describe one or two of the most exciting projects you have worked +on during your career. What were the biggest challenges? When I was a +researcher at AT&T, a group of us designed a new way to manage routing +in Internet Service Provider backbone networks. Traditionally, network +operators configure each router individually, and these routers run +distributed protocols to compute paths through the network. We believed +that network management would be simpler and more flexible if network + + operators could exercise direct control over how routers forward traffic +based on a network-wide view of the topology and traffic. The Routing +Control Platform (RCP) we designed and built could compute the routes +for all of AT&T's backbone on a single commodity computer, and could +control legacy routers without modification. To me, this project was +exciting because we had a provocative idea, a working system, and +ultimately a real deployment in an operational network. Fast forward a +few years, and software-defined networking (SDN) has become a mainstream +technology, and standard protocols (like OpenFlow) have made it much +easier to tell the underlying switches what to do. How do you think +software-defined networking should evolve in the future? In a major +break from the past, control-plane software can be created by many +different programmers, not just at companies selling network equipment. +Yet, unlike the applications running on a server or a smart phone, +controller apps must work together to handle the same traffic. Network +operators do not want to perform load balancing on some traffic and +routing on other traffic; instead, they want to perform load balancing +and routing, together, on the same traffic. Future SDN controller +platforms should offer good programming abstractions for composing +independently written multiple controller applications together. More +broadly, good programming abstractions can make it easier to create +controller applications, without having to worry about low-level details +like flow table entries, traffic counters, bit patterns in packet +headers, and so on. Also, while an SDN controller is logically +centralized, the network still consists of a distributed collection of +devices. Future controllers should offer good abstractions for updating +the flow tables across the network, so apps can reason about what +happens to packets in flight while the devices are updated. Programming +abstractions for control-plane software is an exciting area for +interdisciplinary research between computer networking, distributed +systems, and programming languages, with a real chance for practical +impact in the years ahead. Where do you see the future of networking and +the Internet? Networking is an exciting field because the applications +and the underlying technologies change all the time. We are always +reinventing ourselves! Who would have predicted even ten years ago the +dominance of smart phones, allowing mobile users to access existing +applications as well as new location-based services? The emergence of +cloud computing is fundamentally changing the relationship between users +and the applications they run, and networked sensors and actuators (the +"Internet of Things") are enabling a wealth of new applications (and +security vulnerabilities!). The pace of innovation is truly inspiring. +The underlying network is a crucial component in all of these +innovations. Yet, the network is notoriously "in the way"---limiting +performance, compromising reliability, constraining applications, and +complicating the deployment and management of services. We should strive +to make the network of the future as invisible as the air we breathe, so +it never stands in the way of + + new ideas and valuable services. To do this, we need to raise the level +of abstraction above individual network devices and protocols (and their +attendant acronyms!), so we can reason about the network and the user's +high-level goals as a whole. What people inspired you professionally? +I've long been inspired by Sally Floyd at the International Computer +Science Institute. Her research is always purposeful, focusing on the +important challenges facing the Internet. She digs deeply into hard +questions until she understands the problem and the space of solutions +completely, and she devotes serious energy into "making things happen," +such as pushing her ideas into protocol standards and network equipment. +Also, she gives back to the community, through professional service in +numerous standards and research organizations and by creating tools +(such as the widely used ns-2 and ns-3 simulators) that enable other +researchers to succeed. She retired in 2009 but her influence on the +field will be felt for years to come. What are your recommendations for +students who want careers in computer science and networking? Networking +is an inherently interdisciplinary field. Applying techniques from other +disciplines breakthroughs in networking come from such diverse areas as +queuing theory, game theory, control theory, distributed systems, +network optimization, programming languages, machine learning, +algorithms, data structures, and so on. I think that becoming conversant +in a related field, or collaborating closely with experts in those +fields, is a wonderful way to put networking on a stronger foundation, +so we can learn how to build networks that are worthy of society's +trust. Beyond the theoretical disciplines, networking is exciting +because we create real artifacts that real people use. Mastering how to +design and build systems---by gaining experience in operating systems, +computer architecture, and so on---is another fantastic way to amplify +your knowledge of networking to help make the world a better place. + + Chapter 6 The Link Layer and LANs + +In the previous two chapters we learned that the network layer provides +a communication service between any two network hosts. Between the two +hosts, datagrams travel over a series of communication links, some wired +and some wireless, starting at the source host, passing through a series +of packet switches (switches and routers) and ending at the destination +host. As we continue down the protocol stack, from the network layer to +the link layer, we naturally wonder how packets are sent across the +individual links that make up the end-to-end communication path. How are +the networklayer datagrams encapsulated in the link-layer frames for +transmission over a single link? Are different link-layer protocols used +in the different links along the communication path? How are +transmission conflicts in broadcast links resolved? Is there addressing +at the link layer and, if so, how does the linklayer addressing operate +with the network-layer addressing we learned about in Chapter 4? And +what exactly is the difference between a switch and a router? We'll +answer these and other important questions in this chapter. In +discussing the link layer, we'll see that there are two fundamentally +different types of link-layer channels. The first type are broadcast +channels, which connect multiple hosts in wireless LANs, satellite +networks, and hybrid fiber-coaxial cable (HFC) access networks. Since +many hosts are connected to the same broadcast communication channel, a +so-called medium access protocol is needed to coordinate frame +transmission. In some cases, a central controller may be used to +coordinate transmissions; in other cases, the hosts themselves +coordinate transmissions. The second type of link-layer channel is the +point-to-point communication link, such as that often found between two +routers connected by a long-distance link, or between a user's office +computer and the nearby Ethernet switch to which it is connected. +Coordinating access to a point-to-point link is simpler; the reference +material on this book's Web site has a detailed discussion of the +Point-to-Point Protocol (PPP), which is used in settings ranging from +dial-up service over a telephone line to high-speed point-to-point frame +transport over fiber-optic links. We'll explore several important +link-layer concepts and technologies in this chapter. We'll dive deeper +into error detection and correction, a topic we touched on briefly in +Chapter 3. We'll consider multiple access networks and switched LANs, +including Ethernet---by far the most prevalent wired LAN technology. +We'll also look at virtual LANs, and data center networks. Although +WiFi, and more generally wireless LANs, are link-layer topics, we'll +postpone our study of these important topics until + + Chapter 7. + + 6.1 Introduction to the Link Layer Let's begin with some important +terminology. We'll find it convenient in this chapter to refer to any +device that runs a link-layer (i.e., layer 2) protocol as a node. Nodes +include hosts, routers, switches, and WiFi access points (discussed in +Chapter 7). We will also refer to the communication channels that +connect adjacent nodes along the communication path as links. In order +for a datagram to be transferred from source host to destination host, +it must be moved over each of the individual links in the end-to-end +path. As an example, in the company network shown at the bottom of +Figure 6.1, consider sending a datagram from one of the wireless hosts +to one of the servers. This datagram will actually pass through six +links: a WiFi link between sending host and WiFi access point, an +Ethernet link between the access point and a link-layer switch; a link +between the link-layer switch and the router, a link between the two +routers; an Ethernet link between the router and a link-layer switch; +and finally an Ethernet link between the switch and the server. Over a +given link, a transmitting node encapsulates the datagram in a linklayer +frame and transmits the frame into the link. In order to gain further +insight into the link layer and how it relates to the network layer, +let's consider a transportation analogy. Consider a travel agent who is +planning a trip for a tourist traveling from Princeton, New Jersey, to +Lausanne, Switzerland. The travel agent decides that it is most +convenient for the tourist to take a limousine from Princeton to JFK +airport, then a plane from JFK airport to Geneva's airport, and finally +a train from Geneva's airport to Lausanne's train station. Once the +travel agent makes the three reservations, it is the responsibility of +the Princeton limousine company to get the tourist from Princeton to +JFK; it is the responsibility of the airline company to get the tourist +from JFK to Geneva; and it is the responsibility + + Figure 6.1 Six link-layer hops between wireless host and server + +of the Swiss train service to get the tourist from Geneva to Lausanne. +Each of the three segments of the trip is "direct" between two +"adjacent" locations. Note that the three transportation segments are +managed by different companies and use entirely different transportation +modes (limousine, plane, and train). Although the transportation modes +are different, they each provide the basic service of moving passengers +from one location to an adjacent location. In this transportation +analogy, the tourist is a datagram, each transportation segment is a +link, the transportation mode is a link-layer protocol, and the + + travel agent is a routing protocol. + +6.1.1 The Services Provided by the Link Layer Although the basic service +of any link layer is to move a datagram from one node to an adjacent +node over a single communication link, the details of the provided +service can vary from one link-layer protocol to the next. Possible +services that can be offered by a link-layer protocol include: Framing. +Almost all link-layer protocols encapsulate each network-layer datagram +within a link-layer frame before transmission over the link. A frame +consists of a data field, in which the network-layer datagram is +inserted, and a number of header fields. The structure of the frame is +specified by the link-layer protocol. We'll see several different frame +formats when we examine specific link-layer protocols in the second half +of this chapter. Link access. A medium access control (MAC) protocol +specifies the rules by which a frame is transmitted onto the link. For +point-to-point links that have a single sender at one end of the link +and a single receiver at the other end of the link, the MAC protocol is +simple (or nonexistent)---the sender can send a frame whenever the link +is idle. The more interesting case is when multiple nodes share a single +broadcast link---the so-called multiple access problem. Here, the MAC +protocol serves to coordinate the frame transmissions of the many nodes. +Reliable delivery. When a link-layer protocol provides reliable delivery +service, it guarantees to move each network-layer datagram across the +link without error. Recall that certain transport-layer protocols (such +as TCP) also provide a reliable delivery service. Similar to a +transport-layer reliable delivery service, a link-layer reliable +delivery service can be achieved with acknowledgments and +retransmissions (see Section 3.4). A link-layer reliable delivery +service is often used for links that are prone to high error rates, such +as a wireless link, with the goal of correcting an error locally---on +the link where the error occurs---rather than forcing an end-to-end +retransmission of the data by a transport- or application-layer +protocol. However, link-layer reliable delivery can be considered an +unnecessary overhead for low bit-error links, including fiber, coax, and +many twisted-pair copper links. For this reason, many wired link-layer +protocols do not provide a reliable delivery service. Error detection +and correction. The link-layer hardware in a receiving node can +incorrectly decide that a bit in a frame is zero when it was transmitted +as a one, and vice versa. Such bit errors are introduced by signal +attenuation and electromagnetic noise. Because there is no need to +forward a datagram that has an error, many link-layer protocols provide +a mechanism to detect such bit errors. This is done by having the +transmitting node include error-detection bits in the frame, and having +the receiving node perform an error check. Recall from Chapters 3 and 4 +that the Internet's transport layer and network layer also provide a +limited form of error detection---the Internet checksum. Error detection +in the link layer is usually more sophisticated and is implemented in +hardware. Error correction is similar to error detection, except that a +receiver not only detects when bit errors have occurred in the frame but +also determines exactly where in the frame the errors have occurred (and + + then corrects these errors). + +6.1.2 Where Is the Link Layer Implemented? Before diving into our +detailed study of the link layer, let's conclude this introduction by +considering the question of where the link layer is implemented. We'll +focus here on an end system, since we learned in Chapter 4 that the link +layer is implemented in a router's line card. Is a host's link layer +implemented in hardware or software? Is it implemented on a separate +card or chip, and how does it interface with the rest of a host's +hardware and operating system components? Figure 6.2 shows a typical +host architecture. For the most part, the link layer is implemented in a +network adapter, also sometimes known as a network interface card (NIC). +At the heart of the network adapter is the link-layer controller, +usually a single, special-purpose chip that implements many of the +link-layer services (framing, link access, error detection, and so on). +Thus, much of a link-layer controller's functionality is implemented in +hardware. For example, Intel's 710 adapter \[Intel 2016\] implements the +Ethernet protocols we'll study in Section 6.5; the Atheros AR5006 +\[Atheros 2016\] controller implements the 802.11 WiFi protocols we'll +study in Chapter 7. Until the late 1990s, most network adapters were +physically separate cards (such as a PCMCIA card or a plug-in card +fitting into a PC's PCI card slot) but increasingly, network adapters +are being integrated onto the host's motherboard ---a so-called +LAN-on-motherboard configuration. On the sending side, the controller +takes a datagram that has been created and stored in host memory by the +higher layers of the protocol stack, encapsulates the datagram in a +link-layer frame (filling in the frame's various fields), and then +transmits the frame into the communication link, following the +linkaccess protocol. On the receiving side, a controller receives the +entire frame, and extracts the networklayer datagram. If the link layer +performs error detection, then it is the sending controller that sets +the error-detection bits in the frame header and it is the receiving +controller that performs error detection. Figure 6.2 shows a network +adapter attaching to a host's bus (e.g., a PCI or PCI-X bus), where it +looks much like any other I/O device to the other host + + Figure 6.2 Network adapter: Its relationship to other host components +and to protocol stack functionality + +components. Figure 6.2 also shows that while most of the link layer is +implemented in hardware, part of the link layer is implemented in +software that runs on the host's CPU. The software components of the +link layer implement higher-level link-layer functionality such as +assembling link-layer addressing information and activating the +controller hardware. On the receiving side, link-layer software responds +to controller interrupts (e.g., due to the receipt of one or more +frames), handling error conditions and passing a datagram up to the +network layer. Thus, the link layer is a combination of hardware and +software---the place in the protocol stack where software meets +hardware. \[Intel 2016\] provides a readable overview (as well as a +detailed description) of the XL710 controller from a softwareprogramming +point of view. + + 6.2 Error-Detection and -Correction Techniques In the previous section, +we noted that bit-level error detection and correction---detecting and +correcting the corruption of bits in a link-layer frame sent from one +node to another physically connected neighboring node---are two services +often provided by the link layer. We saw in Chapter 3 that +errordetection and -correction services are also often offered at the +transport layer as well. In this section, we'll examine a few of the +simplest techniques that can be used to detect and, in some cases, +correct such bit errors. A full treatment of the theory and +implementation of this topic is itself the topic of many textbooks (for +example, \[Schwartz 1980\] or \[Bertsekas 1991\]), and our treatment +here is necessarily brief. Our goal here is to develop an intuitive feel +for the capabilities that error-detection and -correction techniques +provide and to see how a few simple techniques work and are used in +practice in the link layer. Figure 6.3 illustrates the setting for our +study. At the sending node, data, D, to be protected against bit errors +is augmented with error-detection and -correction bits (EDC). Typically, +the data to be protected includes not only the datagram passed down from +the network layer for transmission across the link, but also link-level +addressing information, sequence numbers, and other fields in the link +frame header. Both D and EDC are sent to the receiving node in a +link-level frame. At the receiving node, a sequence of bits, D′ and EDC′ +is received. Note that D′ and EDC′ may differ from the original D and +EDC as a result of in-transit bit flips. The receiver's challenge is to +determine whether or not D′ is the same as the original D, given that it +has only received D′ and EDC′. The exact wording of the receiver's +decision in Figure 6.3 (we ask whether an error is detected, not whether +an error has occurred!) is important. Error-detection and -correction +techniques allow the receiver to sometimes, but not always, detect that +bit errors have occurred. Even with the use of error-detection bits +there still may be undetected bit errors; that is, the receiver may be +unaware that the received information contains bit errors. As a + + Figure 6.3 Error-detection and -correction scenario + +consequence, the receiver might deliver a corrupted datagram to the +network layer, or be unaware that the contents of a field in the frame's +header has been corrupted. We thus want to choose an errordetection +scheme that keeps the probability of such occurrences small. Generally, +more sophisticated error-detection and-correction techniques (that is, +those that have a smaller probability of allowing undetected bit errors) +incur a larger overhead---more computation is needed to compute and +transmit a larger number of error-detection and -correction bits. Let's +now examine three techniques for detecting errors in the transmitted +data---parity checks (to illustrate the basic ideas behind error +detection and correction), checksumming methods (which are more +typically used in the transport layer), and cyclic redundancy checks +(which are more typically used in the link layer in an adapter). + +6.2.1 Parity Checks Perhaps the simplest form of error detection is the +use of a single parity bit. Suppose that the information to be sent, D +in Figure 6.4, has d bits. In an even parity scheme, the sender simply +includes one additional bit and chooses its value such that the total +number of 1s in the d+1 bits (the original information plus a parity +bit) is even. For odd parity schemes, the parity bit value is chosen +such that there is an odd number of 1s. Figure 6.4 illustrates an even +parity scheme, with the single parity bit being stored in a separate +field. + + Receiver operation is also simple with a single parity bit. The receiver +need only count the number of 1s in the received d+1 bits. If an odd +number of 1-valued bits are found with an even parity scheme, the +receiver knows that at least one bit error has occurred. More precisely, +it knows that some odd number of bit errors have occurred. But what +happens if an even number of bit errors occur? You should convince +yourself that this would result in an undetected error. If the +probability of bit errors is small and errors can be assumed to occur +independently from one bit to the next, the probability of multiple bit +errors in a packet would be extremely small. In this case, a single +parity bit might suffice. However, measurements have shown that, rather +than occurring independently, errors are often clustered together in +"bursts." Under burst error conditions, the probability of undetected +errors in a frame protected by single-bit parity can approach 50 percent +\[Spragins 1991\]. Clearly, a more robust error-detection scheme is +needed (and, fortunately, is used in practice!). But before examining +error-detection schemes that are used in practice, let's consider a +simple + +Figure 6.4 One-bit even parity + +generalization of one-bit parity that will provide us with insight into +error-correction techniques. Figure 6.5 shows a two-dimensional +generalization of the single-bit parity scheme. Here, the d bits in D +are divided into i rows and j columns. A parity value is computed for +each row and for each column. The resulting i+j+1 parity bits comprise +the link-layer frame's error-detection bits. Suppose now that a single +bit error occurs in the original d bits of information. With this +twodimensional parity scheme, the parity of both the column and the row +containing the flipped bit will be in error. The receiver can thus not +only detect the fact that a single bit error has occurred, but can use +the column and row indices of the column and row with parity errors to +actually identify the bit that was corrupted and correct that error! +Figure 6.5 shows an example in which the 1-valued bit in position (2,2) +is corrupted and switched to a 0---an error that is both detectable and +correctable at the receiver. Although our discussion has focused on the +original d bits of information, a single error in the parity bits +themselves is also detectable and correctable. Two-dimensional parity +can also detect (but not correct!) any combination of two errors in a +packet. Other properties of the two-dimensional parity scheme are +explored in the problems at the end of the chapter. + + Figure 6.5 Two-dimensional even parity + +The ability of the receiver to both detect and correct errors is known +as forward error correction (FEC). These techniques are commonly used in +audio storage and playback devices such as audio CDs. In a network +setting, FEC techniques can be used by themselves, or in conjunction +with link-layer ARQ techniques similar to those we examined in Chapter +3. FEC techniques are valuable because they can decrease the number of +sender retransmissions required. Perhaps more important, they allow for +immediate correction of errors at the receiver. This avoids having to +wait for the round-trip propagation delay needed for the sender to +receive a NAK packet and for the retransmitted packet to propagate back +to the receiver---a potentially important advantage for real-time +network applications \[Rubenstein 1998\] or links (such as deep-space +links) with long propagation delays. Research examining the use of FEC +in error-control protocols includes \[Biersack 1992; Nonnenmacher 1998; +Byers 1998; Shacham 1990\]. + +6.2.2 Checksumming Methods In checksumming techniques, the d bits of +data in Figure 6.4 are treated as a sequence of k-bit integers. One +simple checksumming method is to simply sum these k-bit integers and use +the resulting sum as the error-detection bits. The Internet checksum is +based on this approach---bytes of data are + + treated as 16-bit integers and summed. The 1s complement of this sum +then forms the Internet checksum that is carried in the segment header. +As discussed in Section 3.3, the receiver checks the checksum by taking +the 1s complement of the sum of the received data (including the +checksum) and checking whether the result is all 1 bits. If any of the +bits are 0, an error is indicated. RFC 1071 discusses the Internet +checksum algorithm and its implementation in detail. In the TCP and UDP +protocols, the Internet checksum is computed over all fields (header and +data fields included). In IP the checksum is computed over the IP header +(since the UDP or TCP segment has its own checksum). In other protocols, +for example, XTP \[Strayer 1992\], one checksum is computed over the +header and another checksum is computed over the entire packet. +Checksumming methods require relatively little packet overhead. For +example, the checksums in TCP and UDP use only 16 bits. However, they +provide relatively weak protection against errors as compared with +cyclic redundancy check, which is discussed below and which is often +used in the link layer. A natural question at this point is, Why is +checksumming used at the transport layer and cyclic redundancy check +used at the link layer? Recall that the transport layer is typically +implemented in software in a host as part of the host's operating +system. Because transport-layer error detection is implemented in +software, it is important to have a simple and fast error-detection +scheme such as checksumming. On the other hand, error detection at the +link layer is implemented in dedicated hardware in adapters, which can +rapidly perform the more complex CRC operations. Feldmeier \[Feldmeier +1995\] presents fast software implementation techniques for not only +weighted checksum codes, but CRC (see below) and other codes as well. + +6.2.3 Cyclic Redundancy Check (CRC) An error-detection technique used +widely in today's computer networks is based on cyclic redundancy check +(CRC) codes. CRC codes are also known as polynomial codes, since it is +possible to view the bit string to be sent as a polynomial whose +coefficients are the 0 and 1 values in the bit string, with operations +on the bit string interpreted as polynomial arithmetic. CRC codes +operate as follows. Consider the d-bit piece of data, D, that the +sending node wants to send to the receiving node. The sender and +receiver must first agree on an r+1 bit pattern, known as a generator, +which we will denote as G. We will require that the most significant +(leftmost) bit of G be a 1. The key idea behind CRC codes is shown in +Figure 6.6. For a given piece of data, D, the sender will choose r +additional bits, R, and append them to D such that the resulting d+r bit +pattern (interpreted as a binary number) is exactly divisible by G +(i.e., has no remainder) using modulo-2 arithmetic. The process of error +checking with CRCs is thus simple: The receiver divides the d+r received +bits by G. If the remainder is nonzero, the receiver knows that an error +has occurred; otherwise the data is accepted as being correct. + + All CRC calculations are done in modulo-2 arithmetic without carries in +addition or borrows in subtraction. This means that addition and +subtraction are identical, and both are equivalent to the bitwise +exclusive-or (XOR) of the operands. Thus, for example, + +1011 XOR 0101 = 1110 1001 XOR 1101 = 0100 + +Also, we similarly have + +1011 - 0101 = 1110 1001 - 1101 = 0100 + +Multiplication and division are the same as in base-2 arithmetic, except +that any required addition or subtraction is done without carries or +borrows. As in regular + +Figure 6.6 CRC + +binary arithmetic, multiplication by 2k left shifts a bit pattern by k +places. Thus, given D and R, the quantity D⋅2rXOR R yields the d+r bit +pattern shown in Figure 6.6. We'll use this algebraic characterization +of the d+r bit pattern from Figure 6.6 in our discussion below. Let us +now turn to the crucial question of how the sender computes R. Recall +that we want to find R such that there is an n such that D⋅2rXOR R=nG +That is, we want to choose R such that G divides into D⋅2rXOR R without +remainder. If we XOR (that is, add modulo-2, without carry) R to both +sides of the above equation, we get + + D⋅2r=nG XOR R This equation tells us that if we divide D⋅2r by G, the +value of the remainder is precisely R. In other words, we can calculate +R as R=remainderD⋅2rG Figure 6.7 illustrates this calculation for the +case of D=101110, d=6, G=1001, and r=3. The 9 bits transmitted in this +case are 101 110 011. You should check these calculations for yourself +and also check that indeed D⋅2r=101011⋅G XOR R. + +Figure 6.7 A sample CRC calculation + +International standards have been defined for 8-, 12-, 16-, and 32-bit +generators, G. The CRC-32 32-bit standard, which has been adopted in a +number of link-level IEEE protocols, uses a generator of +GCRC-32=100000100110000010001110110110111 Each of the CRC standards can +detect burst errors of fewer than r+1 bits. (This means that all +consecutive bit errors of r bits or fewer will be detected.) +Furthermore, under appropriate assumptions, a burst of length greater +than r+1 bits is detected with probability 1−0.5r. Also, each of the CRC +standards can detect any odd number of bit errors. See \[Williams 1993\] +for a discussion of implementing CRC checks. The theory behind CRC codes +and even more powerful codes is beyond the scope of this text. The text +\[Schwartz 1980\] provides an excellent introduction to this topic. + + 6.3 Multiple Access Links and Protocols In the introduction to this +chapter, we noted that there are two types of network links: +point-to-point links and broadcast links. A point-to-point link consists +of a single sender at one end of the link and a single receiver at the +other end of the link. Many link-layer protocols have been designed for +point-to-point links; the point-to-point protocol (PPP) and high-level +data link control (HDLC) are two such protocols. The second type of +link, a broadcast link, can have multiple sending and receiving nodes +all connected to the same, single, shared broadcast channel. The term +broadcast is used here because when any one node transmits a frame, the +channel broadcasts the frame and each of the other nodes receives a +copy. Ethernet and wireless LANs are examples of broadcast link-layer +technologies. In this section we'll take a step back from specific +link-layer protocols and first examine a problem of central importance +to the link layer: how to coordinate the access of multiple sending and +receiving nodes to a shared broadcast channel---the multiple access +problem. Broadcast channels are often used in LANs, networks that are +geographically concentrated in a single building (or on a corporate or +university campus). Thus, we'll look at how multiple access channels are +used in LANs at the end of this section. We are all familiar with the +notion of broadcasting---television has been using it since its +invention. But traditional television is a one-way broadcast (that is, +one fixed node transmitting to many receiving nodes), while nodes on a +computer network broadcast channel can both send and receive. Perhaps a +more apt human analogy for a broadcast channel is a cocktail party, +where many people gather in a large room (the air providing the +broadcast medium) to talk and listen. A second good analogy is something +many readers will be familiar with---a classroom---where teacher(s) and +student(s) similarly share the same, single, broadcast medium. A central +problem in both scenarios is that of determining who gets to talk (that +is, transmit into the channel) and when. As humans, we've evolved an +elaborate set of protocols for sharing the broadcast channel: "Give +everyone a chance to speak." "Don't speak until you are spoken to." +"Don't monopolize the conversation." "Raise your hand if you have a +question." "Don't interrupt when someone is speaking." "Don't fall +asleep when someone is talking." Computer networks similarly have +protocols---so-called multiple access protocols---by which nodes + + regulate their transmission into the shared broadcast channel. As shown +in Figure 6.8, multiple access protocols are needed in a wide variety of +network settings, including both wired and wireless access networks, and +satellite networks. Although technically each node accesses the +broadcast channel through its adapter, in this section we will refer to +the node as the sending and + +Figure 6.8 Various multiple access channels + +receiving device. In practice, hundreds or even thousands of nodes can +directly communicate over a broadcast channel. Because all nodes are +capable of transmitting frames, more than two nodes can transmit frames +at the same time. When this happens, all of the nodes receive multiple +frames at the same time; that is, the transmitted frames collide at all +of the receivers. Typically, when there is a collision, none of the +receiving nodes can make any sense of any of the frames that were +transmitted; in a sense, the signals of the colliding frames become +inextricably tangled together. Thus, all the frames involved in the +collision are lost, and the broadcast channel is wasted during the +collision interval. Clearly, if many nodes want to transmit frames +frequently, many transmissions will result in collisions, and much of +the bandwidth of the broadcast channel will be wasted. In order to +ensure that the broadcast channel performs useful work when multiple +nodes are active, it is + + necessary to somehow coordinate the transmissions of the active nodes. +This coordination job is the responsibility of the multiple access +protocol. Over the past 40 years, thousands of papers and hundreds of +PhD dissertations have been written on multiple access protocols; a +comprehensive survey of the first 20 years of this body of work is \[Rom +1990\]. Furthermore, active research in multiple access protocols +continues due to the continued emergence of new types of links, +particularly new wireless links. Over the years, dozens of multiple +access protocols have been implemented in a variety of link-layer +technologies. Nevertheless, we can classify just about any multiple +access protocol as belonging to one of three categories: channel +partitioning protocols, random access protocols, and taking-turns +protocols. We'll cover these categories of multiple access protocols in +the following three subsections. Let's conclude this overview by noting +that, ideally, a multiple access protocol for a broadcast channel of +rate R bits per second should have the following desirable +characteristics: + +1. When only one node has data to send, that node has a throughput of R + bps. + +2. When M nodes have data to send, each of these nodes has a throughput + of R/M bps. This need not necessarily imply that each of the M nodes + always has an instantaneous rate of R/M, but rather that each node + should have an average transmission rate of R/M over some suitably + defined interval of time. + +3. The protocol is decentralized; that is, there is no master node that + represents a single point of failure for the network. + +4. The protocol is simple, so that it is inexpensive to implement. + +6.3.1 Channel Partitioning Protocols Recall from our early discussion +back in Section 1.3 that time-division multiplexing (TDM) and +frequency-division multiplexing (FDM) are two techniques that can + + Figure 6.9 A four-node TDM and FDM example + +be used to partition a broadcast channel's bandwidth among all nodes +sharing that channel. As an example, suppose the channel supports N +nodes and that the transmission rate of the channel is R bps. TDM +divides time into time frames and further divides each time frame into N +time slots. (The TDM time frame should not be confused with the +link-layer unit of data exchanged between sending and receiving +adapters, which is also called a frame. In order to reduce confusion, in +this subsection we'll refer to the link-layer unit of data exchanged as +a packet.) Each time slot is then assigned to one of the N nodes. +Whenever a node has a packet to send, it transmits the packet's bits +during its assigned time slot in the revolving TDM frame. Typically, +slot sizes are chosen so that a single packet can be transmitted during +a slot time. Figure 6.9 shows a simple four-node TDM example. Returning +to our cocktail party analogy, a TDM-regulated cocktail party would +allow one partygoer to speak for a fixed period of time, then allow +another partygoer to speak for the same amount of time, and so on. Once +everyone had had a chance to talk, the pattern would repeat. TDM is +appealing because it eliminates collisions and is perfectly fair: Each +node gets a dedicated transmission rate of R/N bps during each frame +time. However, it has two major drawbacks. First, a node is limited to +an average rate of R/N bps even when it is the only node with packets to +send. A second drawback is that a node must always wait for its turn in +the transmission sequence---again, even when it is the only node with a +frame to send. Imagine the partygoer who is the only one with anything +to say (and imagine that this is the even rarer circumstance where +everyone wants to hear what that one person has to say). Clearly, TDM +would be a poor choice for a multiple access protocol for this +particular party. + + While TDM shares the broadcast channel in time, FDM divides the R bps +channel into different frequencies (each with a bandwidth of R/N) and +assigns each frequency to one of the N nodes. FDM thus creates N smaller +channels of R/N bps out of the single, larger R bps channel. FDM shares +both the advantages and drawbacks of TDM. It avoids collisions and +divides the bandwidth fairly among the N nodes. However, FDM also shares +a principal disadvantage with TDM---a node is limited to a bandwidth of +R/N, even when it is the only node with packets to send. A third channel +partitioning protocol is code division multiple access (CDMA). While TDM +and FDM assign time slots and frequencies, respectively, to the nodes, +CDMA assigns a different code to each node. Each node then uses its +unique code to encode the data bits it sends. If the codes are chosen +carefully, CDMA networks have the wonderful property that different +nodes can transmit simultaneously and yet have their respective +receivers correctly receive a sender's encoded data bits (assuming the +receiver knows the sender's code) in spite of interfering transmissions +by other nodes. CDMA has been used in military systems for some time +(due to its anti-jamming properties) and now has widespread civilian +use, particularly in cellular telephony. Because CDMA's use is so +tightly tied to wireless channels, we'll save our discussion of the +technical details of CDMA until Chapter 7. For now, it will suffice to +know that CDMA codes, like time slots in TDM and frequencies in FDM, can +be allocated to the multiple access channel users. + +6.3.2 Random Access Protocols The second broad class of multiple access +protocols are random access protocols. In a random access protocol, a +transmitting node always transmits at the full rate of the channel, +namely, R bps. When there is a collision, each node involved in the +collision repeatedly retransmits its frame (that is, packet) until its +frame gets through without a collision. But when a node experiences a +collision, it doesn't necessarily retransmit the frame right away. +Instead it waits a random delay before retransmitting the frame. Each +node involved in a collision chooses independent random delays. Because +the random delays are independently chosen, it is possible that one of +the nodes will pick a delay that is sufficiently less than the delays of +the other colliding nodes and will therefore be able to sneak its frame +into the channel without a collision. There are dozens if not hundreds +of random access protocols described in the literature \[Rom 1990; +Bertsekas 1991\]. In this section we'll describe a few of the most +commonly used random access protocols---the ALOHA protocols \[Abramson +1970; Abramson 1985; Abramson 2009\] and the carrier sense multiple +access (CSMA) protocols \[Kleinrock 1975b\]. Ethernet \[Metcalfe 1976\] +is a popular and widely deployed CSMA protocol. Slotted ALOHA + + Let's begin our study of random access protocols with one of the +simplest random access protocols, the slotted ALOHA protocol. In our +description of slotted ALOHA, we assume the following: All frames +consist of exactly L bits. Time is divided into slots of size L/R +seconds (that is, a slot equals the time to transmit one frame). Nodes +start to transmit frames only at the beginnings of slots. The nodes are +synchronized so that each node knows when the slots begin. If two or +more frames collide in a slot, then all the nodes detect the collision +event before the slot ends. Let p be a probability, that is, a number +between 0 and 1. The operation of slotted ALOHA in each node is simple: +When the node has a fresh frame to send, it waits until the beginning of +the next slot and transmits the entire frame in the slot. If there isn't +a collision, the node has successfully transmitted its frame and thus +need not consider retransmitting the frame. (The node can prepare a new +frame for transmission, if it has one.) If there is a collision, the +node detects the collision before the end of the slot. The node +retransmits its frame in each subsequent slot with probability p until +the frame is transmitted without a collision. By retransmitting with +probability p, we mean that the node effectively tosses a biased coin; +the event heads corresponds to "retransmit," which occurs with +probability p. The event tails corresponds to "skip the slot and toss +the coin again in the next slot"; this occurs with probability (1−p). +All nodes involved in the collision toss their coins independently. +Slotted ALOHA would appear to have many advantages. Unlike channel +partitioning, slotted ALOHA allows a node to transmit continuously at +the full rate, R, when that node is the only active node. (A node is +said to be active if it has frames to send.) Slotted ALOHA is also +highly decentralized, because each node detects collisions and +independently decides when to retransmit. (Slotted ALOHA does, however, +require the slots to be synchronized in the nodes; shortly we'll discuss +an unslotted version of the ALOHA protocol, as well as CSMA protocols, +none of which require such synchronization.) Slotted ALOHA is also an +extremely simple protocol. Slotted ALOHA works well when there is only +one active node, but how efficient is it when there are multiple active +nodes? There are two possible efficiency + + Figure 6.10 Nodes 1, 2, and 3 collide in the first slot. Node 2 finally +succeeds in the fourth slot, node 1 in the eighth slot, and node 3 in +the ninth slot + +concerns here. First, as shown in Figure 6.10, when there are multiple +active nodes, a certain fraction of the slots will have collisions and +will therefore be "wasted." The second concern is that another fraction +of the slots will be empty because all active nodes refrain from +transmitting as a result of the probabilistic transmission policy. The +only "unwasted" slots will be those in which exactly one node transmits. +A slot in which exactly one node transmits is said to be a successful +slot. The efficiency of a slotted multiple access protocol is defined to +be the long-run fraction of successful slots in the case when there are +a large number of active nodes, each always having a large number of +frames to send. Note that if no form of access control were used, and +each node were to immediately retransmit after each collision, the +efficiency would be zero. Slotted ALOHA clearly increases the efficiency +beyond zero, but by how much? We now proceed to outline the derivation +of the maximum efficiency of slotted ALOHA. To keep this derivation +simple, let's modify the protocol a little and assume that each node +attempts to transmit a frame in each slot with probability p. (That is, +we assume that each node always has a frame to send and that the node +transmits with probability p for a fresh frame as well as for a frame +that has already suffered a collision.) Suppose there are N nodes. Then +the probability that a given slot is a successful slot is the +probability that one of the nodes transmits and that the remaining N−1 +nodes do not transmit. The probability that a given node transmits is p; +the probability that the remaining nodes do not transmit is (1−p)N−1. +Therefore the probability a given node has a success is p(1−p)N−1. +Because there are N nodes, the probability that any one of the N nodes +has a success is Np(1−p)N−1. Thus, when there are N active nodes, the +efficiency of slotted ALOHA is Np(1−p)N−1. To obtain the maximum +efficiency for N active nodes, we have to find the p\* that maximizes +this expression. (See the + + homework problems for a general outline of this derivation.) And to +obtain the maximum efficiency for a large number of active nodes, we +take the limit of Np*(1−p*)N−1 as N approaches infinity. (Again, see the +homework problems.) After performing these calculations, we'll find that +the maximum efficiency of the protocol is given by 1/e=0.37. That is, +when a large number of nodes have many frames to transmit, then (at +best) only 37 percent of the slots do useful work. Thus the effective +transmission rate of the channel is not R bps but only 0.37 R bps! A +similar analysis also shows that 37 percent of the slots go empty and 26 +percent of slots have collisions. Imagine the poor network administrator +who has purchased a 100-Mbps slotted ALOHA system, expecting to be able +to use the network to transmit data among a large number of users at an +aggregate rate of, say, 80 Mbps! Although the channel is capable of +transmitting a given frame at the full channel rate of 100 Mbps, in the +long run, the successful throughput of this channel will be less than 37 +Mbps. ALOHA The slotted ALOHA protocol required that all nodes +synchronize their transmissions to start at the beginning of a slot. The +first ALOHA protocol \[Abramson 1970\] was actually an unslotted, fully +decentralized protocol. In pure ALOHA, when a frame first arrives (that +is, a network-layer datagram is passed down from the network layer at +the sending node), the node immediately transmits the frame in its +entirety into the broadcast channel. If a transmitted frame experiences +a collision with one or more other transmissions, the node will then +immediately (after completely transmitting its collided frame) +retransmit the frame with probability p. Otherwise, the node waits for a +frame transmission time. After this wait, it then transmits the frame +with probability p, or waits (remaining idle) for another frame time +with probability 1 -- p. To determine the maximum efficiency of pure +ALOHA, we focus on an individual node. We'll make the same assumptions +as in our slotted ALOHA analysis and take the frame transmission time to +be the unit of time. At any given time, the probability that a node is +transmitting a frame is p. Suppose this frame begins transmission at +time t0. As shown in Figure 6.11, in order for this frame to be +successfully transmitted, no other nodes can begin their transmission in +the interval of time \[ t0−1,t0\]. Such a transmission would overlap +with the beginning of the transmission of node i's frame. The +probability that all other nodes do not begin a transmission in this +interval is (1−p)N−1. Similarly, no other node can begin a transmission +while node i is transmitting, as such a transmission would overlap with +the latter part of node i's transmission. The probability that all other +nodes do not begin a transmission in this interval is also (1−p)N−1. +Thus, the probability that a given node has a successful transmission is +p(1−p)2(N−1). By taking limits as in the slotted ALOHA case, we find +that the maximum efficiency of the pure ALOHA protocol is only +1/(2e)---exactly half that of slotted ALOHA. This then is the price to +be paid for a fully decentralized ALOHA protocol. + + Figure 6.11 Interfering transmissions in pure ALOHA + +Carrier Sense Multiple Access (CSMA) In both slotted and pure ALOHA, a +node's decision to transmit is made independently of the activity of the +other nodes attached to the broadcast channel. In particular, a node +neither pays attention to whether another node happens to be +transmitting when it begins to transmit, nor stops transmitting if +another node begins to interfere with its transmission. In our cocktail +party analogy, ALOHA protocols are quite like a boorish partygoer who +continues to chatter away regardless of whether other people are +talking. As humans, we have human protocols that allow us not only to +behave with more civility, but also to decrease the amount of time spent +"colliding" with each other in conversation and, consequently, to +increase the amount of data we exchange in our conversations. +Specifically, there are two important rules for polite human +conversation: Listen before speaking. If someone else is speaking, wait +until they are finished. In the networking world, this is called carrier +sensing---a node listens to the channel before transmitting. If a frame +from another node is currently being transmitted into the channel, a +node then waits until it detects no transmissions for a short amount of +time and then begins transmission. If someone else begins talking at the +same time, stop talking. In the networking world, this is called +collision detection---a transmitting node listens to the channel while +it is transmitting. If it detects that another node is transmitting an +interfering frame, it stops transmitting and waits a random amount of +time before repeating the sense-and-transmit-when-idle cycle. These two +rules are embodied in the family of carrier sense multiple access (CSMA) +and CSMA with collision detection (CSMA/CD) protocols \[Kleinrock 1975b; +Metcalfe 1976; Lam 1980; Rom 1990\]. Many variations on CSMA and + +CASE HISTORY + + NORM ABRAMSON AND ALOHANET Norm Abramson, a PhD engineer, had a passion +for surfing and an interest in packet switching. This combination of +interests brought him to the University of Hawaii in 1969. Hawaii +consists of many mountainous islands, making it difficult to install and +operate land-based networks. When not surfing, Abramson thought about +how to design a network that does packet switching over radio. The +network he designed had one central host and several secondary nodes +scattered over the Hawaiian Islands. The network had two channels, each +using a different frequency band. The downlink channel broadcasted +packets from the central host to the secondary hosts; and the upstream +channel sent packets from the secondary hosts to the central host. In +addition to sending informational packets, the central host also sent on +the downstream channel an acknowledgment for each packet successfully +received from the secondary hosts. Because the secondary hosts +transmitted packets in a decentralized fashion, collisions on the +upstream channel inevitably occurred. This observation led Abramson to +devise the pure ALOHA protocol, as described in this chapter. In 1970, +with continued funding from ARPA, Abramson connected his ALOHAnet to the +ARPAnet. Abramson's work is important not only because it was the first +example of a radio packet network, but also because it inspired Bob +Metcalfe. A few years later, Metcalfe modified the ALOHA protocol to +create the CSMA/CD protocol and the Ethernet LAN. + +CSMA/CD have been proposed. Here, we'll consider a few of the most +important, and fundamental, characteristics of CSMA and CSMA/CD. The +first question that you might ask about CSMA is why, if all nodes +perform carrier sensing, do collisions occur in the first place? After +all, a node will refrain from transmitting whenever it senses that +another node is transmitting. The answer to the question can best be +illustrated using space-time diagrams \[Molle 1987\]. Figure 6.12 shows +a space-time diagram of four nodes (A, B, C, D) attached to a linear +broadcast bus. The horizontal axis shows the position of each node in +space; the vertical axis represents time. At time t0, node B senses the +channel is idle, as no other nodes are currently transmitting. Node B +thus begins transmitting, with its bits propagating in both directions +along the broadcast medium. The downward propagation of B's bits in +Figure 6.12 with increasing time indicates that a nonzero amount of time +is needed for B's bits actually to propagate (albeit at near the speed +of light) along the broadcast medium. At time t1(t1\>t0), node D has a +frame to send. Although node B is currently transmitting at time t1, the +bits being transmitted by B have yet to reach D, and thus D senses + + Figure 6.12 Space-time diagram of two CSMA nodes with colliding +transmissions + +the channel idle at t1. In accordance with the CSMA protocol, D thus +begins transmitting its frame. A short time later, B's transmission +begins to interfere with D's transmission at D. From Figure 6.12, it is +evident that the end-to-end channel propagation delay of a broadcast +channel---the time it takes for a signal to propagate from one of the +nodes to another---will play a crucial role in determining its +performance. The longer this propagation delay, the larger the chance +that a carrier-sensing node is not yet able to sense a transmission that +has already begun at another node in the network. Carrier Sense Multiple +Access with Collision Dection (CSMA/CD) In Figure 6.12, nodes do not +perform collision detection; both B and D continue to transmit their +frames in their entirety even though a collision has occurred. When a +node performs collision detection, it ceases transmission as soon as it +detects a collision. Figure 6.13 shows the same scenario as in Figure +6.12, except that the two + + Figure 6.13 CSMA with collision detection + +nodes each abort their transmission a short time after detecting a +collision. Clearly, adding collision detection to a multiple access +protocol will help protocol performance by not transmitting a useless, +damaged (by interference with a frame from another node) frame in its +entirety. Before analyzing the CSMA/CD protocol, let us now summarize +its operation from the perspective of an adapter (in a node) attached to +a broadcast channel: + +1. The adapter obtains a datagram from the network layer, prepares a + link-layer frame, and puts the frame adapter buffer. + +2. If the adapter senses that the channel is idle (that is, there is no + signal energy entering the adapter from the channel), it starts to + transmit the frame. If, on the other hand, the adapter senses that + the channel is busy, it waits until it senses no signal energy and + then starts to transmit the frame. + +3. While transmitting, the adapter monitors for the presence of signal + energy coming from other adapters using the broadcast channel. + +4. If the adapter transmits the entire frame without detecting signal + energy from other adapters, the + + adapter is finished with the frame. If, on the other hand, the adapter +detects signal energy from other adapters while transmitting, it aborts +the transmission (that is, it stops transmitting its frame). + +5. After aborting, the adapter waits a random amount of time and then + returns to step 2. The need to wait a random (rather than fixed) + amount of time is hopefully clear---if two nodes transmitted frames + at the same time and then both waited the same fixed amount of time, + they'd continue colliding forever. But what is a good interval of + time from which to choose the random backoff time? If the interval + is large and the number of colliding nodes is small, nodes are + likely to wait a large amount of time (with the channel remaining + idle) before repeating the sense-and-transmit-when-idle step. On the + other hand, if the interval is small and the number of colliding + nodes is large, it's likely that the chosen random values will be + nearly the same, and transmitting nodes will again collide. What + we'd like is an interval that is short when the number of colliding + nodes is small, and long when the number of colliding nodes is + large. The binary exponential backoff algorithm, used in Ethernet as + well as in DOCSIS cable network multiple access protocols \[DOCSIS + 2011\], elegantly solves this problem. Specifically, when + transmitting a frame that has already experienced n collisions, a + node chooses the value of K at random from { 0,1,2,...2n−1}. Thus, + the more collisions experienced by a frame, the larger the interval + from which K is chosen. For Ethernet, the actual amount of time a + node waits is K⋅512 bit times (i.e., K times the amount of time + needed to send 512 bits into the Ethernet) and the maximum value + that n can take is capped at +6. Let's look at an example. Suppose that a node attempts to transmit a + frame for the first time and while transmitting it detects a + collision. The node then chooses K=0 with probability 0.5 or chooses + K=1 with probability 0.5. If the node chooses K=0, then it + immediately begins sensing the channel. If the node chooses K=1, it + waits 512 bit times (e.g., 5.12 microseconds for a 100 Mbps + Ethernet) before beginning the sense-and-transmit-when-idle cycle. + After a second collision, K is chosen with equal probability from + {0,1,2,3}. After three collisions, K is chosen with equal + probability from {0,1,2,3,4,5,6,7}. After 10 or more collisions, K + is chosen with equal probability from {0,1,2,..., 1023}. Thus, the + size of the sets from which K is chosen grows exponentially with the + number of collisions; for this reason this algorithm is referred to + as binary exponential backoff. We also note here that each time a + node prepares a new frame for transmission, it runs the CSMA/CD + algorithm, not taking into account any collisions that may have + occurred in the recent past. So it is possible that a node with a + new frame will immediately be able to sneak in a successful + transmission while several other nodes are in the exponential + backoff state. CSMA/CD Efficiency + + When only one node has a frame to send, the node can transmit at the +full channel rate (e.g., for Ethernet typical rates are 10 Mbps, 100 +Mbps, or 1 Gbps). However, if many nodes have frames to transmit, the +effective transmission rate of the channel can be much less. We define +the efficiency of CSMA/CD to be the long-run fraction of time during +which frames are being transmitted on the channel without collisions +when there is a large number of active nodes, with each node having a +large number of frames to send. In order to present a closed-form +approximation of the efficiency of Ethernet, let dprop denote the +maximum time it takes signal energy to propagate between any two +adapters. Let dtrans be the time to transmit a maximum-size frame +(approximately 1.2 msecs for a 10 Mbps Ethernet). A derivation of the +efficiency of CSMA/CD is beyond the scope of this book (see \[Lam 1980\] +and \[Bertsekas 1991\]). Here we simply state the following +approximation: Efficiency=11+5dprop/dtrans We see from this formula that +as dprop approaches 0, the efficiency approaches 1. This matches our +intuition that if the propagation delay is zero, colliding nodes will +abort immediately without wasting the channel. Also, as dtrans becomes +very large, efficiency approaches 1. This is also intuitive because when +a frame grabs the channel, it will hold on to the channel for a very +long time; thus, the channel will be doing productive work most of the +time. + +6.3.3 Taking-Turns Protocols Recall that two desirable properties of a +multiple access protocol are (1) when only one node is active, the +active node has a throughput of R bps, and (2) when M nodes are active, +then each active node has a throughput of nearly R/M bps. The ALOHA and +CSMA protocols have this first property but not the second. This has +motivated researchers to create another class of protocols---the +taking-turns protocols. As with random access protocols, there are +dozens of taking-turns protocols, and each one of these protocols has +many variations. We'll discuss two of the more important protocols here. +The first one is the polling protocol. The polling protocol requires one +of the nodes to be designated as a master node. The master node polls +each of the nodes in a round-robin fashion. In particular, the master +node first sends a message to node 1, saying that it (node 1) can +transmit up to some maximum number of frames. After node 1 transmits +some frames, the master node tells node 2 it (node 2) can transmit up to +the maximum number of frames. (The master node can determine when a node +has finished sending its frames by observing the lack of a signal on the +channel.) The procedure continues in this manner, with the master node +polling each of the nodes in a cyclic manner. The polling protocol +eliminates the collisions and empty slots that plague random access +protocols. This allows polling to achieve a much higher efficiency. But +it also has a few drawbacks. The first drawback is that the protocol +introduces a polling delay---the amount of time required to notify a +node that it can + + transmit. If, for example, only one node is active, then the node will +transmit at a rate less than R bps, as the master node must poll each of +the inactive nodes in turn each time the active node has sent its +maximum number of frames. The second drawback, which is potentially more +serious, is that if the master node fails, the entire channel becomes +inoperative. The 802.15 protocol and the Bluetooth protocol we will +study in Section 6.3 are examples of polling protocols. The second +taking-turns protocol is the token-passing protocol. In this protocol +there is no master node. A small, special-purpose frame known as a token +is exchanged among the nodes in some fixed order. For example, node 1 +might always send the token to node 2, node 2 might always send the +token to node 3, and node N might always send the token to node 1. When +a node receives a token, it holds onto the token only if it has some +frames to transmit; otherwise, it immediately forwards the token to the +next node. If a node does have frames to transmit when it receives the +token, it sends up to a maximum number of frames and then forwards the +token to the next node. Token passing is decentralized and highly +efficient. But it has its problems as well. For example, the failure of +one node can crash the entire channel. Or if a node accidentally +neglects to release the token, then some recovery procedure must be +invoked to get the token back in circulation. Over the years many +token-passing protocols have been developed, including the fiber +distributed data interface (FDDI) protocol \[Jain 1994\] and the IEEE +802.5 token ring protocol \[IEEE 802.5 2012\], and each one had to +address these as well as other sticky issues. + +6.3.4 DOCSIS: The Link-Layer Protocol for Cable Internet Access In the +previous three subsections, we've learned about three broad classes of +multiple access protocols: channel partitioning protocols, random access +protocols, and taking turns protocols. A cable access network will make +for an excellent case study here, as we'll find aspects of each of these +three classes of multiple access protocols with the cable access +network! Recall from Section 1.2.1 that a cable access network typically +connects several thousand residential cable modems to a cable modem +termination system (CMTS) at the cable network headend. The +DataOver-Cable Service Interface Specifications (DOCSIS) \[DOCSIS 2011\] +specifies the cable data network architecture and its protocols. DOCSIS +uses FDM to divide the downstream (CMTS to modem) and upstream (modem to +CMTS) network segments into multiple frequency channels. Each downstream +channel is 6 MHz wide, with a maximum throughput of approximately 40 +Mbps per channel (although this data rate is seldom seen at a cable +modem in practice); each upstream channel has a maximum channel width of +6.4 MHz, and a maximum upstream throughput of approximately 30 Mbps. +Each upstream and + + Figure 6.14 Upstream and downstream channels between CMTS and cable +modems + +downstream channel is a broadcast channel. Frames transmitted on the +downstream channel by the CMTS are received by all cable modems +receiving that channel; since there is just a single CMTS transmitting +into the downstream channel, however, there is no multiple access +problem. The upstream direction, however, is more interesting and +technically challenging, since multiple cable modems share the same +upstream channel (frequency) to the CMTS, and thus collisions can +potentially occur. As illustrated in Figure 6.14, each upstream channel +is divided into intervals of time (TDM-like), each containing a sequence +of mini-slots during which cable modems can transmit to the CMTS. The +CMTS explicitly grants permission to individual cable modems to transmit +during specific mini-slots. The CMTS accomplishes this by sending a +control message known as a MAP message on a downstream channel to +specify which cable modem (with data to send) can transmit during which +mini-slot for the interval of time specified in the control message. +Since mini-slots are explicitly allocated to cable modems, the CMTS can +ensure there are no colliding transmissions during a mini-slot. But how +does the CMTS know which cable modems have data to send in the first +place? This is accomplished by having cable modems send +mini-slot-request frames to the CMTS during a special set of interval +mini-slots that are dedicated for this purpose, as shown in Figure 6.14. +These mini-slotrequest frames are transmitted in a random access manner +and so may collide with each other. A cable modem can neither sense +whether the upstream channel is busy nor detect collisions. Instead, the +cable modem infers that its mini-slot-request frame experienced a +collision if it does not receive a response to the requested allocation +in the next downstream control message. When a collision is inferred, a +cable modem uses binary exponential backoff to defer the retransmission +of its mini-slot-request frame to a future time slot. When there is +little traffic on the upstream channel, a cable modem may actually +transmit data frames during slots nominally assigned for +mini-slot-request frames (and thus avoid having + + to wait for a mini-slot assignment). A cable access network thus serves +as a terrific example of multiple access protocols in action---FDM, TDM, +random access, and centrally allocated time slots all within one +network! + + 6.4 Switched Local Area Networks Having covered broadcast networks and +multiple access protocols in the previous section, let's turn our +attention next to switched local networks. Figure 6.15 shows a switched +local network connecting three departments, two servers and a router +with four switches. Because these switches operate at the link layer, +they switch link-layer frames (rather than network-layer datagrams), +don't recognize network-layer addresses, and don't use routing +algorithms like RIP or OSPF to determine + +Figure 6.15 An institutional network connected together by four switches + +paths through the network of layer-2 switches. Instead of using IP +addresses, we will soon see that they use link-layer addresses to +forward link-layer frames through the network of switches. We'll begin +our study of switched LANs by first covering link-layer addressing +(Section 6.4.1). We then examine the celebrated Ethernet protocol +(Section 6.5.2). After examining link-layer addressing and Ethernet, +we'll look at how link-layer switches operate (Section 6.4.3), and then +see (Section 6.4.4) how these switches are often used to build +large-scale LANs. + + 6.4.1 Link-Layer Addressing and ARP Hosts and routers have link-layer +addresses. Now you might find this surprising, recalling from Chapter 4 +that hosts and routers have network-layer addresses as well. You might +be asking, why in the world do we need to have addresses at both the +network and link layers? In addition to describing the syntax and +function of the link-layer addresses, in this section we hope to shed +some light on why the two layers of addresses are useful and, in fact, +indispensable. We'll also cover the Address Resolution Protocol (ARP), +which provides a mechanism to translate IP addresses to link-layer +addresses. MAC Addresses In truth, it is not hosts and routers that have +link-layer addresses but rather their adapters (that is, network +interfaces) that have link-layer addresses. A host or router with +multiple network interfaces will thus have multiple link-layer addresses +associated with it, just as it would also have multiple IP addresses +associated with it. It's important to note, however, that link-layer +switches do not have linklayer addresses associated with their +interfaces that connect to hosts and routers. This is because the job of +the link-layer switch is to carry datagrams between hosts and routers; a +switch does this job transparently, that is, without the host or router +having to explicitly address the frame to the intervening switch. This +is illustrated in Figure 6.16. A link-layer address is variously called +a LAN address, a physical address, or a MAC address. Because MAC address +seems to be the most popular term, we'll henceforth refer to link-layer +addresses as MAC addresses. For most LANs (including Ethernet and 802.11 +wireless LANs), the MAC address is 6 bytes long, giving 248 possible MAC +addresses. As shown in Figure 6.16, these 6-byte addresses are typically +expressed in hexadecimal notation, with each byte of the address +expressed as a pair of hexadecimal numbers. Although MAC addresses were +designed to be permanent, it is now possible to change an adapter's MAC +address via software. For the rest of this section, however, we'll +assume that an adapter's MAC address is fixed. One interesting property +of MAC addresses is that no two adapters have the same address. This +might seem surprising given that adapters are manufactured in many +countries by many companies. How does a company manufacturing adapters +in Taiwan make sure that it is using different addresses from a company +manufacturing + + Figure 6.16 Each interface connected to a LAN has a unique MAC address + +adapters in Belgium? The answer is that the IEEE manages the MAC address +space. In particular, when a company wants to manufacture adapters, it +purchases a chunk of the address space consisting of 224 addresses for a +nominal fee. IEEE allocates the chunk of 224 addresses by fixing the +first 24 bits of a MAC address and letting the company create unique +combinations of the last 24 bits for each adapter. An adapter's MAC +address has a flat structure (as opposed to a hierarchical structure) +and doesn't change no matter where the adapter goes. A laptop with an +Ethernet interface always has the same MAC address, no matter where the +computer goes. A smartphone with an 802.11 interface always has the same +MAC address, no matter where the smartphone goes. Recall that, in +contrast, IP addresses have a hierarchical structure (that is, a network +part and a host part), and a host's IP addresses needs to be changed +when the host moves, i.e., changes the network to which it is attached. +An adapter's MAC address is analogous to a person's social security +number, which also has a flat addressing structure and which doesn't +change no matter where the person goes. An IP address is analogous to a +person's postal address, which is hierarchical and which must be changed +whenever a person moves. Just as a person may find it useful to have +both a postal address and a social security number, it is useful for a +host and router interfaces to have both a network-layer address and a +MAC address. When an adapter wants to send a frame to some destination +adapter, the sending adapter inserts the destination adapter's MAC +address into the frame and then sends the frame into the LAN. As we will +soon see, a switch occasionally broadcasts an incoming frame onto all of +its interfaces. We'll see in Chapter 7 that 802.11 also broadcasts +frames. Thus, an adapter may receive a frame that isn't addressed to it. +Thus, when an adapter receives a frame, it will check to see whether the +destination MAC address in the frame matches its own MAC address. If +there is a match, the adapter extracts the enclosed datagram and passes +the datagram up the protocol stack. If there isn't a match, the adapter +discards the frame, without passing the network-layer datagram up. Thus, +the destination only will be + + interrupted when the frame is received. However, sometimes a sending +adapter does want all the other adapters on the LAN to receive and +process the frame it is about to send. In this case, the sending adapter +inserts a special MAC broadcast address into the destination address +field of the frame. For LANs that use 6-byte addresses (such as Ethernet +and 802.11), the broadcast address is a string of 48 consecutive 1s +(that is, FF-FF-FF-FF-FFFF in hexadecimal notation). Address Resolution +Protocol (ARP) Because there are both network-layer addresses (for +example, Internet IP addresses) and link-layer addresses (that is, MAC +addresses), there is a need to translate between them. For the Internet, +this is the job of the Address Resolution Protocol (ARP) \[RFC 826\]. To +understand the need for a protocol such as ARP, consider the network +shown in Figure 6.17. In this simple example, each host and router has a +single IP address and single MAC address. As usual, IP addresses are +shown in dotted-decimal + +PRINCIPLES IN PRACTICE KEEPING THE LAYERS INDEPENDENT There are several +reasons why hosts and router interfaces have MAC addresses in addition +to network-layer addresses. First, LANs are designed for arbitrary +network-layer protocols, not just for IP and the Internet. If adapters +were assigned IP addresses rather than "neutral" MAC addresses, then +adapters would not easily be able to support other network-layer +protocols (for example, IPX or DECnet). Second, if adapters were to use +network-layer addresses instead of MAC addresses, the network-layer +address would have to be stored in the adapter RAM and reconfigured +every time the adapter was moved (or powered up). Another option is to +not use any addresses in the adapters and have each adapter pass the +data (typically, an IP datagram) of each frame it receives up the +protocol stack. The network layer could then check for a matching +network-layer address. One problem with this option is that the host +would be interrupted by every frame sent on the LAN, including by frames +that were destined for other hosts on the same broadcast LAN. In +summary, in order for the layers to be largely independent building +blocks in a network architecture, different layers need to have their +own addressing scheme. We have now seen three types of addresses: host +names for the application layer, IP addresses for the network layer, and +MAC addresses for the link layer. + + Figure 6.17 Each interface on a LAN has an IP address and a MAC address + +notation and MAC addresses are shown in hexadecimal notation. For the +purposes of this discussion, we will assume in this section that the +switch broadcasts all frames; that is, whenever a switch receives a +frame on one interface, it forwards the frame on all of its other +interfaces. In the next section, we will provide a more accurate +explanation of how switches operate. Now suppose that the host with IP +address 222.222.222.220 wants to send an IP datagram to host +222.222.222.222. In this example, both the source and destination are in +the same subnet, in the addressing sense of Section 4.3.3. To send a +datagram, the source must give its adapter not only the IP datagram but +also the MAC address for destination 222.222.222.222. The sending +adapter will then construct a link-layer frame containing the +destination's MAC address and send the frame into the LAN. The important +question addressed in this section is, How does the sending host +determine the MAC address for the destination host with IP address +222.222.222.222? As you might have guessed, it uses ARP. An ARP module +in the sending host takes any IP address on the same LAN as input, and +returns the corresponding MAC address. In the example at hand, sending +host 222.222.222.220 provides its ARP module the IP address +222.222.222.222, and the ARP module returns the corresponding MAC +address 49-BD-D2-C7-56-2A. So we see that ARP resolves an IP address to +a MAC address. In many ways it is analogous to DNS (studied in Section +2.5), which resolves host names to IP addresses. However, one important +difference between the two resolvers is that DNS resolves host names for +hosts anywhere in the Internet, whereas ARP resolves IP addresses only +for hosts and router interfaces on the same subnet. If a node in +California were to try to use ARP to resolve the IP address for a node +in Mississippi, ARP would return with an error. + + Figure 6.18 A possible ARP table in 222.222.222.220 + +Now that we have explained what ARP does, let's look at how it works. +Each host and router has an ARP table in its memory, which contains +mappings of IP addresses to MAC addresses. Figure 6.18 shows what an ARP +table in host 222.222.222.220 might look like. The ARP table also +contains a timeto-live (TTL) value, which indicates when each mapping +will be deleted from the table. Note that a table does not necessarily +contain an entry for every host and router on the subnet; some may have +never been entered into the table, and others may have expired. A +typical expiration time for an entry is 20 minutes from when an entry is +placed in an ARP table. Now suppose that host 222.222.222.220 wants to +send a datagram that is IP-addressed to another host or router on that +subnet. The sending host needs to obtain the MAC address of the +destination given the IP address. This task is easy if the sender's ARP +table has an entry for the destination node. But what if the ARP table +doesn't currently have an entry for the destination? In particular, +suppose 222.222.222.220 wants to send a datagram to 222.222.222.222. In +this case, the sender uses the ARP protocol to resolve the address. +First, the sender constructs a special packet called an ARP packet. An +ARP packet has several fields, including the sending and receiving IP +and MAC addresses. Both ARP query and response packets have the same +format. The purpose of the ARP query packet is to query all the other +hosts and routers on the subnet to determine the MAC address +corresponding to the IP address that is being resolved. Returning to our +example, 222.222.222.220 passes an ARP query packet to the adapter along +with an indication that the adapter should send the packet to the MAC +broadcast address, namely, FF-FF-FFFF-FF-FF. The adapter encapsulates +the ARP packet in a link-layer frame, uses the broadcast address for the +frame's destination address, and transmits the frame into the subnet. +Recalling our social security number/postal address analogy, an ARP +query is equivalent to a person shouting out in a crowded room of +cubicles in some company (say, AnyCorp): "What is the social security +number of the person whose postal address is Cubicle 13, Room 112, +AnyCorp, Palo Alto, California?" The frame containing the ARP query is +received by all the other adapters on the subnet, and (because of the +broadcast address) each adapter passes the ARP packet within the frame +up to its ARP module. Each of these ARP modules checks to see if its IP +address matches the destination IP address in the ARP packet. The one +with a match sends back to the querying host a response ARP packet with +the desired mapping. The querying host 222.222.222.220 can then update +its ARP table and send its IP datagram, encapsulated in a link-layer +frame whose destination MAC is that of the host or router responding to +the earlier ARP query. + + There are a couple of interesting things to note about the ARP protocol. +First, the query ARP message is sent within a broadcast frame, whereas +the response ARP message is sent within a standard frame. Before reading +on you should think about why this is so. Second, ARP is plug-and-play; +that is, an ARP table gets built automatically---it doesn't have to be +configured by a system administrator. And if a host becomes disconnected +from the subnet, its entry is eventually deleted from the other ARP +tables in the subnet. Students often wonder if ARP is a link-layer +protocol or a network-layer protocol. As we've seen, an ARP packet is +encapsulated within a link-layer frame and thus lies architecturally +above the link layer. However, an ARP packet has fields containing +link-layer addresses and thus is arguably a link-layer protocol, but it +also contains network-layer addresses and thus is also arguably a +network-layer protocol. In the end, ARP is probably best considered a +protocol that straddles the boundary between the link and network +layers---not fitting neatly into the simple layered protocol stack we +studied in Chapter 1. Such are the complexities of real-world protocols! +Sending a Datagram off the Subnet It should now be clear how ARP +operates when a host wants to send a datagram to another host on the +same subnet. But now let's look at the more complicated situation when a +host on a subnet wants to send a network-layer datagram to a host off +the subnet (that is, across a router onto another subnet). Let's discuss +this issue in the context of Figure 6.19, which shows a simple network +consisting of two subnets interconnected by a router. There are several +interesting things to note about Figure 6.19. Each host has exactly one +IP address and one adapter. But, as discussed in Chapter 4, a router has +an IP address for each of its interfaces. For each router interface +there is also an ARP module (in the router) and an adapter. Because the +router in Figure 6.19 has two interfaces, it has two IP addresses, two +ARP modules, and two adapters. Of course, each adapter in the network +has its own MAC address. + +Figure 6.19 Two subnets interconnected by a router + + Also note that Subnet 1 has the network address 111.111.111/24 and that +Subnet 2 has the network address 222.222.222/24. Thus all of the +interfaces connected to Subnet 1 have addresses of the form +111.111.111.xxx and all of the interfaces connected to Subnet 2 have +addresses of the form 222.222.222.xxx. Now let's examine how a host on +Subnet 1 would send a datagram to a host on Subnet 2. Specifically, +suppose that host 111.111.111.111 wants to send an IP datagram to a host +222.222.222.222. The sending host passes the datagram to its adapter, as +usual. But the sending host must also indicate to its adapter an +appropriate destination MAC address. What MAC address should the adapter +use? One might be tempted to guess that the appropriate MAC address is +that of the adapter for host 222.222.222.222, namely, 49-BD-D2-C7-56-2A. +This guess, however, would be wrong! If the sending adapter were to use +that MAC address, then none of the adapters on Subnet 1 would bother to +pass the IP datagram up to its network layer, since the frame's +destination address would not match the MAC address of any adapter on +Subnet 1. The datagram would just die and go to datagram heaven. If we +look carefully at Figure 6.19, we see that in order for a datagram to go +from 111.111.111.111 to a host on Subnet 2, the datagram must first be +sent to the router interface 111.111.111.110, which is the IP address of +the first-hop router on the path to the final destination. Thus, the +appropriate MAC address for the frame is the address of the adapter for +router interface 111.111.111.110, namely, E6-E9-00-17BB-4B. How does the +sending host acquire the MAC address for 111.111.111.110? By using ARP, +of course! Once the sending adapter has this MAC address, it creates a +frame (containing the datagram addressed to 222.222.222.222) and sends +the frame into Subnet 1. The router adapter on Subnet 1 sees that the +link-layer frame is addressed to it, and therefore passes the frame to +the network layer of the router. Hooray---the IP datagram has +successfully been moved from source host to the router! But we are not +finished. We still have to move the datagram from the router to the +destination. The router now has to determine the correct interface on +which the datagram is to be forwarded. As discussed in Chapter 4, this +is done by consulting a forwarding table in the router. The forwarding +table tells the router that the datagram is to be forwarded via router +interface 222.222.222.220. This interface then passes the datagram to +its adapter, which encapsulates the datagram in a new frame and sends +the frame into Subnet 2. This time, the destination MAC address of the +frame is indeed the MAC address of the ultimate destination. And how +does the router obtain this destination MAC address? From ARP, of +course! ARP for Ethernet is defined in RFC 826. A nice introduction to +ARP is given in the TCP/IP tutorial, RFC 1180. We'll explore ARP in more +detail in the homework problems. + +6.4.2 Ethernet + + Ethernet has pretty much taken over the wired LAN market. In the 1980s +and the early 1990s, Ethernet faced many challenges from other LAN +technologies, including token ring, FDDI, and ATM. Some of these other +technologies succeeded in capturing a part of the LAN market for a few +years. But since its invention in the mid-1970s, Ethernet has continued +to evolve and grow and has held on to its dominant position. Today, +Ethernet is by far the most prevalent wired LAN technology, and it is +likely to remain so for the foreseeable future. One might say that +Ethernet has been to local area networking what the Internet has been to +global networking. There are many reasons for Ethernet's success. First, +Ethernet was the first widely deployed high-speed LAN. Because it was +deployed early, network administrators became intimately familiar with +Ethernet--- its wonders and its quirks---and were reluctant to switch +over to other LAN technologies when they came on the scene. Second, +token ring, FDDI, and ATM were more complex and expensive than Ethernet, +which further discouraged network administrators from switching over. +Third, the most compelling reason to switch to another LAN technology +(such as FDDI or ATM) was usually the higher data rate of the new +technology; however, Ethernet always fought back, producing versions +that operated at equal data rates or higher. Switched Ethernet was also +introduced in the early 1990s, which further increased its effective +data rates. Finally, because Ethernet has been so popular, Ethernet +hardware (in particular, adapters and switches) has become a commodity +and is remarkably cheap. The original Ethernet LAN was invented in the +mid-1970s by Bob Metcalfe and David Boggs. The original Ethernet LAN +used a coaxial bus to interconnect the nodes. Bus topologies for +Ethernet actually persisted throughout the 1980s and into the mid-1990s. +Ethernet with a bus topology is a broadcast LAN ---all transmitted +frames travel to and are processed by all adapters connected to the bus. +Recall that we covered Ethernet's CSMA/CD multiple access protocol with +binary exponential backoff in Section 6.3.2. By the late 1990s, most +companies and universities had replaced their LANs with Ethernet +installations using a hub-based star topology. In such an installation +the hosts (and routers) are directly connected to a hub with +twisted-pair copper wire. A hub is a physical-layer device that acts on +individual bits rather than frames. When a bit, representing a zero or a +one, arrives from one interface, the hub simply recreates the bit, +boosts its energy strength, and transmits the bit onto all the other +interfaces. Thus, Ethernet with a hub-based star topology is also a +broadcast LAN---whenever a hub receives a bit from one of its +interfaces, it sends a copy out on all of its other interfaces. In +particular, if a hub receives frames from two different interfaces at +the same time, a collision occurs and the nodes that created the frames +must retransmit. In the early 2000s Ethernet experienced yet another +major evolutionary change. Ethernet installations continued to use a +star topology, but the hub at the center was replaced with a switch. +We'll be examining switched Ethernet in depth later in this chapter. For +now, we only mention that a switch is not only "collision-less" but is +also a bona-fide store-and-forward packet switch; but unlike routers, +which operate up through layer 3, a switch operates only up through +layer 2. + + Figure 6.20 Ethernet frame structure + +Ethernet Frame Structure We can learn a lot about Ethernet by examining +the Ethernet frame, which is shown in Figure 6.20. To give this +discussion about Ethernet frames a tangible context, let's consider +sending an IP datagram from one host to another host, with both hosts on +the same Ethernet LAN (for example, the Ethernet LAN in Figure 6.17.) +(Although the payload of our Ethernet frame is an IP datagram, we note +that an Ethernet frame can carry other network-layer packets as well.) +Let the sending adapter, adapter A, have the MAC address +AA-AA-AA-AA-AA-AA and the receiving adapter, adapter B, have the MAC +address BB-BB-BB-BB-BB-BB. The sending adapter encapsulates the IP +datagram within an Ethernet frame and passes the frame to the physical +layer. The receiving adapter receives the frame from the physical layer, +extracts the IP datagram, and passes the IP datagram to the network +layer. In this context, let's now examine the six fields of the Ethernet +frame, as shown in Figure 6.20. Data field (46 to 1,500 bytes). This +field carries the IP datagram. The maximum transmission unit (MTU) of +Ethernet is 1,500 bytes. This means that if the IP datagram exceeds +1,500 bytes, then the host has to fragment the datagram, as discussed in +Section 4.3.2. The minimum size of the data field is 46 bytes. This +means that if the IP datagram is less than 46 bytes, the data field has +to be "stuffed" to fill it out to 46 bytes. When stuffing is used, the +data passed to the network layer contains the stuffing as well as an IP +datagram. The network layer uses the length field in the IP datagram +header to remove the stuffing. Destination address (6 bytes). This field +contains the MAC address of the destination adapter, BBBB-BB-BB-BB-BB. +When adapter B receives an Ethernet frame whose destination address is +either BB-BB-BB-BB-BB-BB or the MAC broadcast address, it passes the +contents of the frame's data field to the network layer; if it receives +a frame with any other MAC address, it discards the frame. Source +address (6 bytes). This field contains the MAC address of the adapter +that transmits the frame onto the LAN, in this example, +AA-AA-AA-AA-AA-AA. Type field (2 bytes). The type field permits Ethernet +to multiplex network-layer protocols. To understand this, we need to +keep in mind that hosts can use other network-layer protocols besides +IP. In fact, a given host may support multiple network-layer protocols +using different protocols for different applications. For this reason, +when the Ethernet frame arrives at adapter B, adapter B needs to know to +which network-layer protocol it should pass (that is, demultiplex) the +contents of the data field. IP and other network-layer protocols (for +example, Novell IPX or AppleTalk) each have their own, standardized type +number. Furthermore, the ARP protocol (discussed in the previous + + section) has its own type number, and if the arriving frame contains an +ARP packet (i.e., has a type field of 0806 hexadecimal), the ARP packet +will be demultiplexed up to the ARP protocol. Note that the type field +is analogous to the protocol field in the network-layer datagram and the +port-number fields in the transport-layer segment; all of these fields +serve to glue a protocol at one layer to a protocol at the layer above. +Cyclic redundancy check (CRC) (4 bytes). As discussed in Section 6.2.3, +the purpose of the CRC field is to allow the receiving adapter, adapter +B, to detect bit errors in the frame. Preamble (8 bytes). The Ethernet +frame begins with an 8-byte preamble field. Each of the first 7 bytes of +the preamble has a value of 10101010; the last byte is 10101011. The +first 7 bytes of the preamble serve to "wake up" the receiving adapters +and to synchronize their clocks to that of the sender's clock. Why +should the clocks be out of synchronization? Keep in mind that adapter A +aims to transmit the frame at 10 Mbps, 100 Mbps, or 1 Gbps, depending on +the type of Ethernet LAN. However, because nothing is absolutely +perfect, adapter A will not transmit the frame at exactly the target +rate; there will always be some drift from the target rate, a drift +which is not known a priori by the other adapters on the LAN. A +receiving adapter can lock onto adapter A's clock simply by locking onto +the bits in the first 7 bytes of the preamble. The last 2 bits of the +eighth byte of the preamble (the first two consecutive 1s) alert adapter +B that the "important stuff" is about to come. All of the Ethernet +technologies provide connectionless service to the network layer. That +is, when adapter A wants to send a datagram to adapter B, adapter A +encapsulates the datagram in an Ethernet frame and sends the frame into +the LAN, without first handshaking with adapter B. This layer-2 +connectionless service is analogous to IP's layer-3 datagram service and +UDP's layer-4 connectionless service. Ethernet technologies provide an +unreliable service to the network layer. Specifically, when adapter B +receives a frame from adapter A, it runs the frame through a CRC check, +but neither sends an acknowledgment when a frame passes the CRC check +nor sends a negative acknowledgment when a frame fails the CRC check. +When a frame fails the CRC check, adapter B simply discards the frame. +Thus, adapter A has no idea whether its transmitted frame reached +adapter B and passed the CRC check. This lack of reliable transport (at +the link layer) helps to make Ethernet simple and cheap. But it also +means that the stream of datagrams passed to the network layer can have +gaps. + +CASE HISTORY BOB METCALFE AND ETHERNET As a PhD student at Harvard +University in the early 1970s, Bob Metcalfe worked on the ARPAnet at +MIT. During his studies, he also became exposed to Abramson's work on +ALOHA and random access protocols. After completing his PhD and just +before beginning a job at Xerox Palo Alto Research Center (Xerox PARC), +he visited Abramson and his University of Hawaii colleagues for three +months, getting a firsthand look at ALOHAnet. At Xerox PARC, Metcalfe + + became exposed to Alto computers, which in many ways were the +forerunners of the personal computers of the 1980s. Metcalfe saw the +need to network these computers in an inexpensive manner. So armed with +his knowledge about ARPAnet, ALOHAnet, and random access protocols, +Metcalfe---along with colleague David Boggs---invented Ethernet. +Metcalfe and Boggs's original Ethernet ran at 2.94 Mbps and linked up to +256 hosts separated by up to one mile. Metcalfe and Boggs succeeded at +getting most of the researchers at Xerox PARC to communicate through +their Alto computers. Metcalfe then forged an alliance between Xerox, +Digital, and Intel to establish Ethernet as a 10 Mbps Ethernet standard, +ratified by the IEEE. Xerox did not show much interest in +commercializing Ethernet. In 1979, Metcalfe formed his own company, +3Com, which developed and commercialized networking technology, +including Ethernet technology. In particular, 3Com developed and +marketed Ethernet cards in the early 1980s for the immensely popular IBM +PCs. + +If there are gaps due to discarded Ethernet frames, does the application +at Host B see gaps as well? As we learned in Chapter 3, this depends on +whether the application is using UDP or TCP. If the application is using +UDP, then the application in Host B will indeed see gaps in the data. On +the other hand, if the application is using TCP, then TCP in Host B will +not acknowledge the data contained in discarded frames, causing TCP in +Host A to retransmit. Note that when TCP retransmits data, the data will +eventually return to the Ethernet adapter at which it was discarded. +Thus, in this sense, Ethernet does retransmit data, although Ethernet is +unaware of whether it is transmitting a brand-new datagram with +brand-new data, or a datagram that contains data that has already been +transmitted at least once. Ethernet Technologies In our discussion +above, we've referred to Ethernet as if it were a single protocol +standard. But in fact, Ethernet comes in many different flavors, with +somewhat bewildering acronyms such as 10BASE-T, 10BASE-2, 100BASE-T, +1000BASE-LX, 10GBASE-T and 40GBASE-T. These and many other Ethernet +technologies have been standardized over the years by the IEEE 802.3 +CSMA/CD (Ethernet) working group \[IEEE 802.3 2012\]. While these +acronyms may appear bewildering, there is actually considerable order +here. The first part of the acronym refers to the speed of the standard: +10, 100, 1000, or 10G, for 10 Megabit (per second), 100 Megabit, +Gigabit, 10 Gigabit and 40 Gigibit Ethernet, respectively. "BASE" refers +to baseband Ethernet, meaning that the physical media only carries +Ethernet traffic; almost all of the 802.3 standards are for baseband +Ethernet. The final part of the acronym refers to the physical media +itself; Ethernet is both a link-layer and a physical-layer specification +and is carried over a variety of physical media including coaxial cable, +copper wire, and fiber. Generally, a "T" refers to twisted-pair copper +wires. Historically, an Ethernet was initially conceived of as a segment +of coaxial cable. The early 10BASE-2 and 10BASE-5 standards specify 10 +Mbps Ethernet over two types of coaxial cable, each limited in + + length to 500 meters. Longer runs could be obtained by using a +repeater---a physical-layer device that receives a signal on the input +side, and regenerates the signal on the output side. A coaxial cable +corresponds nicely to our view of Ethernet as a broadcast medium---all +frames transmitted by one interface are received at other interfaces, +and Ethernet's CDMA/CD protocol nicely solves the multiple access +problem. Nodes simply attach to the cable, and voila, we have a local +area network! Ethernet has passed through a series of evolutionary steps +over the years, and today's Ethernet is very different from the original +bus-topology designs using coaxial cable. In most installations today, +nodes are connected to a switch via point-to-point segments made of +twisted-pair copper wires or fiber-optic cables, as shown in Figures +6.15--6.17. In the mid-1990s, Ethernet was standardized at 100 Mbps, 10 +times faster than 10 Mbps Ethernet. The original Ethernet MAC protocol +and frame format were preserved, but higher-speed physical layers were +defined for copper wire (100BASE-T) and fiber (100BASE-FX, 100BASE-SX, +100BASE-BX). Figure 6.21 shows these different standards and the common +Ethernet MAC protocol and frame format. 100 Mbps Ethernet is limited to +a 100-meter distance over twisted pair, and to + +Figure 6.21 100 Mbps Ethernet standards: A common link layer, different +physical layers + +several kilometers over fiber, allowing Ethernet switches in different +buildings to be connected. Gigabit Ethernet is an extension to the +highly successful 10 Mbps and 100 Mbps Ethernet standards. Offering a +raw data rate of 40,000 Mbps, 40 Gigabit Ethernet maintains full +compatibility with the huge installed base of Ethernet equipment. The +standard for Gigabit Ethernet, referred to as IEEE 802.3z, does the +following: Uses the standard Ethernet frame format (Figure 6.20) and is +backward compatible with 10BASE-T and 100BASE-T technologies. This +allows for easy integration of Gigabit Ethernet with the existing +installed base of Ethernet equipment. Allows for point-to-point links as +well as shared broadcast channels. Point-to-point links use switches +while broadcast channels use hubs, as described earlier. In Gigabit +Ethernet jargon, hubs are called buffered distributors. Uses CSMA/CD for +shared broadcast channels. In order to have acceptable efficiency, the + + maximum distance between nodes must be severely restricted. Allows for +full-duplex operation at 40 Gbps in both directions for point-to-point +channels. Initially operating over optical fiber, Gigabit Ethernet is +now able to run over category 5 UTP cabling. Let's conclude our +discussion of Ethernet technology by posing a question that may have +begun troubling you. In the days of bus topologies and hub-based star +topologies, Ethernet was clearly a broadcast link (as defined in Section +6.3) in which frame collisions occurred when nodes transmitted at the +same time. To deal with these collisions, the Ethernet standard included +the CSMA/CD protocol, which is particularly effective for a wired +broadcast LAN spanning a small geographical region. But if the prevalent +use of Ethernet today is a switch-based star topology, using +store-and-forward packet switching, is there really a need anymore for +an Ethernet MAC protocol? As we'll see shortly, a switch coordinates its +transmissions and never forwards more than one frame onto the same +interface at any time. Furthermore, modern switches are full-duplex, so +that a switch and a node can each send frames to each other at the same +time without interference. In other words, in a switch-based Ethernet +LAN there are no collisions and, therefore, there is no need for a MAC +protocol! As we've seen, today's Ethernets are very different from the +original Ethernet conceived by Metcalfe and Boggs more than 30 years +ago---speeds have increased by three orders of magnitude, Ethernet +frames are carried over a variety of media, switched-Ethernets have +become dominant, and now even the MAC protocol is often unnecessary! Is +all of this really still Ethernet? The answer, of course, is "yes, by +definition." It is interesting to note, however, that through all of +these changes, there has indeed been one enduring constant that has +remained unchanged over 30 years---Ethernet's frame format. Perhaps this +then is the one true and timeless centerpiece of the Ethernet standard. + +6.4.3 Link-Layer Switches Up until this point, we have been purposefully +vague about what a switch actually does and how it works. The role of +the switch is to receive incoming link-layer frames and forward them +onto outgoing links; we'll study this forwarding function in detail in +this subsection. We'll see that the switch itself is transparent to the +hosts and routers in the subnet; that is, a host/router addresses a +frame to another host/router (rather than addressing the frame to the +switch) and happily sends the frame into the LAN, unaware that a switch +will be receiving the frame and forwarding it. The rate at which frames +arrive to any one of the switch's output interfaces may temporarily +exceed the link capacity of that interface. To accommodate this problem, +switch output interfaces have buffers, in much the same way that router +output interfaces have buffers for datagrams. Let's now take a closer +look at how switches operate. Forwarding and Filtering + + Filtering is the switch function that determines whether a frame should +be forwarded to some interface or should just be dropped. Forwarding is +the switch function that determines the interfaces to which a frame +should be directed, and then moves the frame to those interfaces. Switch +filtering and forwarding are done with a switch table. The switch table +contains entries for some, but not necessarily all, of the hosts and +routers on a LAN. An entry in the switch table contains (1) a MAC +address, (2) the switch interface that leads toward that MAC address, +and (3) the time at which the entry was placed in the table. An example +switch table for the uppermost switch in Figure 6.15 is shown in Figure +6.22. This description of frame forwarding may sound similar to our +discussion of datagram forwarding + +Figure 6.22 Portion of a switch table for the uppermost switch in Figure +6.15 + +in Chapter 4. Indeed, in our discussion of generalized forwarding in +Section 4.4, we learned that many modern packet switches can be +configured to forward on the basis of layer-2 destination MAC addresses +(i.e., function as a layer-2 switch) or layer-3 IP destination addresses +(i.e., function as a layer-3 router). Nonetheless, we'll make the +important distinction that switches forward packets based on MAC +addresses rather than on IP addresses. We will also see that a +traditional (i.e., in a non-SDN context) switch table is constructed in +a very different manner from a router's forwarding table. To understand +how switch filtering and forwarding work, suppose a frame with +destination address DDDD-DD-DD-DD-DD arrives at the switch on interface +x. The switch indexes its table with the MAC address DD-DD-DD-DD-DD-DD. +There are three possible cases: There is no entry in the table for +DD-DD-DD-DD-DD-DD. In this case, the switch forwards copies of the frame +to the output buffers preceding all interfaces except for interface x. +In other words, if there is no entry for the destination address, the +switch broadcasts the frame. There is an entry in the table, associating +DD-DD-DD-DD-DD-DD with interface x. In this case, the frame is coming +from a LAN segment that contains adapter DD-DD-DD-DD-DD-DD. There being +no need to forward the frame to any of the other interfaces, the switch +performs the filtering function by discarding the frame. There is an +entry in the table, associating DD-DD-DD-DD-DD-DD with interface y≠x. In +this case, the frame needs to be forwarded to the LAN segment attached +to interface y. The switch performs its forwarding function by putting +the frame in an output buffer that precedes interface y. + + Let's walk through these rules for the uppermost switch in Figure 6.15 +and its switch table in Figure 6.22. Suppose that a frame with +destination address 62-FE-F7-11-89-A3 arrives at the switch from +interface 1. The switch examines its table and sees that the destination +is on the LAN segment connected to interface 1 (that is, Electrical +Engineering). This means that the frame has already been broadcast on +the LAN segment that contains the destination. The switch therefore +filters (that is, discards) the frame. Now suppose a frame with the same +destination address arrives from interface 2. The switch again examines +its table and sees that the destination is in the direction of interface +1; it therefore forwards the frame to the output buffer preceding +interface 1. It should be clear from this example that as long as the +switch table is complete and accurate, the switch forwards frames toward +destinations without any broadcasting. In this sense, a switch is +"smarter" than a hub. But how does this switch table get configured in +the first place? Are there link-layer equivalents to network-layer +routing protocols? Or must an overworked manager manually configure the +switch table? Self-Learning A switch has the wonderful property +(particularly for the already-overworked network administrator) that its +table is built automatically, dynamically, and autonomously---without +any intervention from a network administrator or from a configuration +protocol. In other words, switches are self-learning. This capability is +accomplished as follows: + +1. The switch table is initially empty. +2. For each incoming frame received on an interface, the switch stores + in its table (1) the MAC address in the frame's source address + field, (2) the interface from which the frame arrived, and + +```{=html} +<!-- --> +``` +(3) the current time. In this manner the switch records in its table the + LAN segment on which the sender resides. If every host in the LAN + eventually sends a frame, then every host will eventually get + recorded in the table. + +```{=html} +<!-- --> +``` +3. The switch deletes an address in the table if no frames are received + with that address as the source address after some period of time + (the aging time). In this manner, if a PC is replaced by another PC + (with a different adapter), the MAC address of the original PC will + eventually be purged from the switch table. Let's walk through the + self-learning property for the uppermost switch in Figure 6.15 and + its corresponding switch table in Figure 6.22. Suppose at time 9:39 + a frame with source address 01-12-2334-45-56 arrives from + interface 2. Suppose that this address is not in the switch table. + Then the switch adds a new entry to the table, as shown in Figure + 6.23. Continuing with this same example, suppose that the aging time + for this switch is 60 minutes, and no frames with source address + 62-FE-F7-11-89-A3 arrive to the switch between 9:32 and 10:32. Then + at + + time 10:32, the switch removes this address from its table. + +Figure 6.23 Switch learns about the location of an adapter with address +01-12-23-34-45-56 + +Switches are plug-and-play devices because they require no intervention +from a network administrator or user. A network administrator wanting to +install a switch need do nothing more than connect the LAN segments to +the switch interfaces. The administrator need not configure the switch +tables at the time of installation or when a host is removed from one of +the LAN segments. Switches are also full-duplex, meaning any switch +interface can send and receive at the same time. Properties of +Link-Layer Switching Having described the basic operation of a +link-layer switch, let's now consider their features and properties. We +can identify several advantages of using switches, rather than broadcast +links such as buses or hub-based star topologies: Elimination of +collisions. In a LAN built from switches (and without hubs), there is no +wasted bandwidth due to collisions! The switches buffer frames and never +transmit more than one frame on a segment at any one time. As with a +router, the maximum aggregate throughput of a switch is the sum of all +the switch interface rates. Thus, switches provide a significant +performance improvement over LANs with broadcast links. Heterogeneous +links. Because a switch isolates one link from another, the different +links in the LAN can operate at different speeds and can run over +different media. For example, the uppermost switch in Figure 6.15 might +have three1 Gbps 1000BASE-T copper links, two 100 Mbps 100BASEFX fiber +links, and one 100BASE-T copper link. Thus, a switch is ideal for mixing +legacy equipment with new equipment. Management. In addition to +providing enhanced security (see sidebar on Focus on Security), a switch +also eases network management. For example, if an adapter malfunctions +and continually sends Ethernet frames (called a jabbering adapter), a +switch can detect the problem and internally disconnect the +malfunctioning adapter. With this feature, the network administrator +need not get out of bed and drive back to work in order to correct the +problem. Similarly, a cable cut disconnects only that host that was +using the cut cable to connect to the switch. In the days of coaxial +cable, many a + + network manager spent hours "walking the line" (or more accurately, +"crawling the floor") to find the cable break that brought down the +entire network. Switches also gather statistics on bandwidth usage, +collision rates, and traffic types, and make this information available +to the network manager. This information can be used to debug and +correct problems, and to plan how the LAN should evolve in the future. +Researchers are exploring adding yet more management functionality into +Ethernet LANs in prototype deployments \[Casado 2007; Koponen 2011\]. +FOCUS ON SECURITY SNIFFING A SWITCHED LAN: SWITCH POISONING When a host +is connected to a switch, it typically only receives frames that are +intended for it. For example, consider a switched LAN in Figure 6.17. +When host A sends a frame to host B, and there is an entry for host B in +the switch table, then the switch will forward the frame only to host B. +If host C happens to be running a sniffer, host C will not be able to +sniff this A-to-B frame. Thus, in a switched-LAN environment (in +contrast to a broadcast link environment such as 802.11 LANs or +hub--based Ethernet LANs), it is more difficult for an attacker to sniff +frames. However, because the switch broadcasts frames that have +destination addresses that are not in the switch table, the sniffer at C +can still sniff some frames that are not intended for C. Furthermore, a +sniffer will be able sniff all Ethernet broadcast frames with broadcast +destination address FF--FF--FF--FF--FF--FF. A well-known attack against +a switch, called switch poisoning, is to send tons of packets to the +switch with many different bogus source MAC addresses, thereby filling +the switch table with bogus entries and leaving no room for the MAC +addresses of the legitimate hosts. This causes the switch to broadcast +most frames, which can then be picked up by the sniffer \[Skoudis +2006\]. As this attack is rather involved even for a sophisticated +attacker, switches are significantly less vulnerable to sniffing than +are hubs and wireless LANs. + +Switches Versus Routers As we learned in Chapter 4, routers are +store-and-forward packet switches that forward packets using +network-layer addresses. Although a switch is also a store-and-forward +packet switch, it is fundamentally different from a router in that it +forwards packets using MAC addresses. Whereas a router is a layer-3 +packet switch, a switch is a layer-2 packet switch. Recall, however, +that we learned in Section 4.4 that modern switches using the "match +plus action" operation can be used to forward a layer-2 frame based on +the frame's destination MAC address, as well as a layer-3 datagram using +the datagram's destination IP address. Indeed, we saw that switches +using the OpenFlow standard can perform generalized packet forwarding +based on any of eleven different frame, datagram, and transportlayer +header fields. + + Even though switches and routers are fundamentally different, network +administrators must often choose between them when installing an +interconnection device. For example, for the network in Figure 6.15, the +network administrator could just as easily have used a router instead of +a switch to connect the department LANs, servers, and internet gateway +router. Indeed, a router would permit interdepartmental communication +without creating collisions. Given that both switches and routers are +candidates for interconnection devices, what are the pros and cons of +the two approaches? + +Figure 6.24 Packet processing in switches, routers, and hosts + +First consider the pros and cons of switches. As mentioned above, +switches are plug-and-play, a property that is cherished by all the +overworked network administrators of the world. Switches can also have +relatively high filtering and forwarding rates---as shown in Figure +6.24, switches have to process frames only up through layer 2, whereas +routers have to process datagrams up through layer 3. On the other hand, +to prevent the cycling of broadcast frames, the active topology of a +switched network is restricted to a spanning tree. Also, a large +switched network would require large ARP tables in the hosts and routers +and would generate substantial ARP traffic and processing. Furthermore, +switches are susceptible to broadcast storms---if one host goes haywire +and transmits an endless stream of Ethernet broadcast frames, the +switches will forward all of these frames, causing the entire network to +collapse. Now consider the pros and cons of routers. Because network +addressing is often hierarchical (and not flat, as is MAC addressing), +packets do not normally cycle through routers even when the network has +redundant paths. (However, packets can cycle when router tables are +misconfigured; but as we learned in Chapter 4, IP uses a special +datagram header field to limit the cycling.) Thus, packets are not +restricted to a spanning tree and can use the best path between source +and destination. Because routers do not have the spanning tree +restriction, they have allowed the Internet to be built with a rich +topology that includes, for example, multiple active links between +Europe and North America. Another feature of routers is that they +provide firewall protection against layer-2 broadcast storms. Perhaps +the most significant drawback of routers, though, is that they are not +plug-and-play---they and the hosts that connect to them need their IP +addresses to be configured. Also, routers often have a larger per-packet +processing time than switches, because they have to process up through +the layer-3 fields. Finally, there + + are two different ways to pronounce the word router, either as "rootor" +or as "rowter," and people waste a lot of time arguing over the proper +pronunciation \[Perlman 1999\]. Given that both switches and routers +have their pros and cons (as summarized in Table 6.1), when should an +institutional network (for example, a university campus Table 6.1 +Comparison of the typical features of popular interconnection devices +Hubs + +Routers + +Switches + +Traffic isolation + +No + +Yes + +Yes + +Plug and play + +Yes + +No + +Yes + +Optimal routing + +No + +Yes + +No + +network or a corporate campus network) use switches, and when should it +use routers? Typically, small networks consisting of a few hundred hosts +have a few LAN segments. Switches suffice for these small networks, as +they localize traffic and increase aggregate throughput without +requiring any configuration of IP addresses. But larger networks +consisting of thousands of hosts typically include routers within the +network (in addition to switches). The routers provide a more robust +isolation of traffic, control broadcast storms, and use more +"intelligent" routes among the hosts in the network. For more discussion +of the pros and cons of switched versus routed networks, as well as a +discussion of how switched LAN technology can be extended to accommodate +two orders of magnitude more hosts than today's Ethernets, see \[Meyers +2004; Kim 2008\]. + +6.4.4 Virtual Local Area Networks (VLANs) In our earlier discussion of +Figure 6.15, we noted that modern institutional LANs are often +configured hierarchically, with each workgroup (department) having its +own switched LAN connected to the switched LANs of other groups via a +switch hierarchy. While such a configuration works well in an ideal +world, the real world is often far from ideal. Three drawbacks can be +identified in the configuration in Figure 6.15: Lack of traffic +isolation. Although the hierarchy localizes group traffic to within a +single switch, broadcast traffic (e.g., frames carrying ARP and DHCP +messages or frames whose destination has not yet been learned by a +self-learning switch) must still traverse the entire institutional +network. + + Limiting the scope of such broadcast traffic would improve LAN +performance. Perhaps more importantly, it also may be desirable to limit +LAN broadcast traffic for security/privacy reasons. For example, if one +group contains the company's executive management team and another group +contains disgruntled employees running Wireshark packet sniffers, the +network manager may well prefer that the executives' traffic never even +reaches employee hosts. This type of isolation could be provided by +replacing the center switch in Figure 6.15 with a router. We'll see +shortly that this isolation also can be achieved via a switched (layer +2) solution. Inefficient use of switches. If instead of three groups, +the institution had 10 groups, then 10 firstlevel switches would be +required. If each group were small, say less than 10 people, then a +single 96-port switch would likely be large enough to accommodate +everyone, but this single switch would not provide traffic isolation. +Managing users. If an employee moves between groups, the physical +cabling must be changed to connect the employee to a different switch in +Figure 6.15. Employees belonging to two groups make the problem even +harder. Fortunately, each of these difficulties can be handled by a +switch that supports virtual local area networks (VLANs). As the name +suggests, a switch that supports VLANs allows multiple virtual local +area networks to be defined over a single physical local area network +infrastructure. Hosts within a VLAN communicate with each other as if +they (and no other hosts) were connected to the switch. In a port-based +VLAN, the switch's ports (interfaces) are divided into groups by the +network manager. Each group constitutes a VLAN, with the ports in each +VLAN forming a broadcast domain (i.e., broadcast traffic from one port +can only reach other ports in the group). Figure 6.25 shows a single +switch with 16 ports. Ports 2 to 8 belong to the EE VLAN, while ports 9 +to 15 belong to the CS VLAN (ports 1 and 16 are unassigned). This VLAN +solves all of the difficulties noted above---EE and CS VLAN frames are +isolated from each other, the two switches in Figure 6.15 have been +replaced by a single switch, and if the user at switch port 8 joins the +CS Department, the network operator simply reconfigures the VLAN +software so that port 8 is now associated with the CS VLAN. One can +easily imagine how the VLAN switch is configured and operates---the +network manager declares a port to belong + +Figure 6.25 A single switch with two configured VLANs + + to a given VLAN (with undeclared ports belonging to a default VLAN) +using switch management software, a table of port-to-VLAN mappings is +maintained within the switch; and switch hardware only delivers frames +between ports belonging to the same VLAN. But by completely isolating +the two VLANs, we have introduced a new difficulty! How can traffic from +the EE Department be sent to the CS Department? One way to handle this +would be to connect a VLAN switch port (e.g., port 1 in Figure 6.25) to +an external router and configure that port to belong both the EE and CS +VLANs. In this case, even though the EE and CS departments share the +same physical switch, the logical configuration would look as if the EE +and CS departments had separate switches connected via a router. An IP +datagram going from the EE to the CS department would first cross the EE +VLAN to reach the router and then be forwarded by the router back over +the CS VLAN to the CS host. Fortunately, switch vendors make such +configurations easy for the network manager by building a single device +that contains both a VLAN switch and a router, so a separate external +router is not needed. A homework problem at the end of the chapter +explores this scenario in more detail. Returning again to Figure 6.15, +let's now suppose that rather than having a separate Computer +Engineering department, some EE and CS faculty are housed in a separate +building, where (of course!) they need network access, and (of course!) +they'd like to be part of their department's VLAN. Figure 6.26 shows a +second 8-port switch, where the switch ports have been defined as +belonging to the EE or the CS VLAN, as needed. But how should these two +switches be interconnected? One easy solution would be to define a port +belonging to the CS VLAN on each switch (similarly for the EE VLAN) and +to connect these ports to each other, as shown in Figure 6.26(a). This +solution doesn't scale, however, since N VLANS would require N ports on +each switch simply to interconnect the two switches. A more scalable +approach to interconnecting VLAN switches is known as VLAN trunking. In +the VLAN trunking approach shown in Figure 6.26(b), a special port on +each switch (port 16 on the left switch and port 1 on the right switch) +is configured as a trunk port to interconnect the two VLAN switches. The +trunk port belongs to all VLANs, and frames sent to any VLAN are +forwarded over the trunk link to the other switch. But this raises yet +another question: How does a switch know that a frame arriving on a +trunk port belongs to a particular VLAN? The IEEE has defined an +extended Ethernet frame format, 802.1Q, for frames crossing a VLAN +trunk. As shown in Figure 6.27, the 802.1Q frame consists of the +standard Ethernet frame with a four-byte VLAN tag added into the header +that carries the identity of the VLAN to which the frame belongs. The +VLAN tag is added into a frame by the switch at the sending side of a +VLAN trunk, parsed, and removed by the switch at the receiving side of +the trunk. The VLAN tag itself consists of a 2-byte Tag Protocol +Identifier (TPID) field (with a fixed hexadecimal value of 81-00), a +2byte Tag Control Information field that contains a 12-bit VLAN +identifier field, and a 3-bit priority field that is similar in intent +to the IP datagram TOS field. + + Figure 6.26 Connecting two VLAN switches with two VLANs: (a) two cables +(b) trunked + +Figure 6.27 Original Ethernet frame (top), 802.1Q-tagged Ethernet VLAN +frame (below) + +In this discussion, we've only briefly touched on VLANs and have focused +on port-based VLANs. We should also mention that VLANs can be defined in +several other ways. In MAC-based VLANs, the network manager specifies +the set of MAC addresses that belong to each VLAN; whenever a device +attaches to a port, the port is connected into the appropriate VLAN +based on the MAC address of the device. VLANs can also be defined based +on network-layer protocols (e.g., IPv4, IPv6, or Appletalk) and other +criteria. It is also possible for VLANs to be extended across IP +routers, allowing islands of LANs to be connected together to form a +single VLAN that could span the globe \[Yu 2011\]. See the 802.1Q +standard \[IEEE 802.1q 2005\] for more details. + + 6.5 Link Virtualization: A Network as a Link Layer Because this chapter +concerns link-layer protocols, and given that we're now nearing the +chapter's end, let's reflect on how our understanding of the term link +has evolved. We began this chapter by viewing the link as a physical +wire connecting two communicating hosts. In studying multiple access +protocols, we saw that multiple hosts could be connected by a shared +wire and that the "wire" connecting the hosts could be radio spectra or +other media. This led us to consider the link a bit more abstractly as a +channel, rather than as a wire. In our study of Ethernet LANs (Figure +6.15) we saw that the interconnecting media could actually be a rather +complex switched infrastructure. Throughout this evolution, however, the +hosts themselves maintained the view that the interconnecting medium was +simply a link-layer channel connecting two or more hosts. We saw, for +example, that an Ethernet host can be blissfully unaware of whether it +is connected to other LAN hosts by a single short LAN segment (Figure +6.17) or by a geographically dispersed switched LAN (Figure 6.15) or by +a VLAN (Figure 6.26). In the case of a dialup modem connection between +two hosts, the link connecting the two hosts is actually the telephone +network---a logically separate, global telecommunications network with +its own switches, links, and protocol stacks for data transfer and +signaling. From the Internet link-layer point of view, however, the +dial-up connection through the telephone network is viewed as a simple +"wire." In this sense, the Internet virtualizes the telephone network, +viewing the telephone network as a link-layer technology providing +link-layer connectivity between two Internet hosts. You may recall from +our discussion of overlay networks in Chapter 2 that an overlay network +similarly views the Internet as a means for providing connectivity +between overlay nodes, seeking to overlay the Internet in the same way +that the Internet overlays the telephone network. In this section, we'll +consider Multiprotocol Label Switching (MPLS) networks. Unlike the +circuit-switched telephone network, MPLS is a packet-switched, +virtual-circuit network in its own right. It has its own packet formats +and forwarding behaviors. Thus, from a pedagogical viewpoint, a +discussion of MPLS fits well into a study of either the network layer or +the link layer. From an Internet viewpoint, however, we can consider +MPLS, like the telephone network and switched-Ethernets, as a link-layer +technology that serves to interconnect IP devices. Thus, we'll consider +MPLS in our discussion of the link layer. Framerelay and ATM networks +can also be used to interconnect IP devices, though they represent a +slightly older (but still deployed) technology and will not be covered +here; see the very readable book \[Goralski 1999\] for details. Our +treatment of MPLS will be necessarily brief, as entire books could be +(and have been) written on these networks. We recommend \[Davie 2000\] +for details on MPLS. We'll focus here primarily on how MPLS servers +interconnect to IP devices, although we'll dive a bit deeper into the +underlying technologies as well. + + 6.5.1 Multiprotocol Label Switching (MPLS) Multiprotocol Label Switching +(MPLS) evolved from a number of industry efforts in the mid-to-late +1990s to improve the forwarding speed of IP routers by adopting a key +concept from the world of virtual-circuit networks: a fixed-length +label. The goal was not to abandon the destination-based IP +datagramforwarding infrastructure for one based on fixed-length labels +and virtual circuits, but to augment it by selectively labeling +datagrams and allowing routers to forward datagrams based on +fixed-length labels (rather than destination IP addresses) when +possible. Importantly, these techniques work hand-in-hand with IP, using +IP addressing and routing. The IETF unified these efforts in the MPLS +protocol \[RFC 3031, RFC 3032\], effectively blending VC techniques into +a routed datagram network. Let's begin our study of MPLS by considering +the format of a link-layer frame that is handled by an MPLS-capable +router. Figure 6.28 shows that a link-layer frame transmitted between +MPLS-capable devices has a small MPLS header added between the layer-2 +(e.g., Ethernet) header and layer-3 (i.e., IP) header. RFC 3032 defines +the format of the MPLS header for such links; headers are defined for +ATM and frame-relayed networks as well in other RFCs. Among the fields +in the MPLS + +Figure 6.28 MPLS header: Located between link- and network-layer headers + +header are the label, 3 bits reserved for experimental use, a single S +bit, which is used to indicate the end of a series of "stacked" MPLS +headers (an advanced topic that we'll not cover here), and a time-tolive +field. It's immediately evident from Figure 6.28 that an MPLS-enhanced +frame can only be sent between routers that are both MPLS capable (since +a non-MPLS-capable router would be quite confused when it found an MPLS +header where it had expected to find the IP header!). An MPLS-capable +router is often referred to as a label-switched router, since it +forwards an MPLS frame by looking up the MPLS label in its forwarding +table and then immediately passing the datagram to the appropriate +output interface. Thus, the MPLS-capable router need not extract the +destination IP address and perform a lookup of the longest prefix match +in the forwarding table. But how does a router know if its neighbor is +indeed MPLS capable, and how does a router know what label to associate +with the given IP destination? To answer these questions, we'll need to +take a look at the interaction among a group of MPLS-capable routers. + + In the example in Figure 6.29, routers R1 through R4 are MPLS capable. +R5 and R6 are standard IP routers. R1 has advertised to R2 and R3 that +it (R1) can route to destination A, and that a received frame with MPLS +label 6 will be forwarded to destination A. Router R3 has advertised to +router R4 that it can route to destinations A and D, and that incoming +frames with MPLS labels 10 and 12, respectively, will be switched toward +those destinations. Router R2 has also advertised to router R4 that it +(R2) can reach destination A, and that a received frame with MPLS label +8 will be switched toward A. Note that router R4 is now in the +interesting position of having + +Figure 6.29 MPLS-enhanced forwarding + +two MPLS paths to reach A: via interface 0 with outbound MPLS label 10, +and via interface 1 with an MPLS label of 8. The broad picture painted +in Figure 6.29 is that IP devices R5, R6, A, and D are connected +together via an MPLS infrastructure (MPLS-capable routers R1, R2, R3, +and R4) in much the same way that a switched LAN or an ATM network can +connect together IP devices. And like a switched LAN or ATM network, the +MPLS-capable routers R1 through R4 do so without ever touching the IP +header of a packet. In our discussion above, we've not specified the +specific protocol used to distribute labels among the MPLS-capable +routers, as the details of this signaling are well beyond the scope of +this book. We note, however, that the IETF working group on MPLS has +specified in \[RFC 3468\] that an extension of the RSVP protocol, known +as RSVP-TE \[RFC 3209\], will be the focus of its efforts for MPLS +signaling. We've also not discussed how MPLS actually computes the paths +for packets among MPLS capable routers, nor how it gathers link-state +information (e.g., amount of link bandwidth unreserved by MPLS) to + + use in these path computations. Existing link-state routing algorithms +(e.g., OSPF) have been extended to flood this information to +MPLS-capable routers. Interestingly, the actual path computation +algorithms are not standardized, and are currently vendor-specific. Thus +far, the emphasis of our discussion of MPLS has been on the fact that +MPLS performs switching based on labels, without needing to consider the +IP address of a packet. The true advantages of MPLS and the reason for +current interest in MPLS, however, lie not in the potential increases in +switching speeds, but rather in the new traffic management capabilities +that MPLS enables. As noted above, R4 has two MPLS paths to A. If +forwarding were performed up at the IP layer on the basis of IP address, +the IP routing protocols we studied in Chapter 5 would specify only a +single, least-cost path to A. Thus, MPLS provides the ability to forward +packets along routes that would not be possible using standard IP +routing protocols. This is one simple form of traffic engineering using +MPLS \[RFC 3346; RFC 3272; RFC 2702; Xiao 2000\], in which a network +operator can override normal IP routing and force some of the traffic +headed toward a given destination along one path, and other traffic +destined toward the same destination along another path (whether for +policy, performance, or some other reason). It is also possible to use +MPLS for many other purposes as well. It can be used to perform fast +restoration of MPLS forwarding paths, e.g., to reroute traffic over a +precomputed failover path in response to link failure \[Kar 2000; Huang +2002; RFC 3469\]. Finally, we note that MPLS can, and has, been used to +implement so-called virtual private networks (VPNs). In implementing a +VPN for a customer, an ISP uses its MPLS-enabled network to connect +together the customer's various networks. MPLS can be used to isolate +both the resources and addressing used by the customer's VPN from that +of other users crossing the ISP's network; see \[DeClercq 2002\] for +details. Our discussion of MPLS has been brief, and we encourage you to +consult the references we've mentioned. We note that with so many +possible uses for MPLS, it appears that it is rapidly becoming the Swiss +Army knife of Internet traffic engineering! + + 6.6 Data Center Networking In recent years, Internet companies such as +Google, Microsoft, Facebook, and Amazon (as well as their counterparts +in Asia and Europe) have built massive data centers, each housing tens +to hundreds of thousands of hosts, and concurrently supporting many +distinct cloud applications (e.g., search, e-mail, social networking, +and e-commerce). Each data center has its own data center network that +interconnects its hosts with each other and interconnects the data +center with the Internet. In this section, we provide a brief +introduction to data center networking for cloud applications. The cost +of a large data center is huge, exceeding \$12 million per month for a +100,000 host data center \[Greenberg 2009a\]. Of these costs, about 45 +percent can be attributed to the hosts themselves (which need to be +replaced every 3--4 years); 25 percent to infrastructure, including +transformers, uninterruptable power supplies (UPS) systems, generators +for long-term outages, and cooling systems; 15 percent for electric +utility costs for the power draw; and 15 percent for networking, +including network gear (switches, routers and load balancers), external +links, and transit traffic costs. (In these percentages, costs for +equipment are amortized so that a common cost metric is applied for +one-time purchases and ongoing expenses such as power.) While networking +is not the largest cost, networking innovation is the key to reducing +overall cost and maximizing performance \[Greenberg 2009a\]. The worker +bees in a data center are the hosts: They serve content (e.g., Web pages +and videos), store e-mails and documents, and collectively perform +massively distributed computations (e.g., distributed index computations +for search engines). The hosts in data centers, called blades and +resembling pizza boxes, are generally commodity hosts that include CPU, +memory, and disk storage. The hosts are stacked in racks, with each rack +typically having 20 to 40 blades. At the top of each rack there is a +switch, aptly named the Top of Rack (TOR) switch, that interconnects the +hosts in the rack with each other and with other switches in the data +center. Specifically, each host in the rack has a network interface card +that connects to its TOR switch, and each TOR switch has additional +ports that can be connected to other switches. Today hosts typically +have 40 Gbps Ethernet connections to their TOR switches \[Greenberg +2015\]. Each host is also assigned its own data-center-internal IP +address. The data center network supports two types of traffic: traffic +flowing between external clients and internal hosts and traffic flowing +between internal hosts. To handle flows between external clients and +internal hosts, the data center network includes one or more border +routers, connecting the data center network to the public Internet. The +data center network therefore interconnects the racks with each other +and connects the racks to the border routers. Figure 6.30 shows an +example of a data center network. Data center network design, the art of +designing the interconnection network and protocols that connect the +racks with each other and with the border routers, has become an +important branch of + + computer networking research in recent years \[Al-Fares 2008; Greenberg +2009a; Greenberg 2009b; Mysore 2009; Guo 2009; Wang 2010\]. + +Figure 6.30 A data center network with a hierarchical topology + +Load Balancing A cloud data center, such as a Google or Microsoft data +center, provides many applications concurrently, such as search, e-mail, +and video applications. To support requests from external clients, each +application is associated with a publicly visible IP address to which +clients send their requests and from which they receive responses. +Inside the data center, the external requests are first directed to a +load balancer whose job it is to distribute requests to the hosts, +balancing the load across the hosts as a function of their current load. +A large data center will often have several load balancers, each one +devoted to a set of specific cloud applications. Such a load balancer is +sometimes referred to as a "layer-4 switch" since it makes decisions +based on the destination port number (layer 4) as well as destination IP +address in the packet. Upon receiving a request for a particular +application, the load balancer forwards it to one of the hosts that +handles the application. (A host may then invoke the services of other +hosts to help process the request.) When the host finishes processing +the request, it sends its response back to the load balancer, which in +turn relays the response back to the external client. The load balancer +not only balances the work load across hosts, but also provides a +NAT-like function, translating the public external IP address to the +internal IP address of the appropriate host, and + + then translating back for packets traveling in the reverse direction +back to the clients. This prevents clients from contacting hosts +directly, which has the security benefit of hiding the internal network +structure and preventing clients from directly interacting with the +hosts. Hierarchical Architecture For a small data center housing only a +few thousand hosts, a simple network consisting of a border router, a +load balancer, and a few tens of racks all interconnected by a single +Ethernet switch could possibly suffice. But to scale to tens to hundreds +of thousands of hosts, a data center often employs a hierarchy of +routers and switches, such as the topology shown in Figure 6.30. At the +top of the hierarchy, the border router connects to access routers (only +two are shown in Figure 6.30, but there can be many more). Below each +access router there are three tiers of switches. Each access router +connects to a top-tier switch, and each top-tier switch connects to +multiple second-tier switches and a load balancer. Each second-tier +switch in turn connects to multiple racks via the racks' TOR switches +(third-tier switches). All links typically use Ethernet for their +link-layer and physical-layer protocols, with a mix of copper and fiber +cabling. With such a hierarchical design, it is possible to scale a data +center to hundreds of thousands of hosts. Because it is critical for a +cloud application provider to continually provide applications with high +availability, data centers also include redundant network equipment and +redundant links in their designs (not shown in Figure 6.30). For +example, each TOR switch can connect to two tier-2 switches, and each +access router, tier-1 switch, and tier-2 switch can be duplicated and +integrated into the design \[Cisco 2012; Greenberg 2009b\]. In the +hierarchical design in Figure 6.30, observe that the hosts below each +access router form a single subnet. In order to localize ARP broadcast +traffic, each of these subnets is further partitioned into smaller VLAN +subnets, each comprising a few hundred hosts \[Greenberg 2009a\]. +Although the conventional hierarchical architecture just described +solves the problem of scale, it suffers from limited host-to-host +capacity \[Greenberg 2009b\]. To understand this limitation, consider +again Figure 6.30, and suppose each host connects to its TOR switch with +a 1 Gbps link, whereas the links between switches are 10 Gbps Ethernet +links. Two hosts in the same rack can always communicate at a full 1 +Gbps, limited only by the rate of the hosts' network interface cards. +However, if there are many simultaneous flows in the data center +network, the maximum rate between two hosts in different racks can be +much less. To gain insight into this issue, consider a traffic pattern +consisting of 40 simultaneous flows between 40 pairs of hosts in +different racks. Specifically, suppose each of 10 hosts in rack 1 in +Figure 6.30 sends a flow to a corresponding host in rack 5. Similarly, +there are ten simultaneous flows between pairs of hosts in racks 2 and +6, ten simultaneous flows between racks 3 and 7, and ten simultaneous +flows between racks 4 and 8. If each flow evenly shares a link's +capacity with other flows traversing that link, then the 40 flows +crossing the 10 Gbps A-to-B link (as well as the 10 Gbps B-to-C link) +will each only receive 10 Gbps/40=250 Mbps, which is significantly less +than the 1 Gbps network + + interface card rate. The problem becomes even more acute for flows +between hosts that need to travel higher up the hierarchy. One possible +solution to this limitation is to deploy higher-rate switches and +routers. But this would significantly increase the cost of the data +center, because switches and routers with high port speeds are very +expensive. Supporting high-bandwidth host-to-host communication is +important because a key requirement in data centers is flexibility in +placement of computation and services \[Greenberg 2009b; Farrington +2010\]. For example, a large-scale Internet search engine may run on +thousands of hosts spread across multiple racks with significant +bandwidth requirements between all pairs of hosts. Similarly, a cloud +computing service such as EC2 may wish to place the multiple virtual +machines comprising a customer's service on the physical hosts with the +most capacity irrespective of their location in the data center. If +these physical hosts are spread across multiple racks, network +bottlenecks as described above may result in poor performance. Trends in +Data Center Networking In order to reduce the cost of data centers, and +at the same time improve their delay and throughput performance, +Internet cloud giants such as Google, Facebook, Amazon, and Microsoft +are continually deploying new data center network designs. Although +these designs are proprietary, many important trends can nevertheless be +identified. One such trend is to deploy new interconnection +architectures and network protocols that overcome the drawbacks of the +traditional hierarchical designs. One such approach is to replace the +hierarchy of switches and routers with a fully connected topology +\[Facebook 2014; Al-Fares 2008; Greenberg 2009b; Guo 2009\], such as the +topology shown in Figure 6.31. In this design, each tier-1 switch +connects to all of the tier-2 switches so that (1) host-to-host traffic +never has to rise above the switch tiers, and (2) with n tier-1 +switches, between any two tier-2 switches there are n disjoint paths. +Such a design can significantly improve the host-to-host capacity. To +see this, consider again our example of 40 flows. The topology in Figure +6.31 can handle such a flow pattern since there are four distinct paths +between the first tier-2 switch and the second tier-2 switch, together +providing an aggregate capacity of 40 Gbps between the first two tier-2 +switches. Such a design not only alleviates the host-to-host capacity +limitation, but also creates a more flexible computation and service +environment in which communication between any two racks not connected +to the same switch is logically equivalent, irrespective of their +locations in the data center. Another major trend is to employ shipping +container--based modular data centers (MDCs) \[YouTube 2009; Waldrop +2007\]. In an MDC, a factory builds, within a + + Figure 6.31 Highly interconnected data network topology + +standard 12-meter shipping container, a "mini data center" and ships the +container to the data center location. Each container has up to a few +thousand hosts, stacked in tens of racks, which are packed closely +together. At the data center location, multiple containers are +interconnected with each other and also with the Internet. Once a +prefabricated container is deployed at a data center, it is often +difficult to service. Thus, each container is designed for graceful +performance degradation: as components (servers and switches) fail over +time, the container continues to operate but with degraded performance. +When many components have failed and performance has dropped below a +threshold, the entire container is removed and replaced with a fresh +one. Building a data center out of containers creates new networking +challenges. With an MDC, there are two types of networks: the +container-internal networks within each of the containers and the core +network connecting each container \[Guo 2009; Farrington 2010\]. Within +each container, at the scale of up to a few thousand hosts, it is +possible to build a fully connected network (as described above) using +inexpensive commodity Gigabit Ethernet switches. However, the design of +the core network, interconnecting hundreds to thousands of containers +while providing high host-to-host bandwidth across containers for +typical workloads, remains a challenging problem. A hybrid +electrical/optical switch architecture for interconnecting the +containers is proposed in \[Farrington 2010\]. When using highly +interconnected topologies, one of the major issues is designing routing +algorithms among the switches. One possibility \[Greenberg 2009b\] is to +use a form of random routing. Another possibility \[Guo 2009\] is to +deploy multiple network interface cards in each host, connect each host +to multiple low-cost commodity switches, and allow the hosts themselves +to intelligently route traffic among the switches. Variations and +extensions of these approaches are currently being deployed in +contemporary data centers. Another important trend is that large cloud +providers are increasingly building or customizing just about everything +that is in their data centers, including network adapters, switches +routers, TORs, software, + + and networking protocols \[Greenberg 2015, Singh 2015\]. Another trend, +pioneered by Amazon, is to improve reliability with "availability +zones," which essentially replicate distinct data centers in different +nearby buildings. By having the buildings nearby (a few kilometers +apart), transactional data can be synchronized across the data centers +in the same availability zone while providing fault tolerance \[Amazon +2014\]. Many more innovations in data center design are likely to +continue to come; interested readers are encouraged to see the recent +papers and videos on data center network design. + + 6.7 Retrospective: A Day in the Life of a Web Page Request Now that +we've covered the link layer in this chapter, and the network, transport +and application layers in earlier chapters, our journey down the +protocol stack is complete! In the very beginning of this book (Section +1.1), we wrote "much of this book is concerned with computer network +protocols," and in the first five chapters, we've certainly seen that +this is indeed the case! Before heading into the topical chapters in +second part of this book, we'd like to wrap up our journey down the +protocol stack by taking an integrated, holistic view of the protocols +we've learned about so far. One way then to take this "big picture" view +is to identify the many (many!) protocols that are involved in +satisfying even the simplest request: downloading a Web page. Figure +6.32 illustrates our setting: a student, Bob, connects a laptop to his +school's Ethernet switch and downloads a Web page (say the home page of +www.google.com). As we now know, there's a lot going on "under the hood" +to satisfy this seemingly simple request. A Wireshark lab at the end of +this chapter examines trace files containing a number of the packets +involved in similar scenarios in more detail. + +6.7.1 Getting Started: DHCP, UDP, IP, and Ethernet Let's suppose that +Bob boots up his laptop and then connects it to an Ethernet cable +connected to the school's Ethernet switch, which in turn is connected to +the school's router, as shown in Figure 6.32. The school's router is +connected to an ISP, in this example, comcast.net. In this example, +comcast.net is providing the DNS service for the school; thus, the DNS +server resides in the Comcast network rather than the school network. +We'll assume that the DHCP server is running within the router, as is +often the case. When Bob first connects his laptop to the network, he +can't do anything (e.g., download a Web page) without an IP address. +Thus, the first network-related + + Figure 6.32 A day in the life of a Web page request: Network setting and +actions + +action taken by Bob's laptop is to run the DHCP protocol to obtain an IP +address, as well as other information, from the local DHCP server: + +1. The operating system on Bob's laptop creates a DHCP request message + (Section 4.3.3) and puts this message within a UDP segment (Section + 3.3) with destination port 67 (DHCP server) and source port 68 (DHCP + client). The UDP segment is then placed within an IP datagram + (Section 4.3.1) with a broadcast IP destination address + (255.255.255.255) and a source IP address of 0.0.0.0, since Bob's + laptop doesn't yet have an IP address. + +2. The IP datagram containing the DHCP request message is then placed + within an Ethernet frame (Section 6.4.2). The Ethernet frame has a + destination MAC addresses of FF:FF:FF:FF:FF:FF so that the frame + will be broadcast to all devices connected to the switch (hopefully + including a DHCP server); the frame's source MAC address is that of + Bob's laptop, 00:16:D3:23:68:8A. + +3. The broadcast Ethernet frame containing the DHCP request is the + first frame sent by Bob's laptop to the Ethernet switch. The switch + broadcasts the incoming frame on all outgoing ports, including the + port connected to the router. + +4. The router receives the broadcast Ethernet frame containing the DHCP + request on its interface with MAC address 00:22:6B:45:1F:1B and the + IP datagram is extracted from the Ethernet frame. The datagram's + broadcast IP destination address indicates that this IP datagram + should be processed by upper layer protocols at this node, so the + datagram's payload (a UDP segment) is + + thus demultiplexed (Section 3.2) up to UDP, and the DHCP request message +is extracted from the UDP segment. The DHCP server now has the DHCP +request message. + +5. Let's suppose that the DHCP server running within the router can + allocate IP addresses in the CIDR (Section 4.3.3) block + 68.85.2.0/24. In this example, all IP addresses used within the + school are thus within Comcast's address block. Let's suppose the + DHCP server allocates address 68.85.2.101 to Bob's laptop. The DHCP + server creates a DHCP ACK message (Section 4.3.3) containing this IP + address, as well as the IP address of the DNS server (68.87.71.226), + the IP address for the default gateway router (68.85.2.1), and the + subnet block (68.85.2.0/24) (equivalently, the "network mask"). The + DHCP message is put inside a UDP segment, which is put inside an IP + datagram, which is put inside an Ethernet frame. The Ethernet frame + has a source MAC address of the router's interface to the home + network (00:22:6B:45:1F:1B) and a destination MAC address of Bob's + laptop (00:16:D3:23:68:8A). + +6. The Ethernet frame containing the DHCP ACK is sent (unicast) by the + router to the switch. Because the switch is self-learning (Section + 6.4.3) and previously received an Ethernet frame (containing the + DHCP request) from Bob's laptop, the switch knows to forward a frame + addressed to 00:16:D3:23:68:8A only to the output port leading to + Bob's laptop. + +7. Bob's laptop receives the Ethernet frame containing the DHCP ACK, + extracts the IP datagram from the Ethernet frame, extracts the UDP + segment from the IP datagram, and extracts the DHCP ACK message from + the UDP segment. Bob's DHCP client then records its IP address and + the IP address of its DNS server. It also installs the address of + the default gateway into its IP forwarding table (Section 4.1). + Bob's laptop will send all datagrams with destination address + outside of its subnet 68.85.2.0/24 to the default gateway. At this + point, Bob's laptop has initialized its networking components and is + ready to begin processing the Web page fetch. (Note that only the + last two DHCP steps of the four presented in Chapter 4 are actually + necessary.) + +6.7.2 Still Getting Started: DNS and ARP When Bob types the URL for +www.google.com into his Web browser, he begins the long chain of events +that will eventually result in Google's home page being displayed by his +Web browser. Bob's Web browser begins the process by creating a TCP +socket (Section 2.7) that will be used to send the HTTP request (Section +2.2) to www.google.com. In order to create the socket, Bob's laptop will +need to know the IP address of www.google.com. We learned in Section +2.5, that the DNS protocol is used to provide this name-to-IP-address +translation service. + +8. The operating system on Bob's laptop thus creates a DNS query + message (Section 2.5.3), putting the string "www.google.com" in the + question section of the DNS message. This DNS message is then placed + within a UDP segment with a destination port of 53 (DNS server). The + UDP segment is then placed within an IP datagram with an IP + destination address of + + 68.87.71.226 (the address of the DNS server returned in the DHCP ACK in +step 5) and a source IP address of 68.85.2.101. + +9. Bob's laptop then places the datagram containing the DNS query + message in an Ethernet frame. This frame will be sent (addressed, at + the link layer) to the gateway router in Bob's school's network. + However, even though Bob's laptop knows the IP address of the + school's gateway router (68.85.2.1) via the DHCP ACK message in step + 5 above, it doesn't know the gateway router's MAC address. In order + to obtain the MAC address of the gateway router, Bob's laptop will + need to use the ARP protocol (Section 6.4.1). + +10. Bob's laptop creates an ARP query message with a target IP address + of 68.85.2.1 (the default gateway), places the ARP message within an + Ethernet frame with a broadcast destination address + (FF:FF:FF:FF:FF:FF) and sends the Ethernet frame to the switch, + which delivers the frame to all connected devices, including the + gateway router. + +11. The gateway router receives the frame containing the ARP query + message on the interface to the school network, and finds that the + target IP address of 68.85.2.1 in the ARP message matches the IP + address of its interface. The gateway router thus prepares an ARP + reply, indicating that its MAC address of 00:22:6B:45:1F:1B + corresponds to IP address 68.85.2.1. It places the ARP reply message + in an Ethernet frame, with a destination address of + 00:16:D3:23:68:8A (Bob's laptop) and sends the frame to the switch, + which delivers the frame to Bob's laptop. + +12. Bob's laptop receives the frame containing the ARP reply message and + extracts the MAC address of the gateway router (00:22:6B:45:1F:1B) + from the ARP reply message. + +13. Bob's laptop can now (finally!) address the Ethernet frame + containing the DNS query to the gateway router's MAC address. Note + that the IP datagram in this frame has an IP destination address of + 68.87.71.226 (the DNS server), while the frame has a destination + address of 00:22:6B:45:1F:1B (the gateway router). Bob's laptop + sends this frame to the switch, which delivers the frame to the + gateway router. + +6.7.3 Still Getting Started: Intra-Domain Routing to the DNS Server 14. +The gateway router receives the frame and extracts the IP datagram +containing the DNS query. The router looks up the destination address of +this datagram (68.87.71.226) and determines from its forwarding table +that the datagram should be sent to the leftmost router in the Comcast +network in Figure 6.32. The IP datagram is placed inside a link-layer +frame appropriate for the link connecting the school's router to the +leftmost Comcast router and the frame is sent over this link. + +15. The leftmost router in the Comcast network receives the frame, + extracts the IP datagram, examines the datagram's destination + address (68.87.71.226) and determines the outgoing interface on + which to forward the datagram toward the DNS server from its + forwarding table, which has been filled in by Comcast's intra-domain + protocol (such as RIP, OSPF or IS-IS, + + Section 5.3) as well as the Internet's inter-domain protocol, BGP +(Section 5.4). + +16. Eventually the IP datagram containing the DNS query arrives at the + DNS server. The DNS server extracts the DNS query message, looks up + the name www.google.com in its DNS database (Section 2.5), and finds + the DNS resource record that contains the IP address + (64.233.169.105) for www.google.com. (assuming that it is currently + cached in the DNS server). Recall that this cached data originated + in the authoritative DNS server (Section 2.5.2) for googlecom. The + DNS server forms a DNS reply message containing this + hostname-to-IPaddress mapping, and places the DNS reply message in a + UDP segment, and the segment within an IP datagram addressed to + Bob's laptop (68.85.2.101). This datagram will be forwarded back + through the Comcast network to the school's router and from there, + via the Ethernet switch to Bob's laptop. + +17. Bob's laptop extracts the IP address of the server www.google.com + from the DNS message. Finally, after a lot of work, Bob's laptop is + now ready to contact the www.google.com server! + +6.7.4 Web Client-Server Interaction: TCP and HTTP 18. Now that Bob's +laptop has the IP address of www.google.com, it can create the TCP +socket (Section 2.7) that will be used to send the HTTP GET message +(Section 2.2.3) to www.google.com. When Bob creates the TCP socket, the +TCP in Bob's laptop must first perform a three-way handshake (Section +3.5.6) with the TCP in www.google.com. Bob's laptop thus first creates a +TCP SYN segment with destination port 80 (for HTTP), places the TCP +segment inside an IP datagram with a destination IP address of +64.233.169.105 (www.google.com), places the datagram inside a frame with +a destination MAC address of 00:22:6B:45:1F:1B (the gateway router) and +sends the frame to the switch. + +19. The routers in the school network, Comcast's network, and Google's + network forward the datagram containing the TCP SYN toward + www.google.com, using the forwarding table in each router, as in + steps 14--16 above. Recall that the router forwarding table entries + governing forwarding of packets over the inter-domain link between + the Comcast and Google networks are determined by the BGP protocol + (Chapter 5). + +20. Eventually, the datagram containing the TCP SYN arrives at + www.google.com. The TCP SYN message is extracted from the datagram + and demultiplexed to the welcome socket associated with port 80. A + connection socket (Section 2.7) is created for the TCP connection + between the Google HTTP server and Bob's laptop. A TCP SYNACK + (Section 3.5.6) segment is generated, placed inside a datagram + addressed to Bob's laptop, and finally placed inside a link-layer + frame appropriate for the link connecting www.google.com to its + first-hop router. + +21. The datagram containing the TCP SYNACK segment is forwarded through + the Google, Comcast, and school networks, eventually arriving at the + Ethernet card in Bob's laptop. The datagram is demultiplexed within + the operating system to the TCP socket created in step 18, which + enters the connected state. + + 22. With the socket on Bob's laptop now (finally!) ready to send bytes +to www.google.com, Bob's browser creates the HTTP GET message (Section +2.2.3) containing the URL to be fetched. The HTTP GET message is then +written into the socket, with the GET message becoming the payload of a +TCP segment. The TCP segment is placed in a datagram and sent and +delivered to www.google.com as in steps 18--20 above. + +23. The HTTP server at www.google.com reads the HTTP GET message from + the TCP socket, creates an HTTP response message (Section 2.2), + places the requested Web page content in the body of the HTTP + response message, and sends the message into the TCP socket. + +24. The datagram containing the HTTP reply message is forwarded through + the Google, Comcast, and school networks, and arrives at Bob's + laptop. Bob's Web browser program reads the HTTP response from the + socket, extracts the html for the Web page from the body of the HTTP + response, and finally (finally!) displays the Web page! Our scenario + above has covered a lot of networking ground! If you've understood + most or all of the above example, then you've also covered a lot of + ground since you first read Section 1.1, where we wrote "much of + this book is concerned with computer network protocols" and you may + have wondered what a protocol actually was! As detailed as the above + example might seem, we've omitted a number of possible additional + protocols (e.g., NAT running in the school's gateway router, + wireless access to the school's network, security protocols for + accessing the school network or encrypting segments or datagrams, + network management protocols), and considerations (Web caching, the + DNS hierarchy) that one would encounter in the public Internet. + We'll cover a number of these topics and more in the second part of + this book. Lastly, we note that our example above was an integrated + and holistic, but also very "nuts and bolts," view of many of the + protocols that we've studied in the first part of this book. The + example focused more on the "how" than the "why." For a broader, + more reflective view on the design of network protocols in general, + see \[Clark 1988, RFC 5218\]. + + 6.8 Summary In this chapter, we've examined the link layer---its +services, the principles underlying its operation, and a number of +important specific protocols that use these principles in implementing +link-layer services. We saw that the basic service of the link layer is +to move a network-layer datagram from one node (host, switch, router, +WiFi access point) to an adjacent node. We saw that all link-layer +protocols operate by encapsulating a network-layer datagram within a +link-layer frame before transmitting the frame over the link to the +adjacent node. Beyond this common framing function, however, we learned +that different link-layer protocols provide very different link access, +delivery, and transmission services. These differences are due in part +to the wide variety of link types over which link-layer protocols must +operate. A simple point-to-point link has a single sender and receiver +communicating over a single "wire." A multiple access link is shared +among many senders and receivers; consequently, the link-layer protocol +for a multiple access channel has a protocol (its multiple access +protocol) for coordinating link access. In the case of MPLS, the "link" +connecting two adjacent nodes (for example, two IP routers that are +adjacent in an IP sense---that they are next-hop IP routers toward some +destination) may actually be a network in and of itself. In one sense, +the idea of a network being considered as a link should not seem odd. A +telephone link connecting a home modem/computer to a remote +modem/router, for example, is actually a path through a sophisticated +and complex telephone network. Among the principles underlying +link-layer communication, we examined error-detection and -correction +techniques, multiple access protocols, link-layer addressing, +virtualization (VLANs), and the construction of extended switched LANs +and data center networks. Much of the focus today at the link layer is +on these switched networks. In the case of error detection/correction, +we examined how it is possible to add additional bits to a frame's +header in order to detect, and in some cases correct, bit-flip errors +that might occur when the frame is transmitted over the link. We covered +simple parity and checksumming schemes, as well as the more robust +cyclic redundancy check. We then moved on to the topic of multiple +access protocols. We identified and studied three broad approaches for +coordinating access to a broadcast channel: channel partitioning +approaches (TDM, FDM), random access approaches (the ALOHA protocols and +CSMA protocols), and taking-turns approaches (polling and token +passing). We studied the cable access network and found that it uses +many of these multiple access methods. We saw that a consequence of +having multiple nodes share a single broadcast channel was the need to +provide node addresses at the link layer. We learned that link-layer +addresses were quite different from network-layer addresses and that, in +the case of the Internet, a special protocol (ARP---the Address +Resolution Protocol) is used to translate between these two forms of +addressing and studied the hugely successful Ethernet protocol in +detail. We then examined how nodes sharing a broadcast channel form + + a LAN and how multiple LANs can be connected together to form larger +LANs---all without the intervention of network-layer routing to +interconnect these local nodes. We also learned how multiple virtual +LANs can be created on a single physical LAN infrastructure. We ended +our study of the link layer by focusing on how MPLS networks provide +link-layer services when they interconnect IP routers and an overview of +the network designs for today's massive data centers. We wrapped up this +chapter (and indeed the first five chapters) by identifying the many +protocols that are needed to fetch a simple Web page. Having covered the +link layer, our journey down the protocol stack is now over! Certainly, +the physical layer lies below the link layer, but the details of the +physical layer are probably best left for another course (for example, +in communication theory, rather than computer networking). We have, +however, touched upon several aspects of the physical layer in this +chapter and in Chapter 1 (our discussion of physical media in Section +1.2). We'll consider the physical layer again when we study wireless +link characteristics in the next chapter. Although our journey down the +protocol stack is over, our study of computer networking is not yet at +an end. In the following three chapters we cover wireless networking, +network security, and multimedia networking. These four topics do not +fit conveniently into any one layer; indeed, each topic crosscuts many +layers. Understanding these topics (billed as advanced topics in some +networking texts) thus requires a firm foundation in all layers of the +protocol stack---a foundation that our study of the link layer has now +completed! + + Homework Problems and Questions + +Chapter 6 Review Questions + +SECTIONS 6.1--6.2 R1. Consider the transportation analogy in Section +6.1.1 . If the passenger is analagous to a datagram, what is analogous +to the link layer frame? R2. If all the links in the Internet were to +provide reliable delivery service, would the TCP reliable delivery +service be redundant? Why or why not? R3. What are some of the possible +services that a link-layer protocol can offer to the network layer? +Which of these link-layer services have corresponding services in IP? In +TCP? + +SECTION 6.3 R4. Suppose two nodes start to transmit at the same time a +packet of length L over a broadcast channel of rate R. Denote the +propagation delay between the two nodes as dprop. Will there be a +collision if dprop\<L/R? Why or why not? R5. In Section 6.3 , we listed +four desirable characteristics of a broadcast channel. Which of these +characteristics does slotted ALOHA have? Which of these characteristics +does token passing have? R6. In CSMA/CD, after the fifth collision, what +is the probability that a node chooses K=4? The result K=4 corresponds +to a delay of how many seconds on a 10 Mbps Ethernet? R7. Describe +polling and token-passing protocols using the analogy of cocktail party +interactions. R8. Why would the token-ring protocol be inefficient if a +LAN had a very large perimeter? + +SECTION 6.4 R9. How big is the MAC address space? The IPv4 address +space? The IPv6 address space? R10. Suppose nodes A, B, and C each +attach to the same broadcast LAN (through their adapters). If A sends +thousands of IP datagrams to B with each encapsulating frame addressed +to the MAC address of B, will C's adapter process these frames? If so, +will C's adapter pass the IP datagrams in these frames to the network +layer C? How would your answers change if A sends frames with the MAC +broadcast address? R11. Why is an ARP query sent within a broadcast +frame? Why is an ARP response sent within + + a frame with a specific destination MAC address? R12. For the network in +Figure 6.19 , the router has two ARP modules, each with its own ARP +table. Is it possible that the same MAC address appears in both tables? +R13. Compare the frame structures for 10BASE-T, 100BASE-T, and Gigabit +Ethernet. How do they differ? R14. Consider Figure 6.15 . How many +subnetworks are there, in the addressing sense of Section 4.3 ? R15. +What is the maximum number of VLANs that can be configured on a switch +supporting the 802.1Q protocol? Why? R16. Suppose that N switches +supporting K VLAN groups are to be connected via a trunking protocol. +How many ports are needed to connect the switches? Justify your answer. + +Problems P1. Suppose the information content of a packet is the bit +pattern 1110 0110 1001 1101 and an even parity scheme is being used. +What would the value of the field containing the parity bits be for the +case of a two-dimensional parity scheme? Your answer should be such that +a minimumlength checksum field is used. P2. Show (give an example other +than the one in Figure 6.5 ) that two-dimensional parity checks can +correct and detect a single bit error. Show (give an example of) a +double-bit error that can be detected but not corrected. P3. Suppose the +information portion of a packet (D in Figure 6.3 ) contains 10 bytes +consisting of the 8-bit unsigned binary ASCII representation of string +"Networking." Compute the Internet checksum for this data. P4. Consider +the previous problem, but instead suppose these 10 bytes contain + +a. the binary representation of the numbers 1 through 10. + +b. the ASCII representation of the letters B through K (uppercase). + +c. the ASCII representation of the letters b through k (lowercase). + Compute the Internet checksum for this data. P5. Consider the 5-bit + generator, G=10011, and suppose that D has the value 1010101010. + What is the value of R? P6. Consider the previous problem, but + suppose that D has the value + +d. 1001010101. + +e. 101101010. + +f. 1010100000. P7. In this problem, we explore some of the properties + of the CRC. For the generator G(=1001) given in Section + 6.2.3 , answer the following questions. + + a. Why can it detect any single bit error in data D? b. Can the above G +detect any odd number of bit errors? Why? P8. In Section 6.3 , we +provided an outline of the derivation of the efficiency of slotted +ALOHA. In this problem we'll complete the derivation. + +a. Recall that when there are N active nodes, the efficiency of slotted + ALOHA is Np(1−p)N−1. Find the value of p that maximizes this + expression. + +b. Using the value of p found in (a), find the efficiency of slotted + ALOHA by letting N approach infinity. Hint: (1−1/N)N approaches 1/e + as N approaches infinity. P9. Show that the maximum efficiency of + pure ALOHA is 1/(2e). Note: This problem is easy if you have + completed the problem above! P 10. Consider two nodes, A and B, that + use the slotted ALOHA protocol to contend for a channel. Suppose + node A has more data to transmit than node B, and node A's + retransmission probability pA is greater than node B's + retransmission probability, pB. + +c. Provide a formula for node A's average throughput. What is the total + efficiency of the protocol with these two nodes? + +d. If pA=2pB, is node A's average throughput twice as large as that of + node B? Why or why not? If not, how can you choose pA and pB to make + that happen? + +e. In general, suppose there are N nodes, among which node A has + retransmission probability 2p and all other nodes have + retransmission probability p. Provide expressions to compute the + average throughputs of node A and of any other node. P11. Suppose + four active nodes---nodes A, B, C and D---are competing for access + to a channel using slotted ALOHA. Assume each node has an infinite + number of packets to send. Each node attempts to transmit in each + slot with probability p. The first slot is numbered slot 1, the + second slot is numbered slot 2, and so on. + +f. What is the probability that node A succeeds for the first time in + slot 5? + +g. What is the probability that some node (either A, B, C or D) + succeeds in slot 4? + +h. What is the probability that the first success occurs in slot 3? + +i. What is the efficiency of this four-node system? P12. Graph the + efficiency of slotted ALOHA and pure ALOHA as a function of p for + the following values of N: + +j. N=15. + +k. N=25. + +l. N=35. P13. Consider a broadcast channel with N nodes and a + transmission rate of R bps. Suppose the broadcast channel uses + polling (with an additional polling node) for multiple access. + Suppose the + + amount of time from when a node completes transmission until the +subsequent node is permitted to transmit (that is, the polling delay) is +dpoll. Suppose that within a polling round, a given node is allowed to +transmit at most Q bits. What is the maximum throughput of the broadcast +channel? P14. Consider three LANs interconnected by two routers, as +shown in Figure 6.33 . + +a. Assign IP addresses to all of the interfaces. For Subnet 1 use + addresses of the form 192.168.1.xxx; for Subnet 2 uses addresses of + the form 192.168.2.xxx; and for Subnet 3 use addresses of the form + 192.168.3.xxx. + +b. Assign MAC addresses to all of the adapters. + +c. Consider sending an IP datagram from Host E to Host B. Suppose all + of the ARP tables are up to date. Enumerate all the steps, as done + for the single-router example in Section 6.4.1 . + +d. Repeat (c), now assuming that the ARP table in the sending host is + empty (and the other tables are up to date). P15. Consider Figure + 6.33 . Now we replace the router between subnets 1 and 2 with a + switch S1, and label the router between subnets 2 and 3 as R1. + +Figure 6.33 Three subnets, interconnected by routers + +a. Consider sending an IP datagram from Host E to Host F. Will Host E + ask router R1 to help forward the datagram? Why? In the Ethernet + frame containing the IP datagram, what are the source and + destination IP and MAC addresses? + +b. Suppose E would like to send an IP datagram to B, and assume that + E's ARP cache does not contain B's MAC address. Will E perform an + ARP query to find B's MAC + + address? Why? In the Ethernet frame (containing the IP datagram destined +to B) that is delivered to router R1, what are the source and +destination IP and MAC addresses? + +c. Suppose Host A would like to send an IP datagram to Host B, and + neither A's ARP cache contains B's MAC address nor does B's ARP + cache contain A's MAC address. Further suppose that the switch S1's + forwarding table contains entries for Host B and router R1 only. + Thus, A will broadcast an ARP request message. What actions will + switch S1 perform once it receives the ARP request message? Will + router R1 also receive this ARP request message? If so, will R1 + forward the message to Subnet 3? Once Host B receives this ARP + request message, it will send back to Host A an ARP response + message. But will it send an ARP query message to ask for A's MAC + address? Why? What will switch S1 do once it receives an ARP + response message from Host B? P16. Consider the previous problem, + but suppose now that the router between subnets 2 and 3 is replaced + by a switch. Answer questions (a)--(c) in the previous problem in + this new context. P17. Recall that with the CSMA/CD protocol, the + adapter waits K⋅512 bit times after a collision, where K is drawn + randomly. For K=100, how long does the adapter wait until returning + to Step 2 for a 10 Mbps broadcast channel? For a 100 Mbps broadcast + channel? P18. Suppose nodes A and B are on the same 10 Mbps + broadcast channel, and the propagation delay between the two nodes + is 325 bit times. Suppose CSMA/CD and Ethernet packets are used for + this broadcast channel. Suppose node A begins transmitting a frame + and, before it finishes, node B begins transmitting a frame. Can A + finish transmitting before it detects that B has transmitted? Why or + why not? If the answer is yes, then A incorrectly believes that its + frame was successfully transmitted without a collision. Hint: + Suppose at time t=0 bits, A begins transmitting a frame. In the + worst case, A transmits a minimum-sized frame of 512+64 bit times. + So A would finish transmitting the frame at t=512+64 bit times. + Thus, the answer is no, if B's signal reaches A before bit time + t=512+64 bits. In the worst case, when does B's signal reach A? P19. + Suppose nodes A and B are on the same 10 Mbps broadcast channel, and + the propagation delay between the two nodes is 245 bit times. + Suppose A and B send Ethernet frames at the same time, the frames + collide, and then A and B choose different values of K in the + CSMA/CD algorithm. Assuming no other nodes are active, can the + retransmissions from A and B collide? For our purposes, it suffices + to work out the following example. Suppose A and B begin + transmission at t=0 bit times. They both detect collisions at t=245 + t bit times. Suppose KA=0 and KB=1. At what time does B schedule its + retransmission? At what time does A begin transmission? (Note: The + nodes must wait for an idle channel after returning to Step 2---see + protocol.) At what time does A's signal reach B? Does B refrain from + transmitting at its scheduled time? P20. In this problem, you will + derive the efficiency of a CSMA/CD-like multiple access protocol. In + this protocol, time is slotted and all adapters are synchronized to + the slots. Unlike slotted ALOHA, however, the length of a slot (in + seconds) is much less than a frame time (the time to transmit a + frame). Let S be the length of a slot. Suppose all frames are of + constant length + + L=kRS, where R is the transmission rate of the channel and k is a large +integer. Suppose there are N nodes, each with an infinite number of +frames to send. We also assume that dprop\<S, so that all nodes can +detect a collision before the end of a slot time. The protocol is as +follows: If, for a given slot, no node has possession of the channel, +all nodes contend for the channel; in particular, each node transmits in +the slot with probability p. If exactly one node transmits in the slot, +that node takes possession of the channel for the subsequent k−1 slots +and transmits its entire frame. If some node has possession of the +channel, all other nodes refrain from transmitting until the node that +possesses the channel has finished transmitting its frame. Once this +node has transmitted its frame, all nodes contend for the channel. Note +that the channel alternates between two states: the productive state, +which lasts exactly k slots, and the nonproductive state, which lasts +for a random number of slots. Clearly, the channel efficiency is the +ratio of k/(k+x), where x is the expected number of consecutive +unproductive slots. + +a. For fixed N and p, determine the efficiency of this protocol. + +b. For fixed N, determine the p that maximizes the efficiency. + +c. Using the p (which is a function of N) found in (b), determine the + efficiency as N approaches infinity. + +d. Show that this efficiency approaches 1 as the frame length becomes + large. P21. Consider Figure 6.33 in problem P14. Provide MAC + addresses and IP addresses for the interfaces at Host A, both + routers, and Host F. Suppose Host A sends a datagram to Host F. Give + the source and destination MAC addresses in the frame encapsulating + this IP datagram as the frame is transmitted (i) from A to the left + router, (ii) from the left router to the right router, (iii) from + the right router to F. Also give the source and destination IP + addresses in the IP datagram encapsulated within the frame at each + of these points in time. P22. Suppose now that the leftmost router + in Figure 6.33 is replaced by a switch. Hosts A, B, C, and D and the + right router are all star-connected into this switch. Give the + source and destination MAC addresses in the frame encapsulating this + IP datagram as the frame is transmitted (i) from A to the + switch, (ii) from the switch to the right router, (iii) from the + right router to F. Also give the source and destination IP addresses + in the IP datagram encapsulated within the frame at each of these + points in time. P23. Consider Figure 6.15 . Suppose that all links + are 100 Mbps. What is the maximum total aggregate throughput that + can be achieved among the 9 hosts and 2 servers in this network? You + can assume that any host or server can send to any other host or + server. Why? P24. Suppose the three departmental switches in Figure + 6.15 are replaced by hubs. All links are 100 Mbps. Now answer the + questions posed in problem P23. P25. Suppose that all the switches + in Figure 6.15 are replaced by hubs. All links are 100 Mbps. Now + answer the questions posed in problem P23. + + P26. Let's consider the operation of a learning switch in the context of +a network in which 6 nodes labeled A through F are star connected into +an Ethernet switch. Suppose that (i) B sends a frame to E, (ii) E +replies with a frame to B, (iii) A sends a frame to B, (iv) B replies +with a frame to A. The switch table is initially empty. Show the state +of the switch table before and after each of these events. For each of +these events, identify the link(s) on which the transmitted frame will +be forwarded, and briefly justify your answers. P27. In this problem, we +explore the use of small packets for Voice-over-IP applications. One of +the drawbacks of a small packet size is that a large fraction of link +bandwidth is consumed by overhead bytes. To this end, suppose that the +packet consists of P bytes and 5 bytes of header. + +a. Consider sending a digitally encoded voice source directly. Suppose + the source is encoded at a constant rate of 128 kbps. Assume each + packet is entirely filled before the source sends the packet into + the network. The time required to fill a packet is the packetization + delay. In terms of L, determine the packetization delay in + milliseconds. + +b. Packetization delays greater than 20 msec can cause a noticeable and + unpleasant echo. Determine the packetization delay for L=1,500 bytes + (roughly corresponding to a maximum-sized Ethernet packet) and for + L=50 (corresponding to an ATM packet). + +c. Calculate the store-and-forward delay at a single switch for a link + rate of R=622 Mbps for L=1,500 bytes, and for L=50 bytes. + +d. Comment on the advantages of using a small packet size. P28. + Consider the single switch VLAN in Figure 6.25 , and assume an + external router is connected to switch port 1. Assign IP addresses + to the EE and CS hosts and router interface. Trace the steps taken + at both the network layer and the link layer to transfer an IP + datagram from an EE host to a CS host (Hint: Reread the discussion + of Figure 6.19 in the text). P29. Consider the MPLS network shown in + Figure 6.29 , and suppose that routers R5 and R6 are now MPLS + enabled. Suppose that we want to perform traffic engineering so that + packets from R6 destined for A are switched to A via R6-R4-R3-R1, + and packets from R5 destined for A are switched via R5-R4-R2-R1. + Show the MPLS tables in R5 and R6, as well as the modified table in + R4, that would make this possible. P30. Consider again the same + scenario as in the previous problem, but suppose that packets from + R6 destined for D are switched via R6-R4-R3, while packets from R5 + destined to D are switched via R4-R2-R1-R3. Show the MPLS tables in + all routers that would make this possible. P31. In this problem, you + will put together much of what you have learned about Internet + protocols. Suppose you walk into a room, connect to Ethernet, and + want to download a Web page. What are all the protocol steps that + take place, starting from powering on your PC to getting the Web + page? Assume there is nothing in our DNS or browser caches when you + power on your PC. (Hint: The steps include the use of Ethernet, + DHCP, ARP, DNS, TCP, and HTTP protocols.) Explicitly indicate in + your steps how you obtain the IP and MAC addresses of a gateway + router. P32. Consider the data center network with hierarchical + topology in Figure 6.30 . Suppose now + + there are 80 pairs of flows, with ten flows between the first and ninth +rack, ten flows between the second and tenth rack, and so on. Further +suppose that all links in the network are 10 Gbps, except for the links +between hosts and TOR switches, which are 1 Gbps. + +a. Each flow has the same data rate; determine the maximum rate of a + flow. + +b. For the same traffic pattern, determine the maximum rate of a flow + for the highly interconnected topology in Figure 6.31 . + +c. Now suppose there is a similar traffic pattern, but involving 20 + hosts on each rack and 160 pairs of flows. Determine the maximum + flow rates for the two topologies. P33. Consider the hierarchical + network in Figure 6.30 and suppose that the data center needs to + support e-mail and video distribution among other applications. + Suppose four racks of servers are reserved for e-mail and four racks + are reserved for video. For each of the applications, all four racks + must lie below a single tier-2 switch since the tier-2 to tier-1 + links do not have sufficient bandwidth to support the + intra-application traffic. For the e-mail application, suppose that + for 99.9 percent of the time only three racks are used, and that the + video application has identical usage patterns. + +d. For what fraction of time does the e-mail application need to use a + fourth rack? How about for the video application? + +e. Assuming e-mail usage and video usage are independent, for what + fraction of time do (equivalently, what is the probability that) + both applications need their fourth rack? + +f. Suppose that it is acceptable for an application to have a shortage + of servers for 0.001 percent of time or less (causing rare periods + of performance degradation for users). Discuss how the topology in + Figure 6.31 can be used so that only seven racks are collectively + assigned to the two applications (assuming that the topology can + support all the traffic). + +Wireshark Labs At the Companion website for this textbook, +http://www.pearsonhighered.com/cs-resources/, you'll find a Wireshark +lab that examines the operation of the IEEE 802.3 protocol and the +Wireshark frame format. A second Wireshark lab examines packet traces +taken in a home network scenario. + +AN INTERVIEW WITH... Simon S. Lam Simon S. Lam is Professor and Regents +Chair in Computer Sciences at the University of Texas at Austin. From +1971 to 1974, he was with the ARPA Network Measurement Center at UCLA, +where he worked on satellite and radio packet switching. He led a +research group that invented secure sockets and prototyped, in 1993, the +first secure sockets layer named Secure Network Programming, which won +the 2004 ACM Software System Award. His research interests are in design +and analysis of network protocols and security services. He received his +BSEE from + + Washington State University and his MS and PhD from UCLA. He was elected +to the National Academy of Engineering in 2007. + +Why did you decide to specialize in networking? When I arrived at UCLA +as a new graduate student in Fall 1969, my intention was to study +control theory. Then I took the queuing theory classes of Leonard +Kleinrock and was very impressed by him. For a while, I was working on +adaptive control of queuing systems as a possible thesis topic. In early +1972, Larry Roberts initiated the ARPAnet Satellite System project +(later called Packet Satellite). Professor Kleinrock asked me to join +the project. The first thing we did was to introduce a simple, yet +realistic, backoff algorithm to the slotted ALOHA protocol. Shortly +thereafter, I found many interesting research problems, such as ALOHA's +instability problem and need for adaptive backoff, which would form the +core of my thesis. You were active in the early days of the Internet in +the 1970s, beginning with your student days at UCLA. What was it like +then? Did people have any inkling of what the Internet would become? The +atmosphere was really no different from other system-building projects I +have seen in industry and academia. The initially stated goal of the +ARPAnet was fairly modest, that is, to provide access to expensive +computers from remote locations so that many more scientists could use +them. However, with the startup of the Packet Satellite project in 1972 +and the Packet Radio project in 1973, ARPA's goal had expanded +substantially. By 1973, ARPA was building three different packet +networks at the same time, and it became necessary for Vint Cerf and Bob +Kahn to develop an interconnection strategy. Back then, all of these +progressive developments in networking were viewed (I believe) as +logical rather than magical. No one could have envisioned the scale of +the Internet and power of personal computers today. It was a decade +before appearance of the first PCs. To put things in perspective, most +students submitted their computer programs as decks of punched cards for +batch processing. Only some students had direct access to computers, +which were typically housed in a restricted area. Modems were slow and +still a rarity. As a graduate student, I had only a phone on my desk, +and I used pencil and paper to do most of my work. + + Where do you see the field of networking and the Internet heading in the +future? In the past, the simplicity of the Internet's IP protocol was +its greatest strength in vanquishing competition and becoming the de +facto standard for internetworking. Unlike competitors, such as X.25 in +the 1980s and ATM in the 1990s, IP can run on top of any link-layer +networking technology, because it offers only a best-effort datagram +service. Thus, any packet network can connect to the Internet. Today, +IP's greatest strength is actually a shortcoming. IP is like a +straitjacket that confines the Internet's development to specific +directions. In recent years, many researchers have redirected their +efforts to the application layer only. There is also a great deal of +research on wireless ad hoc networks, sensor networks, and satellite +networks. These networks can be viewed either as stand-alone systems or +link-layer systems, which can flourish because they are outside of the +IP straitjacket. Many people are excited about the possibility of P2P +systems as a platform for novel Internet applications. However, P2P +systems are highly inefficient in their use of Internet resources. A +concern of mine is whether the transmission and switching capacity of +the Internet core will continue to increase faster than the traffic +demand on the Internet as it grows to interconnect all kinds of devices +and support future P2P-enabled applications. Without substantial +overprovisioning of capacity, ensuring network stability in the presence +of malicious attacks and congestion will continue to be a significant +challenge. The Internet's phenomenal growth also requires the allocation +of new IP addresses at a rapid rate to network operators and enterprises +worldwide. At the current rate, the pool of unallocated IPv4 addresses +would be depleted in a few years. When that happens, large contiguous +blocks of address space can only be allocated from the IPv6 address +space. Since adoption of IPv6 is off to a slow start, due to lack of +incentives for early adopters, IPv4 and IPv6 will most likely coexist on +the Internet for many years to come. Successful migration from an +IPv4-dominant Internet to an IPv6-dominant Internet will require a +substantial global effort. What is the most challenging part of your +job? The most challenging part of my job as a professor is teaching and +motivating every student in my class, and every doctoral student under +my supervision, rather than just the high achievers. The very bright and +motivated may require a little guidance but not much else. I often learn +more from these students than they learn from me. Educating and +motivating the underachievers present a major challenge. What impacts do +you foresee technology having on learning in the future? Eventually, +almost all human knowledge will be accessible through the Internet, +which will be the most powerful tool for learning. This vast knowledge +base will have the potential of leveling the + + playing field for students all over the world. For example, motivated +students in any country will be able to access the best-class Web sites, +multimedia lectures, and teaching materials. Already, it was said that +the IEEE and ACM digital libraries have accelerated the development of +computer science researchers in China. In time, the Internet will +transcend all geographic barriers to learning. + + Chapter 7 Wireless and Mobile Networks + +In the telephony world, the past 20 years have arguably been the golden +years of cellular telephony. The number of worldwide mobile cellular +subscribers increased from 34 million in 1993 to nearly 7.0 billion +subscribers by 2014, with the number of cellular subscribers now +surpassing the number of wired telephone lines. There are now a larger +number of mobile phone subscriptions than there are people on our +planet. The many advantages of cell phones are evident to +all---anywhere, anytime, untethered access to the global telephone +network via a highly portable lightweight device. More recently, +laptops, smartphones, and tablets are wirelessly connected to the +Internet via a cellular or WiFi network. And increasingly, devices such +as gaming consoles, thermostats, home security systems, home appliances, +watches, eye glasses, cars, traffic control systems and more are being +wirelessly connected to the Internet. From a networking standpoint, the +challenges posed by networking these wireless and mobile devices, +particularly at the link layer and the network layer, are so different +from traditional wired computer networks that an individual chapter +devoted to the study of wireless and mobile networks (i.e., this +chapter) is appropriate. We'll begin this chapter with a discussion of +mobile users, wireless links, and networks, and their relationship to +the larger (typically wired) networks to which they connect. We'll draw +a distinction between the challenges posed by the wireless nature of the +communication links in such networks, and by the mobility that these +wireless links enable. Making this important distinction---between +wireless and mobility---will allow us to better isolate, identify, and +master the key concepts in each area. Note that there are indeed many +networked environments in which the network nodes are wireless but not +mobile (e.g., wireless home or office networks with stationary +workstations and large displays), and that there are limited forms of +mobility that do not require wireless links (e.g., a worker who uses a +wired laptop at home, shuts down the laptop, drives to work, and +attaches the laptop to the company's wired network). Of course, many of +the most exciting networked environments are those in which users are +both wireless and mobile---for example, a scenario in which a mobile +user (say in the back seat of car) maintains a Voice-over-IP call and +multiple ongoing TCP connections while racing down the autobahn at 160 +kilometers per hour, soon in an autonomous vehicle. It is here, at the +intersection of wireless and mobility, that we'll find the most +interesting technical challenges! + + We'll begin by illustrating the setting in which we'll consider wireless +communication and mobility---a network in which wireless (and possibly +mobile) users are connected into the larger network infrastructure by a +wireless link at the network's edge. We'll then consider the +characteristics of this wireless link in Section 7.2. We include a brief +introduction to code division multiple access (CDMA), a shared-medium +access protocol that is often used in wireless networks, in Section 7.2. +In Section 7.3, we'll examine the link-level aspects of the IEEE 802.11 +(WiFi) wireless LAN standard in some depth; we'll also say a few words +about Bluetooth and other wireless personal area networks. In Section +7.4, we'll provide an overview of cellular Internet access, including 3G +and emerging 4G cellular technologies that provide both voice and +high-speed Internet access. In Section 7.5, we'll turn our attention to +mobility, focusing on the problems of locating a mobile user, routing to +the mobile user, and "handing off" the mobile user who dynamically moves +from one point of attachment to the network to another. We'll examine +how these mobility services are implemented in the mobile IP standard in +enterprise 802.11 networks, and in LTE cellular networks in Sections 7.6 +and 7.7, respectively. Finally, we'll consider the impact of wireless +links and mobility on transport-layer protocols and networked +applications in Section 7.8. + + 7.1 Introduction Figure 7.1 shows the setting in which we'll consider +the topics of wireless data communication and mobility. We'll begin by +keeping our discussion general enough to cover a wide range of networks, +including both wireless LANs such as IEEE 802.11 and cellular networks +such as a 4G network; we'll drill down into a more detailed discussion +of specific wireless architectures in later sections. We can identify +the following elements in a wireless network: Wireless hosts. As in the +case of wired networks, hosts are the end-system devices that run +applications. A wireless host might be a laptop, tablet, smartphone, or +desktop computer. The hosts themselves may or may not be mobile. + +Figure 7.1 Elements of a wireless network + +Wireless links. A host connects to a base station (defined below) or to +another wireless host through a wireless communication link. Different +wireless link technologies have different + + transmission rates and can transmit over different distances. Figure 7.2 +shows two key characteristics (coverage area and link rate) of the more +popular wireless network standards. (The figure is only meant to provide +a rough idea of these characteristics. For example, some of these types +of networks are only now being deployed, and some link rates can +increase or decrease beyond the values shown depending on distance, +channel conditions, and the number of users in the wireless network.) +We'll cover these standards later in the first half of this chapter; +we'll also consider other wireless link characteristics (such as their +bit error rates and the causes of bit errors) in Section 7.2. In Figure +7.1, wireless links connect wireless hosts located at the edge of the +network into the larger network infrastructure. We hasten to add that +wireless links are also sometimes used within a network to connect +routers, switches, and + +Figure 7.2 Link characteristics of selected wireless network standards + +other network equipment. However, our focus in this chapter will be on +the use of wireless communication at the network edge, as it is here +that many of the most exciting technical challenges, and most of the +growth, are occurring. Base station. The base station is a key part of +the wireless network infrastructure. Unlike the wireless host and +wireless link, a base station has no obvious counterpart in a wired +network. A base station is responsible for sending and receiving data +(e.g., packets) to and from a wireless host that is associated with that +base station. A base station will often be responsible for coordinating +the transmission of multiple wireless hosts with which it is associated. +When we say a wireless host is + + "associated" with a base station, we mean that (1) the host is within +the wireless communication distance of the base station, and (2) the +host uses that base station to relay data between it (the host) and the +larger network. Cell towers in cellular networks and access points in +802.11 wireless LANs are examples of base stations. In Figure 7.1, the +base station is connected to the larger network (e.g., the Internet, +corporate or home network, or telephone network), thus functioning as a +link-layer relay between the wireless host and the rest of the world +with which the host communicates. Hosts associated with a base station +are often referred to as operating in infrastructure mode, since all +traditional network services (e.g., address assignment and routing) are +provided by the network to which a host is connected via CASE HISTORY +PUBLIC WIFI ACCESS: COMING SOON TO A LAMP POST NEAR YOU? WiFi +hotspots---public locations where users can find 802.11 wireless +access---are becoming increasingly common in hotels, airports, and cafés +around the world. Most college campuses offer ubiquitous wireless +access, and it's hard to find a hotel that doesn't offer wireless +Internet access. Over the past decade a number of cities have designed, +deployed, and operated municipal WiFi networks. The vision of providing +ubiquitous WiFi access to the community as a public service (much like +streetlights)---helping to bridge the digital divide by providing +Internet access to all citizens and to promote economic development---is +compelling. Many cities around the world, including Philadelphia, +Toronto, Hong Kong, Minneapolis, London, and Auckland, have plans to +provide ubiquitous wireless within the city, or have already done so to +varying degrees. The goal in Philadelphia was to "turn Philadelphia into +the nation's largest WiFi hotspot and help to improve education, bridge +the digital divide, enhance neighborhood development, and reduce the +costs of government." The ambitious program--- an agreement between the +city, Wireless Philadelphia (a nonprofit entity), and the Internet +Service Provider Earthlink---built an operational network of 802.11b +hotspots on streetlamp pole arms and traffic control devices that +covered 80 percent of the city. But financial and operational concerns +caused the network to be sold to a group of private investors in 2008, +who later sold the network back to the city in 2010. Other cities, such +as Minneapolis, Toronto, Hong Kong, and Auckland, have had success with +smaller-scale efforts. The fact that 802.11 networks operate in the +unlicensed spectrum (and hence can be deployed without purchasing +expensive spectrum use rights) would seem to make them financially +attractive. However, 802.11 access points (see Section 7.3) have much +shorter ranges than 4G cellular base stations (see Section 7.4), +requiring a larger number of deployed endpoints to cover the same +geographic region. Cellular data networks providing Internet access, on +the other hand, operate in the licensed spectrum. Cellular providers pay + + billions of dollars for spectrum access rights for their networks, +making cellular data networks a business rather than municipal +undertaking. the base station. In ad hoc networks, wireless hosts have +no such infrastructure with which to connect. In the absence of such +infrastructure, the hosts themselves must provide for services such as +routing, address assignment, DNS-like name translation, and more. When a +mobile host moves beyond the range of one base station and into the +range of another, it will change its point of attachment into the larger +network (i.e., change the base station with which it is associated)---a +process referred to as handoff. Such mobility raises many challenging +questions. If a host can move, how does one find the mobile host's +current location in the network so that data can be forwarded to that +mobile host? How is addressing performed, given that a host can be in +one of many possible locations? If the host moves during a TCP +connection or phone call, how is data routed so that the connection +continues uninterrupted? These and many (many!) other questions make +wireless and mobile networking an area of exciting networking research. +Network infrastructure. This is the larger network with which a wireless +host may wish to communicate. Having discussed the "pieces" of a +wireless network, we note that these pieces can be combined in many +different ways to form different types of wireless networks. You may +find a taxonomy of these types of wireless networks useful as you read +on in this chapter, or read/learn more about wireless networks beyond +this book. At the highest level we can classify wireless networks +according to two criteria: (i) whether a packet in the wireless network +crosses exactly one wireless hop or multiple wireless hops, and (ii) +whether there is infrastructure such as a base station in the network: +Single-hop, infrastructure-based. These networks have a base station +that is connected to a larger wired network (e.g., the Internet). +Furthermore, all communication is between this base station and a +wireless host over a single wireless hop. The 802.11 networks you use in +the classroom, café, or library; and the 4G LTE data networks that we +will learn about shortly all fall in this category. The vast majority of +our daily interactions are with single-hop, infrastructure-based +wireless networks. Single-hop, infrastructure-less. In these networks, +there is no base station that is connected to a wireless network. +However, as we will see, one of the nodes in this single-hop network may +coordinate the transmissions of the other nodes. Bluetooth networks +(that connect small wireless devices such as keyboards, speakers, and +headsets, and which we will study in Section 7.3.6) and 802.11 networks +in ad hoc mode are single-hop, infrastructure-less networks. Multi-hop, +infrastructure-based. In these networks, a base station is present that +is wired to the larger network. However, some wireless nodes may have to +relay their communication through other wireless nodes in order to +communicate via the base station. Some wireless sensor networks and +so-called wireless mesh networks fall in this category. Multi-hop, +infrastructure-less. There is no base station in these networks, and +nodes may have to relay messages among several other nodes in order to +reach a destination. Nodes may also be + + mobile, with connectivity changing among nodes---a class of networks +known as mobile ad hoc networks (MANETs). If the mobile nodes are +vehicles, the network is a vehicular ad hoc network (VANET). As you +might imagine, the development of protocols for such networks is +challenging and is the subject of much ongoing research. In this +chapter, we'll mostly confine ourselves to single-hop networks, and then +mostly to infrastructurebased networks. Let's now dig deeper into the +technical challenges that arise in wireless and mobile networks. We'll +begin by first considering the individual wireless link, deferring our +discussion of mobility until later in this chapter. + + 7.2 Wireless Links and Network Characteristics Let's begin by +considering a simple wired network, say a home network, with a wired +Ethernet switch (see Section 6.4) interconnecting the hosts. If we +replace the wired Ethernet with a wireless 802.11 network, a wireless +network interface would replace the host's wired Ethernet interface, and +an access point would replace the Ethernet switch, but virtually no +changes would be needed at the network layer or above. This suggests +that we focus our attention on the link layer when looking for important +differences between wired and wireless networks. Indeed, we can find a +number of important differences between a wired link and a wireless +link: Decreasing signal strength. Electromagnetic radiation attenuates +as it passes through matter (e.g., a radio signal passing through a +wall). Even in free space, the signal will disperse, resulting in +decreased signal strength (sometimes referred to as path loss) as the +distance between sender and receiver increases. Interference from other +sources. Radio sources transmitting in the same frequency band will +interfere with each other. For example, 2.4 GHz wireless phones and +802.11b wireless LANs transmit in the same frequency band. Thus, the +802.11b wireless LAN user talking on a 2.4 GHz wireless phone can expect +that neither the network nor the phone will perform particularly well. +In addition to interference from transmitting sources, electromagnetic +noise within the environment (e.g., a nearby motor, a microwave) can +result in interference. Multipath propagation. Multipath propagation +occurs when portions of the electromagnetic wave reflect off objects and +the ground, taking paths of different lengths between a sender and +receiver. This results in the blurring of the received signal at the +receiver. Moving objects between the sender and receiver can cause +multipath propagation to change over time. For a detailed discussion of +wireless channel characteristics, models, and measurements, see +\[Anderson 1995\]. The discussion above suggests that bit errors will be +more common in wireless links than in wired links. For this reason, it +is perhaps not surprising that wireless link protocols (such as the +802.11 protocol we'll examine in the following section) employ not only +powerful CRC error detection codes, but also link-level +reliable-data-transfer protocols that retransmit corrupted frames. +Having considered the impairments that can occur on a wireless channel, +let's next turn our attention to the host receiving the wireless signal. +This host receives an electromagnetic signal that is a combination of a +degraded form of the original signal transmitted by the sender (degraded +due to the attenuation and multipath propagation effects that we +discussed above, among others) and background noise in the + + environment. The signal-to-noise ratio (SNR) is a relative measure of +the strength of the received signal (i.e., the information being +transmitted) and this noise. The SNR is typically measured in units of +decibels (dB), a unit of measure that some think is used by electrical +engineers primarily to confuse computer scientists. The SNR, measured in +dB, is twenty times the ratio of the base-10 logarithm of the amplitude +of the received signal to the amplitude of the noise. For our purposes +here, we need only know that a larger SNR makes it easier for the +receiver to extract the transmitted signal from the background noise. +Figure 7.3 (adapted from \[Holland 2001\]) shows the bit error rate +(BER)---roughly speaking, the probability that a transmitted bit is +received in error at the receiver---versus the SNR for three different +modulation techniques for encoding information for transmission on an +idealized wireless channel. The theory of modulation and coding, as well +as signal extraction and BER, is well beyond the scope of + +Figure 7.3 Bit error rate, transmission rate, and SNR + +Figure 7.4 Hidden terminal problem caused by obstacle (a) and fading (b) + + this text (see \[Schwartz 1980\] for a discussion of these topics). +Nonetheless, Figure 7.3 illustrates several physical-layer +characteristics that are important in understanding higher-layer +wireless communication protocols: For a given modulation scheme, the +higher the SNR, the lower the BER. Since a sender can increase the SNR +by increasing its transmission power, a sender can decrease the +probability that a frame is received in error by increasing its +transmission power. Note, however, that there is arguably little +practical gain in increasing the power beyond a certain threshold, say +to decrease the BER from 10−12 to 10−13. There are also disadvantages +associated with increasing the transmission power: More energy must be +expended by the sender (an important concern for battery-powered mobile +users), and the sender's transmissions are more likely to interfere with +the transmissions of another sender (see Figure 7.4(b)). For a given +SNR, a modulation technique with a higher bit transmission rate (whether +in error or not) will have a higher BER. For example, in Figure 7.3, +with an SNR of 10 dB, BPSK modulation with a transmission rate of 1 Mbps +has a BER of less than 10−7, while with QAM16 modulation with a +transmission rate of 4 Mbps, the BER is 10−1, far too high to be +practically useful. However, with an SNR of 20 dB, QAM16 modulation has +a transmission rate of 4 Mbps and a BER of 10−7, while BPSK modulation +has a transmission rate of only 1 Mbps and a BER that is so low as to be +(literally) "off the charts." If one can tolerate a BER of 10−7, the +higher transmission rate offered by QAM16 would make it the preferred +modulation technique in this situation. These considerations give rise +to the final characteristic, described next. Dynamic selection of the +physical-layer modulation technique can be used to adapt the modulation +technique to channel conditions. The SNR (and hence the BER) may change +as a result of mobility or due to changes in the environment. Adaptive +modulation and coding are used in cellular data systems and in the +802.11 WiFi and 4G cellular data networks that we'll study in Sections +7.3 and 7.4. This allows, for example, the selection of a modulation +technique that provides the highest transmission rate possible subject +to a constraint on the BER, for given channel characteristics. + + A higher and time-varying bit error rate is not the only difference +between a wired and wireless link. Recall that in the case of wired +broadcast links, all nodes receive the transmissions from all other +nodes. In the case of wireless links, the situation is not as simple, as +shown in Figure 7.4. Suppose that Station A is transmitting to Station +B. Suppose also that Station C is transmitting to Station B. With the +so-called hidden terminal problem, physical obstructions in the +environment (for example, a mountain or a building) may prevent A and C +from hearing each other's transmissions, even though A's and C's +transmissions are indeed interfering at the destination, B. This is +shown in Figure 7.4(a). A second scenario that results in undetectable +collisions at the receiver results from the fading of a signal's +strength as it propagates through the wireless medium. Figure 7.4(b) +illustrates the case where A and C are placed such that their signals +are not strong enough to detect each other's transmissions, yet their +signals are strong enough to interfere with each other at station B. As +we'll see in Section 7.3, the hidden terminal problem and fading make +multiple access in a wireless network considerably more complex than in +a wired network. + +7.2.1 CDMA Recall from Chapter 6 that when hosts communicate over a +shared medium, a protocol is needed so that the signals sent by multiple +senders do not interfere at the receivers. In Chapter 6 we described +three classes of medium access protocols: channel partitioning, random +access, and taking turns. Code division multiple access (CDMA) belongs +to the family of channel partitioning protocols. It is prevalent in +wireless LAN and cellular technologies. Because CDMA is so important in +the wireless world, we'll take a quick look at CDMA now, before getting +into specific wireless access technologies in the subsequent sections. +In a CDMA protocol, each bit being sent is encoded by multiplying the +bit by a signal (the code) that changes at a much faster rate (known as +the chipping rate) than the original sequence of data bits. Figure 7.5 +shows a simple, idealized CDMA encoding/decoding scenario. Suppose that +the rate at which original data bits reach the CDMA encoder defines the +unit of time; that is, each original data bit to be transmitted requires +a one-bit slot time. Let di be the value of the data bit for the ith bit +slot. For mathematical convenience, we represent a data bit with a 0 +value as −1. Each bit slot is further subdivided into M mini-slots; in +Figure 7.5, M=8, + + Figure 7.5 A simple CDMA example: Sender encoding, receiver decoding + +although in practice M is much larger. The CDMA code used by the sender +consists of a sequence of M values, cm, m=1,..., M, each taking a+1 or +−1 value. In the example in Figure 7.5, the M-bit CDMA code being used +by the sender is (1,1,1,−1,1,−1,−1,−1). To illustrate how CDMA works, +let us focus on the ith data bit, di. For the mth mini-slot of the +bittransmission time of di, the output of the CDMA encoder, Zi,m, is the +value of di multiplied by the mth bit in the assigned CDMA code, cm: +Zi,m=di⋅cm In a simple world, with no interfering senders, the receiver +would receive the encoded bits, Zi,m, and recover the original data bit, +di, by computing: + +(7.1) + + di=1M∑m=1MZi,m⋅cm + +(7.2) + +The reader might want to work through the details of the example in +Figure 7.5 to see that the original data bits are indeed correctly +recovered at the receiver using Equation 7.2. The world is far from +ideal, however, and as noted above, CDMA must work in the presence of +interfering senders that are encoding and transmitting their data using +a different assigned code. But how can a CDMA receiver recover a +sender's original data bits when those data bits are being tangled with +bits being transmitted by other senders? CDMA works under the assumption +that the interfering transmitted bit signals are additive. This means, +for example, that if three senders send a 1 value, and a fourth sender +sends a −1 value during the same mini-slot, then the received signal at +all receivers during that mini-slot is a 2 (since 1+1+1−1=2). In the +presence of multiple senders, sender s computes its encoded +transmissions, Zi,ms, in exactly the same manner as in Equation 7.1. The +value received at a receiver during the mth mini-slot of the ith bit +slot, however, is now the sum of the transmitted bits from all N senders +during that mini-slot: Zi,m*=∑s=1NZi,ms Amazingly, if the senders' codes +are chosen carefully, each receiver can recover the data sent by a given +sender out of the aggregate signal simply by using the sender's code in +exactly the same manner as in Equation 7.2: di=1M∑m=1MZi,m*⋅cm + +(7.3) + +as shown in Figure 7.6, for a two-sender CDMA example. The M-bit CDMA +code being used by the upper sender is (1,1,1,−1,1,−1,−1,−1), while the +CDMA code being used by the lower sender is (1,−1,1,1,1,−1,1,1). Figure +7.6 illustrates a receiver recovering the original data bits from the +upper sender. Note that the receiver is able to extract the data from +sender 1 in spite of the interfering transmission from sender 2. Recall +our cocktail analogy from Chapter 6. A CDMA protocol is similar to +having partygoers speaking in multiple languages; in such circumstances +humans are actually quite good at locking into the conversation in the +language they understand, while filtering out the remaining +conversations. We see here that CDMA is a partitioning protocol in that +it partitions the codespace (as opposed to time or frequency) and +assigns each node a dedicated piece of the codespace. Our discussion +here of CDMA is necessarily brief; in practice a number of difficult +issues must be addressed. First, in order for the CDMA receivers to be +able + + Figure 7.6 A two-sender CDMA example + +to extract a particular sender's signal, the CDMA codes must be +carefully chosen. Second, our discussion has assumed that the received +signal strengths from various senders are the same; in reality this can +be difficult to achieve. There is a considerable body of literature +addressing these and other issues related to CDMA; see \[Pickholtz 1982; +Viterbi 1995\] for details. + + 7.3 WiFi: 802.11 Wireless LANs Pervasive in the workplace, the home, +educational institutions, cafés, airports, and street corners, wireless +LANs are now one of the most important access network technologies in +the Internet today. Although many technologies and standards for +wireless LANs were developed in the 1990s, one particular class of +standards has clearly emerged as the winner: the IEEE 802.11 wireless +LAN, also known as WiFi. In this section, we'll take a close look at +802.11 wireless LANs, examining its frame structure, its medium access +protocol, and its internetworking of 802.11 LANs with wired Ethernet +LANs. There are several 802.11 standards for wireless LAN technology in +the IEEE 802.11 ("WiFi") family, as summarized in Table 7.1. The +different 802.11 standards all share some common characteristics. They +all use the same medium access protocol, CSMA/CA, which we'll discuss +shortly. All three use the same frame structure for their link-layer +frames as well. All three standards have the ability to reduce their +transmission rate in order to reach out over greater distances. And, +importantly, 802.11 products are also all backwards compatible, meaning, +for example, that a mobile capable only of 802.11g may still interact +with a newer 802.11ac base station. However, as shown in Table 7.1, the +standards have some major differences at the physical layer. 802.11 +devices operate in two difference frequency ranges: 2.4--2.485 GHz +(referred to as the 2.4 GHz range) and 5.1 -- 5.8 GHz (referred to as +the 5 GHz range). The 2.4 GHz range is an unlicensed frequency band, +where 802.11 devices may compete for frequency spectrum with 2.4 GHz +phones and microwave ovens. At 5 GHz, 802.11 LANs have a shorter +transmission distance for a given power level and suffer more from +multipath propagation. The two most recent standards, 802.11n \[IEEE +802.11n 2012\] and 802.11ac \[IEEE 802.11ac 2013; Cisco 802.11ac 2015\] +uses multiple input multiple-output (MIMO) antennas; i.e., two or more +antennas on the sending side and two or more antennas on the receiving +side that are transmitting/receiving different signals \[Diggavi 2004\]. +802.11ac base Table 7.1 Summary of IEEE 802.11 standards Standard + +Frequency Range + +Data Rate + +802.11b + +2.4 GHz + +up to 11 Mbps + +802.11a + +5 GHz + +up to 54 Mbps + +802.11g + +2.4 GHz + +up to 54 Mbps + + 802.11n + +2.5 GHz and 5 GHz + +up to 450 Mbps + +802.11ac + +5 GHz + +up to 1300 Mbps + +stations may transmit to multiple stations simultaneously, and use +"smart" antennas to adaptively beamform to target transmissions in the +direction of a receiver. This decreases interference and increases the +distance reached at a given data rate. The data rates shown in Table 7.1 +are for an idealized environment, e.g., a receiver placed 1 meter away +from the base station, with no interference ---a scenario that we're +unlikely to experience in practice! So as the saying goes, YMMV: Your +Mileage (or in this case your wireless data rate) May Vary. + +7.3.1 The 802.11 Architecture Figure 7.7 illustrates the principal +components of the 802.11 wireless LAN architecture. The fundamental +building block of the 802.11 architecture is the basic service set +(BSS). A BSS contains one or more wireless stations and a central base +station, known as an access point (AP) in 802.11 parlance. Figure 7.7 +shows the AP in each of two BSSs connecting to an interconnection device +(such as a switch or router), which in turn leads to the Internet. In a +typical home network, there is one AP and one router (typically +integrated together as one unit) that connects the BSS to the Internet. +As with Ethernet devices, each 802.11 wireless station has a 6-byte MAC +address that is stored in the firmware of the station's adapter (that +is, 802.11 network interface card). Each AP also has a MAC address for +its wireless interface. As with Ethernet, these MAC addresses are +administered by IEEE and are (in theory) globally unique. + + Figure 7.7 IEEE 802.11 LAN architecture + +Figure 7.8 An IEEE 802.11 ad hoc network + +As noted in Section 7.1, wireless LANs that deploy APs are often +referred to as infrastructure wireless LANs, with the "infrastructure" +being the APs along with the wired Ethernet infrastructure that +interconnects the APs and a router. Figure 7.8 shows that IEEE 802.11 +stations can also group themselves together to form an ad hoc +network---a network with no central control and with no connections to +the "outside world." Here, the network is formed "on the fly," by mobile +devices that have found themselves in proximity to each other, that have +a need to communicate, and that find no preexisting network +infrastructure in their location. An ad hoc network might be formed when +people with + + laptops get together (for example, in a conference room, a train, or a +car) and want to exchange data in the absence of a centralized AP. There +has been tremendous interest in ad hoc networking, as communicating +portable devices continue to proliferate. In this section, though, we'll +focus our attention on infrastructure wireless LANs. Channels and +Association In 802.11, each wireless station needs to associate with an +AP before it can send or receive networklayer data. Although all of the +802.11 standards use association, we'll discuss this topic specifically +in the context of IEEE 802.11b/g. When a network administrator installs +an AP, the administrator assigns a one- or two-word Service Set +Identifier (SSID) to the access point. (When you choose Wi-Fi under +Setting on your iPhone, for example, a list is displayed showing the +SSID of each AP in range.) The administrator must also assign a channel +number to the AP. To understand channel numbers, recall that 802.11 +operates in the frequency range of 2.4 GHz to 2.4835 GHz. Within this 85 +MHz band, 802.11 defines 11 partially overlapping channels. Any two +channels are non-overlapping if and only if they are separated by four +or more channels. In particular, the set of channels 1, 6, and 11 is the +only set of three non-overlapping channels. This means that an +administrator could create a wireless LAN with an aggregate maximum +transmission rate of 33 Mbps by installing three 802.11b APs at the same +physical location, assigning channels 1, 6, and 11 to the APs, and +interconnecting each of the APs with a switch. Now that we have a basic +understanding of 802.11 channels, let's describe an interesting (and not +completely uncommon) situation---that of a WiFi jungle. A WiFi jungle is +any physical location where a wireless station receives a sufficiently +strong signal from two or more APs. For example, in many cafés in New +York City, a wireless station can pick up a signal from numerous nearby +APs. One of the APs might be managed by the café, while the other APs +might be in residential apartments near the café. Each of these APs +would likely be located in a different IP subnet and would have been +independently assigned a channel. Now suppose you enter such a WiFi +jungle with your phone, tablet, or laptop, seeking wireless Internet +access and a blueberry muffin. Suppose there are five APs in the WiFi +jungle. To gain Internet access, your wireless device needs to join +exactly one of the subnets and hence needs to associate with exactly one +of the APs. Associating means the wireless device creates a virtual wire +between itself and the AP. Specifically, only the associated AP will +send data frames (that is, frames containing data, such as a datagram) +to your wireless device, and your wireless device will send data frames +into the Internet only through the associated AP. But how does your +wireless device associate with a particular AP? And more fundamentally, +how does your wireless device know which APs, if any, are out there in +the jungle? The 802.11 standard requires that an AP periodically send +beacon frames, each of which includes the + + AP's SSID and MAC address. Your wireless device, knowing that APs are +sending out beacon frames, scans the 11 channels, seeking beacon frames +from any APs that may be out there (some of which may be transmitting on +the same channel---it's a jungle out there!). Having learned about +available APs from the beacon frames, you (or your wireless device) +select one of the APs for association. The 802.11 standard does not +specify an algorithm for selecting which of the available APs to +associate with; that algorithm is left up to the designers of the 802.11 +firmware and software in your wireless device. Typically, the device +chooses the AP whose beacon frame is received with the highest signal +strength. While a high signal strength is good (see, e.g., Figure 7.3), +signal strength is not the only AP characteristic that will determine +the performance a device receives. In particular, it's possible that the +selected AP may have a strong signal, but may be overloaded with other +affiliated devices (that will need to share the wireless bandwidth at +that AP), while an unloaded AP is not selected due to a slightly weaker +signal. A number of alternative ways of choosing APs have thus recently +been proposed \[Vasudevan 2005; Nicholson 2006; Sundaresan 2006\]. For +an interesting and down-to-earth discussion of how signal strength is +measured, see \[Bardwell 2004\]. + +Figure 7.9 Active and passive scanning for access points + +The process of scanning channels and listening for beacon frames is +known as passive scanning (see Figure 7.9a). A wireless device can also +perform active scanning, by broadcasting a probe frame that will be +received by all APs within the wireless device's range, as shown in +Figure 7.9b. APs respond to the probe request frame with a probe +response frame. The wireless device can then choose the AP with which to +associate from among the responding APs. + + After selecting the AP with which to associate, the wireless device +sends an association request frame to the AP, and the AP responds with +an association response frame. Note that this second request/response +handshake is needed with active scanning, since an AP responding to the +initial probe request frame doesn't know which of the (possibly many) +responding APs the device will choose to associate with, in much the +same way that a DHCP client can choose from among multiple DHCP servers +(see Figure 4.21). Once associated with an AP, the device will want to +join the subnet (in the IP addressing sense of Section 4.3.3) to which +the AP belongs. Thus, the device will typically send a DHCP discovery +message (see Figure 4.21) into the subnet via the AP in order to obtain +an IP address on the subnet. Once the address is obtained, the rest of +the world then views that device simply as another host with an IP +address in that subnet. In order to create an association with a +particular AP, the wireless device may be required to authenticate +itself to the AP. 802.11 wireless LANs provide a number of alternatives +for authentication and access. One approach, used by many companies, is +to permit access to a wireless network based on a device's MAC address. +A second approach, used by many Internet cafés, employs usernames and +passwords. In both cases, the AP typically communicates with an +authentication server, relaying information between the wireless device +and the authentication server using a protocol such as RADIUS \[RFC +2865\] or DIAMETER \[RFC 3588\]. Separating the authentication server +from the AP allows one authentication server to serve many APs, +centralizing the (often sensitive) decisions of authentication and +access within the single server, and keeping AP costs and complexity +low. We'll see in Chapter 8 that the new IEEE 802.11i protocol defining +security aspects of the 802.11 protocol family takes precisely this +approach. + +7.3.2 The 802.11 MAC Protocol Once a wireless device is associated with +an AP, it can start sending and receiving data frames to and from the +access point. But because multiple wireless devices, or the AP itself +may want to transmit data frames at the same time over the same channel, +a multiple access protocol is needed to coordinate the transmissions. In +the following, we'll refer to the devices or the AP as wireless +"stations" that share the multiple access channel. As discussed in +Chapter 6 and Section 7.2.1, broadly speaking there are three classes of +multiple access protocols: channel partitioning (including CDMA), random +access, and taking turns. Inspired by the huge success of Ethernet and +its random access protocol, the designers of 802.11 chose a random +access protocol for 802.11 wireless LANs. This random access protocol is +referred to as CSMA with collision avoidance, or more succinctly as +CSMA/CA. As with Ethernet's CSMA/CD, the "CSMA" in CSMA/CA stands for +"carrier sense multiple access," meaning that each station senses the +channel before transmitting, and refrains from transmitting when the +channel is sensed busy. Although both Ethernet and 802.11 use +carrier-sensing random access, the two MAC protocols have important +differences. First, instead of using collision detection, 802.11 uses +collisionavoidance techniques. Second, because of the relatively high +bit error rates of wireless channels, + + 802.11 (unlike Ethernet) uses a link-layer acknowledgment/retransmission +(ARQ) scheme. We'll describe 802.11's collision-avoidance and link-layer +acknowledgment schemes below. Recall from Sections 6.3.2 and 6.4.2 that +with Ethernet's collision-detection algorithm, an Ethernet station +listens to the channel as it transmits. If, while transmitting, it +detects that another station is also transmitting, it aborts its +transmission and tries to transmit again after waiting a small, random +amount of time. Unlike the 802.3 Ethernet protocol, the 802.11 MAC +protocol does not implement collision detection. There are two important +reasons for this: The ability to detect collisions requires the ability +to send (the station's own signal) and receive (to determine whether +another station is also transmitting) at the same time. Because the +strength of the received signal is typically very small compared to the +strength of the transmitted signal at the 802.11 adapter, it is costly +to build hardware that can detect a collision. More importantly, even if +the adapter could transmit and listen at the same time (and presumably +abort transmission when it senses a busy channel), the adapter would +still not be able to detect all collisions, due to the hidden terminal +problem and fading, as discussed in Section 7.2. Because 802.11wireless +LANs do not use collision detection, once a station begins to transmit a +frame, it transmits the frame in its entirety; that is, once a station +gets started, there is no turning back. As one might expect, +transmitting entire frames (particularly long frames) when collisions +are prevalent can significantly degrade a multiple access protocol's +performance. In order to reduce the likelihood of collisions, 802.11 +employs several collision-avoidance techniques, which we'll shortly +discuss. Before considering collision avoidance, however, we'll first +need to examine 802.11's link-layer acknowledgment scheme. Recall from +Section 7.2 that when a station in a wireless LAN sends a frame, the +frame may not reach the destination station intact for a variety of +reasons. To deal with this non-negligible chance of failure, the 802.11 +MAC protocol uses link-layer acknowledgments. As shown in Figure 7.10, +when the destination station receives a frame that passes the CRC, it +waits a short period of time known as the Short Inter-frame Spacing +(SIFS) and then sends back + + Figure 7.10 802.11 uses link-layer acknowledgments + +an acknowledgment frame. If the transmitting station does not receive an +acknowledgment within a given amount of time, it assumes that an error +has occurred and retransmits the frame, using the CSMA/CA protocol to +access the channel. If an acknowledgment is not received after some +fixed number of retransmissions, the transmitting station gives up and +discards the frame. Having discussed how 802.11 uses link-layer +acknowledgments, we're now in a position to describe the 802.11 CSMA/CA +protocol. Suppose that a station (wireless device or an AP) has a frame +to transmit. + +1. If initially the station senses the channel idle, it transmits its + frame after a short period of time known as the Distributed + Inter-frame Space (DIFS); see Figure 7.10. + +2. Otherwise, the station chooses a random backoff value using binary + exponential backoff (as we encountered in Section 6.3.2) and counts + down this value after DIFS when the channel is sensed idle. While + the channel is sensed busy, the counter value remains frozen. + +3. When the counter reaches zero (note that this can only occur while + the channel is sensed idle), the station transmits the entire frame + and then waits for an acknowledgment. + +4. If an acknowledgment is received, the transmitting station knows + that its frame has been correctly received at the destination + station. If the station has another frame to send, it begins + + the CSMA/CA protocol at step 2. If the acknowledgment isn't received, +the transmitting station reenters the backoff phase in step 2, with the +random value chosen from a larger interval. Recall that under Ethernet's +CSMA/CD, multiple access protocol (Section 6.3.2), a station begins +transmitting as soon as the channel is sensed idle. With CSMA/CA, +however, the station refrains from transmitting while counting down, +even when it senses the channel to be idle. Why do CSMA/CD and CDMA/CA +take such different approaches here? To answer this question, let's +consider a scenario in which two stations each have a data frame to +transmit, but neither station transmits immediately because each senses +that a third station is already transmitting. With Ethernet's CSMA/CD, +the two stations would each transmit as soon as they detect that the +third station has finished transmitting. This would cause a collision, +which isn't a serious issue in CSMA/CD, since both stations would abort +their transmissions and thus avoid the useless transmissions of the +remainders of their frames. In 802.11, however, the situation is quite +different. Because 802.11 does not detect a collision and abort +transmission, a frame suffering a collision will be transmitted in its +entirety. The goal in 802.11 is thus to avoid collisions whenever +possible. In 802.11, if the two stations sense the channel busy, they +both immediately enter random backoff, hopefully choosing different +backoff values. If these values are indeed different, once the channel +becomes idle, one of the two stations will begin transmitting before the +other, and (if the two stations are not hidden from each other) the +"losing station" will hear the "winning station's" signal, freeze its +counter, and refrain from transmitting until the winning station has +completed its transmission. In this manner, a costly collision is +avoided. Of course, collisions can still occur with 802.11 in this +scenario: The two stations could be hidden from each other, or the two +stations could choose random backoff values that are close enough that +the transmission from the station starting first have yet to reach the +second station. Recall that we encountered this problem earlier in our +discussion of random access algorithms in the context of Figure 6.12. +Dealing with Hidden Terminals: RTS and CTS The 802.11 MAC protocol also +includes a nifty (but optional) reservation scheme that helps avoid +collisions even in the presence of hidden terminals. Let's investigate +this scheme in the context of Figure 7.11, which shows two wireless +stations and one access point. Both of the wireless stations are within +range of the AP (whose coverage is shown as a shaded circle) and both +have associated with the AP. However, due to fading, the signal ranges +of wireless stations are limited to the interiors of the shaded circles +shown in Figure 7.11. Thus, each of the wireless stations is hidden from +the other, although neither is hidden from the AP. Let's now consider +why hidden terminals can be problematic. Suppose Station H1 is +transmitting a frame and halfway through H1's transmission, Station H2 +wants to send a frame to the AP. H2, not hearing the transmission from +H1, will first wait a DIFS interval and then transmit the frame, +resulting in + + a collision. The channel will therefore be wasted during the entire +period of H1's transmission as well as during H2's transmission. In +order to avoid this problem, the IEEE 802.11 protocol allows a station +to use a short Request to Send (RTS) control frame and a short Clear to +Send (CTS) control frame to reserve access to the channel. When a sender +wants to send a DATA + +Figure 7.11 Hidden terminal example: H1 is hidden from H2, and vice +versa + +frame, it can first send an RTS frame to the AP, indicating the total +time required to transmit the DATA frame and the acknowledgment (ACK) +frame. When the AP receives the RTS frame, it responds by broadcasting a +CTS frame. This CTS frame serves two purposes: It gives the sender +explicit permission to send and also instructs the other stations not to +send for the reserved duration. Thus, in Figure 7.12, before +transmitting a DATA frame, H1 first broadcasts an RTS frame, which is +heard by all stations in its circle, including the AP. The AP then +responds + + Figure 7.12 Collision avoidance using the RTS and CTS frames + +with a CTS frame, which is heard by all stations within its range, +including H1 and H2. Station H2, having heard the CTS, refrains from +transmitting for the time specified in the CTS frame. The RTS, CTS, +DATA, and ACK frames are shown in Figure 7.12. The use of the RTS and +CTS frames can improve performance in two important ways: The hidden +station problem is mitigated, since a long DATA frame is transmitted +only after the channel has been reserved. Because the RTS and CTS frames +are short, a collision involving an RTS or CTS frame will last only + + for the duration of the short RTS or CTS frame. Once the RTS and CTS +frames are correctly transmitted, the following DATA and ACK frames +should be transmitted without collisions. You are encouraged to check +out the 802.11 applet in the textbook's Web site. This interactive +applet illustrates the CSMA/CA protocol, including the RTS/CTS exchange +sequence. Although the RTS/CTS exchange can help reduce collisions, it +also introduces delay and consumes channel resources. For this reason, +the RTS/CTS exchange is only used (if at all) to reserve the channel for +the transmission of a long DATA frame. In practice, each wireless +station can set an RTS threshold such that the RTS/CTS sequence is used +only when the frame is longer than the threshold. For many wireless +stations, the default RTS threshold value is larger than the maximum +frame length, so the RTS/CTS sequence is skipped for all DATA frames +sent. Using 802.11 as a Point-to-Point Link Our discussion so far has +focused on the use of 802.11 in a multiple access setting. We should +mention that if two nodes each have a directional antenna, they can +point their directional antennas at each other and run the 802.11 +protocol over what is essentially a point-to-point link. Given the low +cost of commodity 802.11 hardware, the use of directional antennas and +an increased transmission power allow 802.11 to be used as an +inexpensive means of providing wireless point-to-point connections over +tens of kilometers distance. \[Raman 2007\] describes one of the first +such multi-hop wireless networks, operating in the rural Ganges plains +in India using point-to-point 802.11 links. + +7.3.3 The IEEE 802.11 Frame Although the 802.11 frame shares many +similarities with an Ethernet frame, it also contains a number of fields +that are specific to its use for wireless links. The 802.11 frame is +shown in Figure 7.13. The numbers above each of the fields in the frame +represent the lengths of the fields in bytes; the numbers above each of +the subfields in the frame control field represent the lengths of the +subfields in bits. Let's now examine the fields in the frame as well as +some of the more important subfields in the frame's control field. + + Figure 7.13 The 802.11 frame + +Payload and CRC Fields At the heart of the frame is the payload, which +typically consists of an IP datagram or an ARP packet. Although the +field is permitted to be as long as 2,312 bytes, it is typically fewer +than 1,500 bytes, holding an IP datagram or an ARP packet. As with an +Ethernet frame, an 802.11 frame includes a 32-bit cyclic redundancy +check (CRC) so that the receiver can detect bit errors in the received +frame. As we've seen, bit errors are much more common in wireless LANs +than in wired LANs, so the CRC is even more useful here. Address Fields +Perhaps the most striking difference in the 802.11 frame is that it has +four address fields, each of which can hold a 6-byte MAC address. But +why four address fields? Doesn't a source MAC field and destination MAC +field suffice, as they do for Ethernet? It turns out that three address +fields are needed for internetworking purposes---specifically, for +moving the network-layer datagram from a wireless station through an AP +to a router interface. The fourth address field is used when APs forward +frames to each other in ad hoc mode. Since we are only considering +infrastructure networks here, let's focus our attention on the first +three address fields. The 802.11 standard defines these fields as +follows: Address 2 is the MAC address of the station that transmits the +frame. Thus, if a wireless station transmits the frame, that station's +MAC address is inserted in the address 2 field. Similarly, if an AP +transmits the frame, the AP's MAC address is inserted in the address 2 +field. Address 1 is the MAC address of the wireless station that is to +receive the frame. Thus if a mobile wireless station transmits the +frame, address 1 contains the MAC address of the destination AP. +Similarly, if an AP transmits the frame, address 1 contains the MAC +address of the destination wireless station. + + Figure 7.14 The use of address fields in 802.11 frames: Sending frames +between H1 and R1 + +To understand address 3, recall that the BSS (consisting of the AP and +wireless stations) is part of a subnet, and that this subnet connects to +other subnets via some router interface. Address 3 contains the MAC +address of this router interface. To gain further insight into the +purpose of address 3, let's walk through an internetworking example in +the context of Figure 7.14. In this figure, there are two APs, each of +which is responsible for a number of wireless stations. Each of the APs +has a direct connection to a router, which in turn connects to the +global Internet. We should keep in mind that an AP is a link-layer +device, and thus neither "speaks" IP nor understands IP addresses. +Consider now moving a datagram from the router interface R1 to the +wireless Station H1. The router is not aware that there is an AP between +it and H1; from the router's perspective, H1 is just a host in one of +the subnets to which it (the router) is connected. The router, which +knows the IP address of H1 (from the destination address of the +datagram), uses ARP to determine the MAC address of H1, just as in an +ordinary Ethernet LAN. After obtaining H1's MAC address, router +interface R1 encapsulates the datagram within an Ethernet frame. The +source address field of this frame contains R1's MAC address, and the +destination address field contains H1's MAC address. When the Ethernet +frame arrives at the AP, the AP converts the 802.3 Ethernet frame to an +802.11 frame before transmitting the frame into the wireless channel. +The AP fills in address 1 and address 2 with H1's MAC address and its +own MAC address, respectively, as described above. For address 3, the AP +inserts the MAC address of R1. In this manner, H1 can determine (from +address 3) the MAC address of the router interface that sent the +datagram into the subnet. + + Now consider what happens when the wireless station H1 responds by +moving a datagram from H1 to R1. H1 creates an 802.11 frame, filling the +fields for address 1 and address 2 with the AP's MAC address and H1's +MAC address, respectively, as described above. For address 3, H1 inserts +R1's MAC address. When the AP receives the 802.11 frame, it converts the +frame to an Ethernet frame. The source address field for this frame is +H1's MAC address, and the destination address field is R1's MAC address. +Thus, address 3 allows the AP to determine the appropriate destination +MAC address when constructing the Ethernet frame. In summary, address 3 +plays a crucial role for internetworking the BSS with a wired LAN. +Sequence Number, Duration, and Frame Control Fields Recall that in +802.11, whenever a station correctly receives a frame from another +station, it sends back an acknowledgment. Because acknowledgments can +get lost, the sending station may send multiple copies of a given frame. +As we saw in our discussion of the rdt2.1 protocol (Section 3.4.1), the +use of sequence numbers allows the receiver to distinguish between a +newly transmitted frame and the retransmission of a previous frame. The +sequence number field in the 802.11 frame thus serves exactly the same +purpose here at the link layer as it did in the transport layer in +Chapter 3. Recall that the 802.11 protocol allows a transmitting station +to reserve the channel for a period of time that includes the time to +transmit its data frame and the time to transmit an acknowledgment. This +duration value is included in the frame's duration field (both for data +frames and for the RTS and CTS frames). As shown in Figure 7.13, the +frame control field includes many subfields. We'll say just a few words +about some of the more important subfields; for a more complete +discussion, you are encouraged to consult the 802.11 specification +\[Held 2001; Crow 1997; IEEE 802.11 1999\]. The type and subtype fields +are used to distinguish the association, RTS, CTS, ACK, and data frames. +The to and from fields are used to define the meanings of the different +address fields. (These meanings change depending on whether ad hoc or +infrastructure modes are used and, in the case of infrastructure mode, +whether a wireless station or an AP is sending the frame.) Finally the +WEP field indicates whether encryption is being used or not (WEP is +discussed in Chapter 8). + +7.3.4 Mobility in the Same IP Subnet + + In order to increase the physical range of a wireless LAN, companies and +universities will often deploy multiple BSSs within the same IP subnet. +This naturally raises the issue of mobility among the BSSs--- how do +wireless stations seamlessly move from one BSS to another while +maintaining ongoing TCP sessions? As we'll see in this subsection, +mobility can be handled in a relatively straightforward manner when the +BSSs are part of the subnet. When stations move between subnets, more +sophisticated mobility management protocols will be needed, such as +those we'll study in Sections 7.5 and 7.6. Let's now look at a specific +example of mobility between BSSs in the same subnet. Figure 7.15 shows +two interconnected BSSs with a host, H1, moving from BSS1 to BSS2. +Because in this example the interconnection device that connects the two +BSSs is not a router, all of the stations in the two BSSs, including the +APs, belong to the same IP subnet. Thus, when H1 moves from BSS1 to +BSS2, it may keep its IP address and all of its ongoing TCP connections. +If the interconnection device were a router, then H1 would have to +obtain a new IP address in the subnet in which it was moving. This +address change would disrupt (and eventually terminate) any on-going TCP +connections at H1. In Section 7.6, we'll see how a network-layer +mobility protocol, such as mobile IP, can be used to avoid this problem. +But what specifically happens when H1 moves from BSS1 to BSS2? As H1 +wanders away from AP1, H1 detects a weakening signal from AP1 and starts +to scan for a stronger signal. H1 receives beacon frames from AP2 (which +in many corporate and university settings will have the same SSID as +AP1). H1 then disassociates with AP1 and associates with AP2, while +keeping its IP address and maintaining its ongoing TCP sessions. This +addresses the handoff problem from the host and AP viewpoint. But what +about the switch in Figure 7.15? How does it know that the host has +moved from one AP to another? As you may recall from Chapter 6, switches +are "self-learning" and automatically build their forwarding tables. +This selflearning feature nicely handles + +Figure 7.15 Mobility in the same subnet + + occasional moves (for example, when an employee gets transferred from +one department to another); however, switches were not designed to +support highly mobile users who want to maintain TCP connections while +moving between BSSs. To appreciate the problem here, recall that before +the move, the switch has an entry in its forwarding table that pairs +H1's MAC address with the outgoing switch interface through which H1 can +be reached. If H1 is initially in BSS1, then a datagram destined to H1 +will be directed to H1 via AP1. Once H1 associates with BSS2, however, +its frames should be directed to AP2. One solution (a bit of a hack, +really) is for AP2 to send a broadcast Ethernet frame with H1's source +address to the switch just after the new association. When the switch +receives the frame, it updates its forwarding table, allowing H1 to be +reached via AP2. The 802.11f standards group is developing an inter-AP +protocol to handle these and related issues. Our discussion above has +focused on mobility with the same LAN subnet. Recall that VLANs, which +we studied in Section 6.4.4, can be used to connect together islands of +LANs into a large virtual LAN that can span a large geographical region. +Mobility among base stations within such a VLAN can be handled in +exactly the same manner as above \[Yu 2011\]. + +7.3.5 Advanced Features in 802.11 We'll wrap up our coverage of 802.11 +with a short discussion of two advanced capabilities found in 802.11 +networks. As we'll see, these capabilities are not completely specified +in the 802.11 standard, but rather are made possible by mechanisms +specified in the standard. This allows different vendors to implement +these capabilities using their own (proprietary) approaches, presumably +giving them an edge over the competition. 802.11 Rate Adaptation We saw +earlier in Figure 7.3 that different modulation techniques (with the +different transmission rates that they provide) are appropriate for +different SNR scenarios. Consider for example a mobile 802.11 user who +is initially 20 meters away from the base station, with a high +signal-to-noise ratio. Given the high SNR, the user can communicate with +the base station using a physical-layer modulation technique that +provides high transmission rates while maintaining a low BER. This is +one happy user! Suppose now that the user becomes mobile, walking away +from the base station, with the SNR falling as the distance from the +base station increases. In this case, if the modulation technique used +in the 802.11 protocol operating between the base station and the user +does not change, the BER will become unacceptably high as the SNR +decreases, and eventually no transmitted frames will be received +correctly. For this reason, some 802.11 implementations have a rate +adaptation capability that adaptively selects the underlying +physical-layer modulation technique to use based on current or recent +channel + + characteristics. If a node sends two frames in a row without receiving +an acknowledgment (an implicit indication of bit errors on the channel), +the transmission rate falls back to the next lower rate. If 10 frames in +a row are acknowledged, or if a timer that tracks the time since the +last fallback expires, the transmission rate increases to the next +higher rate. This rate adaptation mechanism shares the same "probing" +philosophy as TCP's congestion-control mechanism---when conditions are +good (reflected by ACK receipts), the transmission rate is increased +until something "bad" happens (the lack of ACK receipts); when something +"bad" happens, the transmission rate is reduced. 802.11 rate adaptation +and TCP congestion control are thus similar to the young child who is +constantly pushing his/her parents for more and more (say candy for a +young child, later curfew hours for the teenager) until the parents +finally say "Enough!" and the child backs off (only to try again later +after conditions have hopefully improved!). A number of other schemes +have also been proposed to improve on this basic automatic +rateadjustment scheme \[Kamerman 1997; Holland 2001; Lacage 2004\]. +Power Management Power is a precious resource in mobile devices, and +thus the 802.11 standard provides powermanagement capabilities that +allow 802.11 nodes to minimize the amount of time that their sense, +transmit, and receive functions and other circuitry need to be "on." +802.11 power management operates as follows. A node is able to +explicitly alternate between sleep and wake states (not unlike a sleepy +student in a classroom!). A node indicates to the access point that it +will be going to sleep by setting the power-management bit in the header +of an 802.11 frame to 1. A timer in the node is then set to wake up the +node just before the AP is scheduled to send its beacon frame (recall +that an AP typically sends a beacon frame every 100 msec). Since the AP +knows from the set power-transmission bit that the node is going to +sleep, it (the AP) knows that it should not send any frames to that +node, and will buffer any frames destined for the sleeping host for +later transmission. A node will wake up just before the AP sends a +beacon frame, and quickly enter the fully active state (unlike the +sleepy student, this wakeup requires only 250 microseconds \[Kamerman +1997\]!). The beacon frames sent out by the AP contain a list of nodes +whose frames have been buffered at the AP. If there are no buffered +frames for the node, it can go back to sleep. Otherwise, the node can +explicitly request that the buffered frames be sent by sending a polling +message to the AP. With an inter-beacon time of 100 msec, a wakeup time +of 250 microseconds, and a similarly small time to receive a beacon +frame and check to ensure that there are no buffered frames, a node that +has no frames to send or receive can be asleep 99% of the time, +resulting in a significant energy savings. + +7.3.6 Personal Area Networks: Bluetooth and Zigbee As illustrated in +Figure 7.2, the IEEE 802.11 WiFi standard is aimed at communication +among devices separated by up to 100 meters (except when 802.11 is used +in a point-to-point configuration with a + + directional antenna). Two other wireless protocols in the IEEE 802 +family are Bluetooth and Zigbee (defined in the IEEE 802.15.1 and IEEE +802.15.4 standards \[IEEE 802.15 2012\]). Bluetooth An IEEE 802.15.1 +network operates over a short range, at low power, and at low cost. It +is essentially a low-power, short-range, low-rate "cable replacement" +technology for interconnecting a computer with its wireless keyboard, +mouse or other peripheral device; cellular phones, speakers, headphones, +and many other devices, whereas 802.11 is a higher-power, medium-range, +higher-rate "access" technology. For this reason, 802.15.1 networks are +sometimes referred to as wireless personal area networks (WPANs). The +link and physical layers of 802.15.1 are based on the earlier Bluetooth +specification for personal area networks \[Held 2001, Bisdikian 2001\]. +802.15.1 networks operate in the 2.4 GHz unlicensed radio band in a TDM +manner, with time slots of 625 microseconds. During each time slot, a +sender transmits on one of 79 channels, with the channel changing in a +known but pseudo-random manner from slot to slot. This form of channel +hopping, known as frequency-hopping spread spectrum (FHSS), spreads +transmissions in time over the frequency spectrum. 802.15.1 can provide +data rates up to 4 Mbps. 802.15.1 networks are ad hoc networks: No +network infrastructure (e.g., an access point) is needed to interconnect +802.15.1 devices. Thus, 802.15.1 devices must organize themselves. +802.15.1 devices are first organized into a piconet of up to eight +active devices, as shown in Figure 7.16. One of these devices is +designated as the master, with the remaining devices acting as slaves. +The master node truly rules the piconet---its clock determines time in +the piconet, it can transmit in each odd-numbered slot, and a + +Figure 7.16 A Bluetooth piconet + + slave can transmit only after the master has communicated with it in the +previous slot and even then the slave can only transmit to the master. +In addition to the slave devices, there can also be up to 255 parked +devices in the network. These devices cannot communicate until their +status has been changed from parked to active by the master node. For +more information about WPANs, the interested reader should consult the +Bluetooth references \[Held 2001, Bisdikian 2001\] or the official IEEE +802.15 Web site \[IEEE 802.15 2012\]. Zigbee A second personal area +network standardized by the IEEE is the 802.15.4 standard \[IEEE 802.15 +2012\] known as Zigbee. While Bluetooth networks provide a "cable +replacement" data rate of over a Megabit per second, Zigbee is targeted +at lower-powered, lower-data-rate, lower-duty-cycle applications than +Bluetooth. While we may tend to think that "bigger and faster is +better," not all network applications need high bandwidth and the +consequent higher costs (both economic and power costs). For example, +home temperature and light sensors, security devices, and wall-mounted +switches are all very simple, lowpower, low-duty-cycle, low-cost +devices. Zigbee is thus well-suited for these devices. Zigbee defines +channel rates of 20, 40, 100, and 250 Kbps, depending on the channel +frequency. Nodes in a Zigbee network come in two flavors. So-called +"reduced-function devices" operate as slave devices under the control of +a single "full-function device," much as Bluetooth slave devices. A +fullfunction device can operate as a master device as in Bluetooth by +controlling multiple slave devices, and multiple full-function devices +can additionally be configured into a mesh network in which fullfunction +devices route frames amongst themselves. Zigbee shares many protocol +mechanisms that we've already encountered in other link-layer protocols: +beacon frames and link-layer acknowledgments (similar to 802.11), +carrier-sense random access protocols with binary exponential backoff +(similar to 802.11 and Ethernet), and fixed, guaranteed allocation of +time slots (similar to DOCSIS). Zigbee networks can be configured in +many different ways. Let's consider the simple case of a single +full-function device controlling multiple reduced-function devices in a +time-slotted manner using beacon frames. Figure 7.17 shows the case + + Figure 7.17 Zigbee 802.15.4 super-frame structure + +where the Zigbee network divides time into recurring super frames, each +of which begins with a beacon frame. Each beacon frame divides the super +frame into an active period (during which devices may transmit) and an +inactive period (during which all devices, including the controller, can +sleep and thus conserve power). The active period consists of 16 time +slots, some of which are used by devices in a CSMA/CA random access +manner, and some of which are allocated by the controller to specific +devices, thus providing guaranteed channel access for those devices. +More details about Zigbee networks can be found at \[Baronti 2007, IEEE +802.15.4 2012\]. + + 7.4 Cellular Internet Access In the previous section we examined how an +Internet host can access the Internet when inside a WiFi hotspot---that +is, when it is within the vicinity of an 802.11 access point. But most +WiFi hotspots have a small coverage area of between 10 and 100 meters in +diameter. What do we do then when we have a desperate need for wireless +Internet access and we cannot access a WiFi hotspot? Given that cellular +telephony is now ubiquitous in many areas throughout the world, a +natural strategy is to extend cellular networks so that they support not +only voice telephony but wireless Internet access as well. Ideally, this +Internet access would be at a reasonably high speed and would provide +for seamless mobility, allowing users to maintain their TCP sessions +while traveling, for example, on a bus or a train. With sufficiently +high upstream and downstream bit rates, the user could even maintain +videoconferencing sessions while roaming about. This scenario is not +that far-fetched. Data rates of several megabits per second are becoming +available as broadband data services such as those we will cover here +become more widely deployed. In this section, we provide a brief +overview of current and emerging cellular Internet access technologies. +Our focus here will be on both the wireless first hop as well as the +network that connects the wireless first hop into the larger telephone +network and/or the Internet; in Section 7.7 we'll consider how calls are +routed to a user moving between base stations. Our brief discussion will +necessarily provide only a simplified and high-level description of +cellular technologies. Modern cellular communications, of course, has +great breadth and depth, with many universities offering several courses +on the topic. Readers seeking a deeper understanding are encouraged to +see \[Goodman 1997; Kaaranen 2001; Lin 2001; Korhonen 2003; Schiller +2003; Palat 2009; Scourias 2012; Turner 2012; Akyildiz 2010\], as well +as the particularly excellent and exhaustive references \[Mouly 1992; +Sauter 2014\]. + +7.4.1 An Overview of Cellular Network Architecture In our description of +cellular network architecture in this section, we'll adopt the +terminology of the Global System for Mobile Communications (GSM) +standards. (For history buffs, the GSM acronym was originally derived +from Groupe Spécial Mobile, until the more anglicized name was adopted, +preserving the original acronym letters.) In the 1980s, Europeans +recognized the need for a pan-European digital cellular telephony system +that would replace the numerous incompatible analog cellular telephony +systems, leading to the GSM standard \[Mouly 1992\]. Europeans deployed +GSM technology with great + + success in the early 1990s, and since then GSM has grown to be the +800-pound gorilla of the cellular telephone world, with more than 80% of +all cellular subscribers worldwide using GSM. + +CASE HISTORY 4G Cellular Mobile Versus Wireless LANs Many cellular +mobile phone operators are deploying 4G cellular mobile systems. In some +countries (e.g., Korea and Japan), 4G LTE coverage is higher than +90%---nearly ubiquitous. In 2015, average download rates over deployed +LTE systems range from 10Mbps in the US and India to close to 40 Mbps in +New Zealand. These 4G systems are being deployed in licensed +radio-frequency bands, with some operators paying considerable sums to +governments for spectrum-use licenses. 4G systems allow users to access +the Internet from remote outdoor locations while on the move, in a +manner similar to today's cellular phone-only access. In many cases, a +user may have simultaneous access to both wireless LANs and 4G. With the +capacity of 4G systems being both more constrained and more expensive, +many mobile devices default to the use of WiFi rather than 4G, when both +are avilable. The question of whether wireless edge network access will +be primarily over wireless LANs or cellular systems remains an open +question: The emerging wireless LAN infrastructure may become nearly +ubiquitous. IEEE 802.11 wireless LANs, operating at 54 Mbps and higher, +are enjoying widespread deployment. Essentially all laptops, tablets and +smartphones are factory-equipped with 802.11 LAN capabilities. +Furthermore, emerging Internet appliances---such as wireless cameras and +picture frames---also have low-powered wireless LAN capabilities. +Wireless LAN base stations can also handle mobile phone appliances. Many +phones are already capable of connecting to the cellular phone network +or to an IP network either natively or using a Skype-like Voice-over-IP +service, thus bypassing the operator's cellular voice and 4G data +services. Of course, many other experts believe that 4G not only will be +a major success, but will also dramatically revolutionize the way we +work and live. Most likely, both WiFi and 4G will both become prevalent +wireless technologies, with roaming wireless devices automatically +selecting the access technology that provides the best service at their +current physical location. + +When people talk about cellular technology, they often classify the +technology as belonging to one of several "generations." The earliest +generations were designed primarily for voice traffic. First generation +(1G) systems were analog FDMA systems designed exclusively for +voice-only communication. These 1G systems are almost extinct now, +having been replaced by digital 2G systems. The original 2G systems were +also designed for voice, but later extended (2.5G) to support data +(i.e., Internet) as well as voice service. 3G systems also support voice +and data, but with an emphasis on data capabilities and + + higher-speed radio access links. The 4G systems being deployed today are +based on LTE technology, feature an all-IP core network, and provide +integrated voice and data at multi-Megabit speeds. Cellular Network +Architecture, 2G: Voice Connections to the Telephone Network The term +cellular refers to the fact that the region covered by a cellular +network is partitioned into a number of geographic coverage areas, known +as cells, shown as hexagons on the left side of Figure 7.18. As with the +802.11WiFi standard we studied in Section 7.3.1, GSM has its own +particular nomenclature. Each cell + +Figure 7.18 Components of the GSM 2G cellular network architecture + +contains a base transceiver station (BTS) that transmits signals to and +receives signals from the mobile stations in its cell. The coverage area +of a cell depends on many factors, including the transmitting power of +the BTS, the transmitting power of the user devices, obstructing +buildings in the cell, and the height of base station antennas. Although +Figure 7.18 shows each cell containing one base transceiver station +residing in the middle of the cell, many systems today place the BTS at +corners where three cells intersect, so that a single BTS with +directional antennas can service three cells. The GSM standard for 2G +cellular systems uses combined FDM/TDM (radio) for the air interface. +Recall from Chapter 1 that, with pure FDM, the channel is partitioned +into a number of frequency bands with each band devoted to a call. Also +recall from Chapter 1 that, with pure TDM, time is partitioned into + + frames with each frame further partitioned into slots and each call +being assigned the use of a particular slot in the revolving frame. In +combined FDM/TDM systems, the channel is partitioned into a number of +frequency sub-bands; within each sub-band, time is partitioned into +frames and slots. Thus, for a combined FDM/TDM system, if the channel is +partitioned into F sub-bands and time is partitioned into T slots, then +the channel will be able to support F.T simultaneous calls. Recall that +we saw in Section 6.3.4 that cable access networks also use a combined +FDM/TDM approach. GSM systems consist of 200-kHz frequency bands with +each band supporting eight TDM calls. GSM encodes speech at 13 kbps and +12.2 kbps. A GSM network's base station controller (BSC) will typically +service several tens of base transceiver stations. The role of the BSC +is to allocate BTS radio channels to mobile subscribers, perform paging +(finding the cell in which a mobile user is resident), and perform +handoff of mobile users---a topic we'll cover shortly in Section 7.7.2. +The base station controller and its controlled base transceiver stations +collectively constitute a GSM base station subsystem (BSS). As we'll see +in Section 7.7, the mobile switching center (MSC) plays the central role +in user authorization and accounting (e.g., determining whether a mobile +device is allowed to connect to the cellular network), call +establishment and teardown, and handoff. A single MSC will typically +contain up to five BSCs, resulting in approximately 200K subscribers per +MSC. A cellular provider's network will have a number of MSCs, with +special MSCs known as gateway MSCs connecting the provider's cellular +network to the larger public telephone network. + +7.4.2 3G Cellular Data Networks: Extending the Internet to Cellular +Subscribers Our discussion in Section 7.4.1 focused on connecting +cellular voice users to the public telephone network. But, of course, +when we're on the go, we'd also like to read e-mail, access the Web, get +location-dependent services (e.g., maps and restaurant recommendations) +and perhaps even watch streaming video. To do this, our smartphone will +need to run a full TCP/IP protocol stack (including the physical link, +network, transport, and application layers) and connect into the +Internet via the cellular data network. The topic of cellular data +networks is a rather bewildering collection of competing and +ever-evolving standards as one generation (and half-generation) succeeds +the former and introduces new technologies and services with new +acronyms. To make matters worse, there's no single official body that +sets requirements for 2.5G, 3G, 3.5G, or 4G technologies, making it hard +to sort out the differences among competing standards. In our discussion +below, we'll focus on the UMTS (Universal Mobile Telecommunications +Service) 3G and 4G standards developed by the 3rd Generation Partnership +project (3GPP) \[3GPP 2016\]. Let's first take a top-down look at 3G +cellular data network architecture shown in Figure 7.19. + + Figure 7.19 3G system architecture + +3G Core Network The 3G core cellular data network connects radio access +networks to the public Internet. The core network interoperates with +components of the existing cellular voice network (in particular, the +MSC) that we previously encountered in Figure 7.18. Given the +considerable amount of existing infrastructure (and profitable +services!) in the existing cellular voice network, the approach taken by +the designers of 3G data services is clear: leave the existing core GSM +cellular voice network untouched, adding additional cellular data +functionality in parallel to the existing cellular voice network. The +alternative--- integrating new data services directly into the core of +the existing cellular voice network---would have raised the same +challenges encountered in Section 4.3, where we discussed integrating +new (IPv6) and legacy (IPv4) technologies in the Internet. + + There are two types of nodes in the 3G core network: Serving GPRS +Support Nodes (SGSNs) and Gateway GPRS Support Nodes (GGSNs). (GPRS +stands for Generalized Packet Radio Service, an early cellular data +service in 2G networks; here we discuss the evolved version of GPRS in +3G networks). An SGSN is responsible for delivering datagrams to/from +the mobile nodes in the radio access network to which the SGSN is +attached. The SGSN interacts with the cellular voice network's MSC for +that area, providing user authorization and handoff, maintaining +location (cell) information about active mobile nodes, and performing +datagram forwarding between mobile nodes in the radio access network and +a GGSN. The GGSN acts as a gateway, connecting multiple SGSNs into the +larger Internet. A GGSN is thus the last piece of 3G infrastructure that +a datagram originating at a mobile node encounters before entering the +larger Internet. To the outside world, the GGSN looks like any other +gateway router; the mobility of the 3G nodes within the GGSN's network +is hidden from the outside world behind the GGSN. 3G Radio Access +Network: The Wireless Edge The 3G radio access network is the wireless +first-hop network that we see as a 3G user. The Radio Network Controller +(RNC) typically controls several cell base transceiver stations similar +to the base stations that we encountered in 2G systems (but officially +known in 3G UMTS parlance as a "Node Bs"---a rather non-descriptive +name!). Each cell's wireless link operates between the mobile nodes and +a base transceiver station, just as in 2G networks. The RNC connects to +both the circuit-switched cellular voice network via an MSC, and to the +packet-switched Internet via an SGSN. Thus, while 3G cellular voice and +cellular data services use different core networks, they share a common +first/last-hop radio access network. A significant change in 3G UMTS +over 2G networks is that rather than using GSM's FDMA/TDMA scheme, UMTS +uses a CDMA technique known as Direct Sequence Wideband CDMA (DS-WCDMA) +\[Dahlman 1998\] within TDMA slots; TDMA slots, in turn, are available +on multiple frequencies---an interesting use of all three dedicated +channel-sharing approaches that we earlier identified in Chapter 6 and +similar to the approach taken in wired cable access networks (see +Section 6.3.4). This change requires a new 3G cellular wireless-access +network operating in parallel with the 2G BSS radio network shown in +Figure 7.19. The data service associated with the WCDMA specification is +known as HSPA (High Speed Packet Access) and promises downlink data +rates of up to 14 Mbps. Details regarding 3G networks can be found at +the 3rd Generation Partnership Project (3GPP) Web site \[3GPP 2016\]. + +7.4.3 On to 4G: LTE Fourth generation (4G) cellular systems are becoming +widely deployed. In 2015, more than 50 countries had 4G coverage +exceeding 50%. The 4G Long-Term Evolution (LTE) standard \[Sauter 2014\] +put forward by the 3GPP has two important innovations over 3G systems an +all-IP core network and an + + enhanced radio access network, as discussed below. 4G System +Architecture: An All-IP Core Network Figure 7.20 shows the overall 4G +network architecture, which (unfortunately) introduces yet another +(rather impenetrable) new vocabulary and set of acronyms for + +Figure 7.20 4G network architecture + +network components. But let's not get lost in these acronyms! There are +two important high-level observations about the 4G architecture: A +unified, all-IP network architecture. Unlike the 3G network shown in +Figure 7.19, which has separate network components and paths for voice +and data traffic, the 4G architecture shown in Figure 7.20 is +"all-IP"---both voice and data are carried in IP datagrams to/from the +wireless device (the User Equipment, UE in 4G parlance) to the gateway +to the packet gateway (P-GW) that connects the 4G edge network to the +rest of the network. With 4G, the last vestiges of cellular networks' +roots in the telephony have disappeared, giving way to universal IP +service! A clear separation of the 4G data plane and 4G control plane. +Mirroring our distinction between the data and control planes for IP's +network layer in Chapters 4 and 5 respectively, the 4G network +architecture also clearly separates the data and control planes. We'll +discuss their functionality below. A clear separation between the radio +access network, and the all-IP-core network. IP datagrams carrying user +data are forwarded between the user (UE) and the gateway (P-GW in + + Figure 7.20) over a 4G-internal IP network to the external Internet. +Control packets are exchanged over this same internal network among the +4G's control services components, whose roles are described below. The +principal components of the 4G architecture are as follows. The eNodeB +is the logical descendant of the 2G base station and the 3G Radio +Network Controller (a.k.a Node B) and again plays a central role here. +Its data-plane role is to forward datagrams between UE (over the LTE +radio access network) and the P-GW. UE datagrams are encapsulated at the +eNodeB and tunneled to the P-GW through the 4G network's all-IP enhanced +packet core (EPC). This tunneling between the eNodeB and P-GW is similar +the tunneling we saw in Section 4.3 of IPv6 datagrams between two IPv6 +endpoints through a network of IPv4 routers. These tunnels may have +associated quality of service (QoS) guarantees. For example, a 4G +network may guarantee that voice traffic experiences no more than a 100 +msec delay between UE and P-GW, and has a packet loss rate of less than +1%; TCP traffic might have a guarantee of 300 msec and a packet loss +rate of less than .0001% \[Palat 2009\]. We'll cover QoS in Chapter 9. +In the control plane, the eNodeB handles registration and mobility +signaling traffic on behalf of the UE. The Packet Data Network Gateway +(P-GW) allocates IP addresses to the UEs and performs QoS enforcement. +As a tunnel endpoint it also performs datagram +encapsulation/decapsulation when forwarding a datagram to/from a UE. The +Serving Gateway (S-GW) is the data-plane mobility anchor point---all UE +traffic will pass through the S-GW. The S-GW also performs +charging/billing functions and lawful traffic interception. The Mobility +Management Entity (MME) performs connection and mobility management on +behalf of the UEs resident in the cell it controls. It receives UE +subscription information from the HHS. We cover mobility in cellular +networks in detail in Section 7.7. The Home Subscriber Server (HSS) +contains UE information including roaming access capabilities, quality +of service profiles, and authentication information. As we'll see in +Section 7.7, the HSS obtains this information from the UE's home +cellular provider. Very readable introductions to 4G network +architecture and its EPC are \[Motorola 2007; Palat 2009; Sauter 2014\]. +LTE Radio Access Network LTE uses a combination of frequency division +multiplexing and time division multiplexing on the downstream channel, +known as orthogonal frequency division multiplexing (OFDM) \[Rohde 2008; +Ericsson 2011\]. (The term "orthogonal" comes from the fact the signals +being sent on different frequency + + channels are created so that they interfere very little with each other, +even when channel frequencies are tightly spaced). In LTE, each active +mobile node is allocated one or more 0.5 ms time slots in one or more of +the channel frequencies. Figure 7.21 shows an allocation of eight time +slots over four frequencies. By being allocated increasingly more time +slots (whether on the same frequency or on different frequencies), a +mobile node is able to achieve increasingly higher transmission rates. +Slot (re)allocation among mobile + +Figure 7.21 Twenty 0.5 ms slots organized into 10 ms frames at each +frequency. An eight-slot allocation is shown shaded. + +nodes can be performed as often as once every millisecond. Different +modulation schemes can also be used to change the transmission rate; see +our earlier discussion of Figure 7.3 and dynamic selection of modulation +schemes in WiFi networks. The particular allocation of time slots to +mobile nodes is not mandated by the LTE standard. Instead, the decision +of which mobile nodes will be allowed to transmit in a given time slot +on a given frequency is determined by the scheduling algorithms provided +by the LTE equipment vendor and/or the network operator. With +opportunistic scheduling \[Bender 2000; Kolding 2003; Kulkarni 2005\], +matching the physical-layer protocol to the channel conditions between +the sender and receiver and choosing the receivers to which packets will +be sent based on channel conditions allow the radio network controller +to make best use of the wireless medium. In addition, user priorities +and contracted levels of service (e.g., silver, gold, or platinum) can +be used in scheduling downstream packet transmissions. In addition to +the LTE capabilities described above, LTE-Advanced allows for downstream +bandwidths of hundreds of Mbps by allocating aggregated channels to a +mobile node \[Akyildiz 2010\]. + + An additional 4G wireless technology---WiMAX (World Interoperability for +Microwave Access)---is a family of IEEE 802.16 standards that differ +significantly from LTE. WiMAX has not yet been able to enjoy the +widespread deployment of LTE. A detailed discussion of WiMAX can be +found on this book's Web site. + + 7.5 Mobility Management: Principles Having covered the wireless nature +of the communication links in a wireless network, it's now time to turn +our attention to the mobility that these wireless links enable. In the +broadest sense, a mobile node is one that changes its point of +attachment into the network over time. Because the term mobility has +taken on many meanings in both the computer and telephony worlds, it +will serve us well first to consider several dimensions of mobility in +some detail. From the network layer's standpoint, how mobile is a user? +A physically mobile user will present a very different set of challenges +to the network layer, depending on how he or she moves between points of +attachment to the network. At one end of the spectrum in Figure 7.22, a +user may carry a laptop with a wireless network interface card around in +a building. As we saw in Section 7.3.4, this user is not mobile from a +network-layer perspective. Moreover, if the user associates with the +same access point regardless of location, the user is not even mobile +from the perspective of the link layer. At the other end of the +spectrum, consider the user zooming along the autobahn in a BMW or Tesla +at 150 kilometers per hour, passing through multiple wireless access +networks and wanting to maintain an uninterrupted TCP connection to a +remote application throughout the trip. This user is definitely mobile! +In between + +Figure 7.22 Various degrees of mobility, from the network layer's point +of view + +these extremes is a user who takes a laptop from one location (e.g., +office or dormitory) into another (e.g., coffeeshop, classroom) and +wants to connect into the-network in the new location. This user is also +mobile (although less so than the BMW driver!) but does not need to +maintain an ongoing connection while moving between points of attachment +to the network. Figure 7.22 illustrates this spectrum of user mobility +from the network layer's perspective. How important is it for the mobile +node's address to always remain the same? With mobile telephony, your +phone number---essentially the network-layer address of your +phone---remains the same as you travel from one provider's mobile phone +network to another. Must a laptop similarly + + maintain the same IP address while moving between IP networks? The +answer to this question will depend strongly on the applications being +run. For the BMW or Tesla driver who wants to maintain an uninterrupted +TCP connection to a remote application while zipping along the autobahn, +it would be convenient to maintain the same IP address. Recall from +Chapter 3 that an Internet application needs to know the IP address and +port number of the remote entity with which it is communicating. If a +mobile entity is able to maintain its IP address as it moves, mobility +becomes invisible from the application standpoint. There is great value +to this transparency ---an application need not be concerned with a +potentially changing IP address, and the same application code serves +mobile and nonmobile connections alike. We'll see in the following +section that mobile IP provides this transparency, allowing a mobile +node to maintain its permanent IP address while moving among networks. +On the other hand, a less glamorous mobile user might simply want to +turn off an office laptop, bring that laptop home, power up, and work +from home. If the laptop functions primarily as a client in +client-server applications (e.g., send/read e-mail, browse the Web, +Telnet to a remote host) from home, the particular IP address used by +the laptop is not that important. In particular, one could get by fine +with an address that is temporarily allocated to the laptop by the ISP +serving the home. We saw in Section 4.3 that DHCP already provides this +functionality. What supporting wired infrastructure is available? In all +of our scenarios above, we've implicitly assumed that there is a fixed +infrastructure to which the mobile user can connect---for example, the +home's ISP network, the wireless access network in the office, or the +wireless access networks lining the autobahn. What if no such +infrastructure exists? If two users are within communication proximity +of each other, can they establish a network connection in the absence of +any other network-layer infrastructure? Ad hoc networking provides +precisely these capabilities. This rapidly developing area is at the +cutting edge of mobile networking research and is beyond the scope of +this book. \[Perkins 2000\] and the IETF Mobile Ad Hoc Network (manet) +working group Web pages \[manet 2016\] provide thorough treatments of +the subject. In order to illustrate the issues involved in allowing a +mobile user to maintain ongoing connections while moving between +networks, let's consider a human analogy. A twenty-something adult +moving out of the family home becomes mobile, living in a series of +dormitories and/or apartments, and often changing addresses. If an old +friend wants to get in touch, how can that friend find the address of +her mobile friend? One common way is to contact the family, since a +mobile adult will often register his or her current address with the +family (if for no other reason than so that the parents can send money +to help pay the rent!). The family home, with its permanent address, +becomes that one place that others can go as a first step in +communicating with the mobile adult. Later communication from the friend +may be either indirect (for example, with mail being sent first to the +parents' home and then forwarded to the mobile adult) or direct (for +example, with the friend using the address obtained from the parents to +send mail directly to her mobile friend). + + In a network setting, the permanent home of a mobile node (such as a +laptop or smartphone) is known as the home network, and the entity +within the home network that performs the mobility management functions +discussed below on behalf of the mobile node is known as the home agent. +The network in which the mobile node is currently residing is known as +the foreign (or visited) network, and the entity within the foreign +network that helps the mobile node with the mobility management +functions discussed below is known as a foreign agent. For mobile +professionals, their home network might likely be their company network, +while the visited network might be the network of a colleague they are +visiting. A correspondent is the entity wishing to communicate with the +mobile node. Figure 7.23 illustrates these concepts, as well as +addressing concepts considered below. In Figure 7.23, note that agents +are shown as being collocated with routers (e.g., as processes running +on routers), but alternatively they could be executing on other hosts or +servers in the network. + +7.5.1 Addressing We noted above that in order for user mobility to be +transparent to network applications, it is desirable for a mobile node +to keep its address as it moves from one network + +Figure 7.23 Initial elements of a mobile network architecture + + to another. When a mobile node is resident in a foreign network, all +traffic addressed to the node's permanent address now needs to be routed +to the foreign network. How can this be done? One option is for the +foreign network to advertise to all other networks that the mobile node +is resident in its network. This could be via the usual exchange of +intradomain and interdomain routing information and would require few +changes to the existing routing infrastructure. The foreign network +could simply advertise to its neighbors that it has a highly specific +route to the mobile node's permanent address (that is, essentially +inform other networks that it has the correct path for routing datagrams +to the mobile node's permanent address; see Section 4.3). These +neighbors would then propagate this routing information throughout the +network as part of the normal procedure of updating routing information +and forwarding tables. When the mobile node leaves one foreign network +and joins another, the new foreign network would advertise a new, highly +specific route to the mobile node, and the old foreign network would +withdraw its routing information regarding the mobile node. This solves +two problems at once, and it does so without making significant changes +to the networklayer infrastructure. Other networks know the location of +the mobile node, and it is easy to route datagrams to the mobile node, +since the forwarding tables will direct datagrams to the foreign +network. A significant drawback, however, is that of scalability. If +mobility management were to be the responsibility of network routers, +the routers would have to maintain forwarding table entries for +potentially millions of mobile nodes, and update these entries as nodes +move. Some additional drawbacks are explored in the problems at the end +of this chapter. An alternative approach (and one that has been adopted +in practice) is to push mobility functionality from the network core to +the network edge---a recurring theme in our study of Internet +architecture. A natural way to do this is via the mobile node's home +network. In much the same way that parents of the mobile +twenty-something track their child's location, the home agent in the +mobile node's home network can track the foreign network in which the +mobile node resides. A protocol between the mobile node (or a foreign +agent representing the mobile node) and the home agent will certainly be +needed to update the mobile node's location. Let's now consider the +foreign agent in more detail. The conceptually simplest approach, shown +in Figure 7.23, is to locate foreign agents at the edge routers in the +foreign network. One role of the foreign agent is to create a so-called +care-of address (COA) for the mobile node, with the network portion of +the COA matching that of the foreign network. There are thus two +addresses associated with a mobile node, its permanent address +(analogous to our mobile youth's family's home address) and its COA, +sometimes known as a foreign address (analogous to the address of the +house in which our mobile youth is currently residing). In the example +in Figure 7.23, the permanent address of the mobile node is +128.119.40.186. When visiting network 79.129.13/24, the mobile node has +a COA of 79.129.13.2. A second role of the foreign agent is to inform +the home agent that the mobile node is resident in its (the foreign +agent's) network and has the given COA. We'll see shortly that the COA +will + + be used to "reroute" datagrams to the mobile node via its foreign agent. +Although we have separated the functionality of the mobile node and the +foreign agent, it is worth noting that the mobile node can also assume +the responsibilities of the foreign agent. For example, the mobile node +could obtain a COA in the foreign network (for example, using a protocol +such as DHCP) and itself inform the home agent of its COA. + +7.5.2 Routing to a Mobile Node We have now seen how a mobile node +obtains a COA and how the home agent can be informed of that address. +But having the home agent know the COA solves only part of the problem. +How should datagrams be addressed and forwarded to the mobile node? +Since only the home agent (and not network-wide routers) knows the +location of the mobile node, it will no longer suffice to simply address +a datagram to the mobile node's permanent address and send it into the +network-layer infrastructure. Something more must be done. Two +approaches can be identified, which we will refer to as indirect and +direct routing. Indirect Routing to a Mobile Node Let's first consider a +correspondent that wants to send a datagram to a mobile node. In the +indirect routing approach, the correspondent simply addresses the +datagram to the mobile node's permanent address and sends the datagram +into the network, blissfully unaware of whether the mobile node is +resident in its home network or is visiting a foreign network; mobility +is thus completely transparent to the correspondent. Such datagrams are +first routed, as usual, to the mobile node's home network. This is +illustrated in step 1 in Figure 7.24. Let's now turn our attention to +the home agent. In addition to being responsible for interacting with a +foreign agent to track the mobile node's COA, the home agent has another +very important function. Its second job is to be on the lookout for +arriving datagrams addressed to nodes whose home network is that of the +home agent but that are currently resident in a foreign network. The +home agent intercepts these datagrams and then forwards them to a mobile +node in a two-step process. The datagram is first forwarded to the +foreign agent, using the mobile node's COA (step 2 in Figure 7.24), and +then forwarded from the foreign agent to the mobile node (step 3 in +Figure 7.24). + + Figure 7.24 Indirect routing to a mobile node + +It is instructive to consider this rerouting in more detail. The home +agent will need to address the datagram using the mobile node's COA, so +that the network layer will route the datagram to the foreign network. +On the other hand, it is desirable to leave the correspondent's datagram +intact, since the application receiving the datagram should be unaware +that the datagram was forwarded via the home agent. Both goals can be +satisfied by having the home agent encapsulate the correspondent's +original complete datagram within a new (larger) datagram. This larger +datagram is addressed and delivered to the mobile node's COA. The +foreign agent, who "owns" the COA, will receive and decapsulate the +datagram---that is, remove the correspondent's original datagram from +within the larger encapsulating datagram and forward (step 3 in Figure +7.24) the original datagram to the mobile node. Figure 7.25 shows a +correspondent's original datagram being sent to the home network, an +encapsulated datagram being sent to the foreign agent, and the original +datagram being delivered to the mobile node. The sharp reader will note +that the encapsulation/decapsulation described here is identical to the +notion of tunneling, discussed in Section 4.3 in the context of IP +multicast and IPv6. Let's next consider how a mobile node sends +datagrams to a correspondent. This is quite simple, as the mobile node +can address its datagram directly to the correspondent (using its own +permanent address as the source address, and the + + Figure 7.25 Encapsulation and decapsulation + +correspondent's address as the destination address). Since the mobile +node knows the correspondent's address, there is no need to route the +datagram back through the home agent. This is shown as step 4 in Figure +7.24. Let's summarize our discussion of indirect routing by listing the +new network-layer functionality required to support mobility. A +mobile-node--to--foreign-agent protocol. The mobile node will register +with the foreign agent when attaching to the foreign network. Similarly, +a mobile node will deregister with the foreign agent when it leaves the +foreign network. A foreign-agent--to--home-agent registration protocol. +The foreign agent will register the mobile node's COA with the home +agent. A foreign agent need not explicitly deregister a COA when a +mobile node leaves its network, because the subsequent registration of a +new COA, when the mobile node moves to a new network, will take care of +this. A home-agent datagram encapsulation protocol. Encapsulation and +forwarding of the correspondent's original datagram within a datagram +addressed to the COA. A foreign-agent decapsulation protocol. Extraction +of the correspondent's original datagram from the encapsulating +datagram, and the forwarding of the original datagram to the mobile +node. The previous discussion provides all the pieces---foreign agents, +the home agent, and indirect + + forwarding---needed for a mobile node to maintain an ongoing connection +while moving among networks. As an example of how these pieces fit +together, assume the mobile node is attached to foreign network A, has +registered a COA in network A with its home agent, and is receiving +datagrams that are being indirectly routed through its home agent. The +mobile node now moves to foreign network B and registers with the +foreign agent in network B, which informs the home agent of the mobile +node's new COA. From this point on, the home agent will reroute +datagrams to foreign network B. As far as a correspondent is concerned, +mobility is transparent---datagrams are routed via the same home agent +both before and after the move. As far as the home agent is concerned, +there is no disruption in the flow of datagrams---arriving datagrams are +first forwarded to foreign network A; after the change in COA, datagrams +are forwarded to foreign network B. But will the mobile node see an +interrupted flow of datagrams as it moves between networks? As long as +the time between the mobile node's disconnection from network A (at +which point it can no longer receive datagrams via A) and its attachment +to network B (at which point it will register a new COA with its home +agent) is small, few datagrams will be lost. Recall from Chapter 3 that +end-to-end connections can suffer datagram loss due to network +congestion. Hence occasional datagram loss within a connection when a +node moves between networks is by no means a catastrophic problem. If +loss-free communication is required, upperlayer mechanisms will recover +from datagram loss, whether such loss results from network congestion or +from user mobility. An indirect routing approach is used in the mobile +IP standard \[RFC 5944\], as discussed in Section 7.6. Direct Routing to +a Mobile Node The indirect routing approach illustrated in Figure 7.24 +suffers from an inefficiency known as the triangle routing +problem---datagrams addressed to the mobile node must be routed first to +the home agent and then to the foreign network, even when a much more +efficient route exists between the correspondent and the mobile node. In +the worst case, imagine a mobile user who is visiting the foreign +network of a colleague. The two are sitting side by side and exchanging +data over the network. Datagrams from the correspondent (in this case +the colleague of the visitor) are routed to the mobile user's home agent +and then back again to the foreign network! Direct routing overcomes the +inefficiency of triangle routing, but does so at the cost of additional +complexity. In the direct routing approach, a correspondent agent in the +correspondent's network first learns the COA of the mobile node. This +can be done by having the correspondent agent query the home agent, +assuming that (as in the case of indirect routing) the mobile node has +an up-to-date value for its COA registered with its home agent. It is +also possible for the correspondent itself to perform the function of +the correspondent agent, just as a mobile node could perform the +function of the foreign agent. This is shown as steps 1 and 2 in Figure +7.26. The correspondent agent then tunnels datagrams directly to the +mobile node's COA, in a manner analogous to the tunneling performed by +the home agent, steps 3 and 4 in Figure 7.26. + + While direct routing overcomes the triangle routing problem, it +introduces two important additional challenges: A mobile-user location +protocol is needed for the correspondent agent to query the home agent +to obtain the mobile node's COA (steps 1 and 2 in Figure 7.26). When the +mobile node moves from one foreign network to another, how will data now +be forwarded to the new foreign network? In the case of indirect +routing, this problem was easily solved by updating the COA maintained +by the home agent. However, with direct routing, the home agent is +queried for the COA by the correspondent agent only once, at the +beginning of the session. Thus, updating the COA at the home agent, +while necessary, will not be enough to solve the problem of routing data +to the mobile node's new foreign network. One solution would be to +create a new protocol to notify the correspondent of the changing COA. +An alternate solution, and one that we'll see adopted in practice + +Figure 7.26 Direct routing to a mobile user + + in GSM networks, works as follows. Suppose data is currently being +forwarded to the mobile node in the foreign network where the mobile +node was located when the session first started (step 1 in Figure 7.27). +We'll identify the foreign agent in that foreign network where the +mobile node was first found as the anchor foreign agent. When the mobile +node moves to a new foreign network (step 2 in Figure 7.27), the mobile +node registers with the new foreign agent (step 3), and the new foreign +agent provides the anchor foreign agent with the mobile node's new COA +(step 4). When the anchor foreign agent receives an encapsulated +datagram for a departed mobile node, it can then re-encapsulate the +datagram and forward it to the mobile node (step 5) using the new COA. +If the mobile node later moves yet again to a new foreign network, the +foreign agent in that new visited network would then contact the anchor +foreign agent in order to set up forwarding to this new foreign network. + +Figure 7.27 Mobile transfer between networks with direct routing + + 7.6 Mobile IP The Internet architecture and protocols for supporting +mobility, collectively known as mobile IP, are defined primarily in RFC +5944 for IPv4. Mobile IP is a flexible standard, supporting many +different modes of operation (for example, operation with or without a +foreign agent), multiple ways for agents and mobile nodes to discover +each other, use of single or multiple COAs, and multiple forms of +encapsulation. As such, mobile IP is a complex standard, and would +require an entire book to describe in detail; indeed one such book is +\[Perkins 1998b\]. Our modest goal here is to provide an overview of the +most important aspects of mobile IP and to illustrate its use in a few +common-case scenarios. The mobile IP architecture contains many of the +elements we have considered above, including the concepts of home +agents, foreign agents, care-of addresses, and +encapsulation/decapsulation. The current standard \[RFC 5944\] specifies +the use of indirect routing to the mobile node. The mobile IP standard +consists of three main pieces: Agent discovery. Mobile IP defines the +protocols used by a home or foreign agent to advertise its services to +mobile nodes, and protocols for mobile nodes to solicit the services of +a foreign or home agent. Registration with the home agent. Mobile IP +defines the protocols used by the mobile node and/or foreign agent to +register and deregister COAs with a mobile node's home agent. Indirect +routing of datagrams. The standard also defines the manner in which +datagrams are forwarded to mobile nodes by a home agent, including rules +for forwarding datagrams, rules for handling error conditions, and +several forms of encapsulation \[RFC 2003, RFC 2004\]. Security +considerations are prominent throughout the mobile IP standard. For +example, authentication of a mobile node is clearly needed to ensure +that a malicious user does not register a bogus care-of address with a +home agent, which could cause all datagrams addressed to an IP address +to be redirected to the malicious user. Mobile IP achieves security +using many of the mechanisms that we will examine in Chapter 8, so we +will not address security considerations in our discussion below. Agent +Discovery A mobile IP node arriving to a new network, whether attaching +to a foreign network or returning to its home network, must learn the +identity of the corresponding foreign or home agent. Indeed it is the +discovery of a new foreign agent, with a new network address, that +allows the network layer in a mobile + + node to learn that it has moved into a new foreign network. This process +is known as agent discovery. Agent discovery can be accomplished in one +of two ways: via agent advertisement or via agent solicitation. With +agent advertisement, a foreign or home agent advertises its services +using an extension to the existing router discovery protocol \[RFC +1256\]. The agent periodically broadcasts an ICMP message with a type +field of 9 (router discovery) on all links to which it is connected. The +router discovery message contains the IP address of the router (that is, +the agent), thus allowing a mobile node to learn the agent's IP address. +The router discovery message also contains a mobility agent +advertisement extension that contains additional information needed by +the mobile node. Among the more important fields in the extension are +the following: Home agent bit (H). Indicates that the agent is a home +agent for the network in which it resides. Foreign agent bit (F). +Indicates that the agent is a foreign agent for the network in which it +resides. Registration required bit (R). Indicates that a mobile user in +this network must register with a foreign agent. In particular, a mobile +user cannot obtain a care-of address in the foreign network (for +example, using DHCP) and assume the functionality of the foreign agent +for itself, without registering with the foreign agent. + +Figure 7.28 ICMP router discovery message with mobility agent +advertisement extension + +M, G encapsulation bits. Indicate whether a form of encapsulation other +than IP-in-IP encapsulation will be used. Care-of address (COA) fields. +A list of one or more care-of addresses provided by the foreign + + agent. In our example below, the COA will be associated with the foreign +agent, who will receive datagrams sent to the COA and then forward them +to the appropriate mobile node. The mobile user will select one of these +addresses as its COA when registering with its home agent. Figure 7.28 +illustrates some of the key fields in the agent advertisement message. +With agent solicitation, a mobile node wanting to learn about agents +without waiting to receive an agent advertisement can broadcast an agent +solicitation message, which is simply an ICMP message with type value +10. An agent receiving the solicitation will unicast an agent +advertisement directly to the mobile node, which can then proceed as if +it had received an unsolicited advertisement. Registration with the Home +Agent Once a mobile IP node has received a COA, that address must be +registered with the home agent. This can be done either via the foreign +agent (who then registers the COA with the home agent) or directly by +the mobile IP node itself. We consider the former case below. Four steps +are involved. + +1. Following the receipt of a foreign agent advertisement, a mobile + node sends a mobile IP registration message to the foreign agent. + The registration message is carried within a UDP datagram and sent + to port 434. The registration message carries a COA advertised by + the foreign agent, the address of the home agent (HA), the permanent + address of the mobile node (MA), the requested lifetime of the + registration, and a 64-bit registration identification. The + requested registration lifetime is the number of seconds that the + registration is to be valid. If the registration is not renewed at + the home agent within the specified lifetime, the registration will + become invalid. The registration identifier acts like a sequence + number and serves to match a received registration reply with a + registration request, as discussed below. + +2. The foreign agent receives the registration message and records the + mobile node's permanent IP address. The foreign agent now knows that + it should be looking for datagrams containing an encapsulated + datagram whose destination address matches the permanent address of + the mobile node. The foreign agent then sends a mobile IP + registration message (again, within a UDP datagram) to port 434 of + the home agent. The message contains the COA, HA, MA, encapsulation + format requested, requested registration lifetime, and registration + identification. + +3. The home agent receives the registration request and checks for + authenticity and correctness. The home agent binds the mobile node's + permanent IP address with the COA; in the future, datagrams arriving + at the home agent and addressed to the mobile node will now be + encapsulated and tunneled to the COA. The home agent sends a mobile + IP registration reply containing the HA, MA, actual registration + lifetime, and the registration identification of the request that is + being satisfied with this reply. + +4. The foreign agent receives the registration reply and then forwards + it to the mobile node. + + At this point, registration is complete, and the mobile node can receive +datagrams sent to its permanent address. Figure 7.29 illustrates these +steps. Note that the home agent specifies a lifetime that is smaller +than the lifetime requested by the mobile node. A foreign agent need not +explicitly deregister a COA when a mobile node leaves its network. This +will occur automatically, when the mobile node moves to a new network +(whether another foreign network or its home network) and registers a +new COA. The mobile IP standard allows many additional scenarios and +capabilities in addition to those described previously. The interested +reader should consult \[Perkins 1998b; RFC 5944\]. + + Figure 7.29 Agent advertisement and mobile IP registration + + 7.7 Managing Mobility in Cellular Networks Having examined how mobility +is managed in IP networks, let's now turn our attention to networks with +an even longer history of supporting mobility---cellular telephony +networks. Whereas we focused on the first-hop wireless link in cellular +networks in Section 7.4, we'll focus here on mobility, using the GSM +cellular network \[Goodman 1997; Mouly 1992; Scourias 2012; Kaaranen +2001; Korhonen 2003; Turner 2012\] as our case study, since it is a +mature and widely deployed technology. Mobility in 3G and 4G networks is +similar in principle to that used in GSM. As in the case of mobile IP, +we'll see that a number of the fundamental principles we identified in +Section 7.5 are embodied in GSM's network architecture. Like mobile IP, +GSM adopts an indirect routing approach (see Section 7.5.2), first +routing the correspondent's call to the mobile user's home network and +from there to the visited network. In GSM terminology, the mobile +users's home network is referred to as the mobile user's home public +land mobile network (home PLMN). Since the PLMN acronym is a bit of a +mouthful, and mindful of our quest to avoid an alphabet soup of +acronyms, we'll refer to the GSM home PLMN simply as the home network. +The home network is the cellular provider with which the mobile user has +a subscription (i.e., the provider that bills the user for monthly +cellular service). The visited PLMN, which we'll refer to simply as the +visited network, is the network in which the mobile user is currently +residing. As in the case of mobile IP, the responsibilities of the home +and visited networks are quite different. The home network maintains a +database known as the home location register (HLR), which contains the +permanent cell phone number and subscriber profile information for each +of its subscribers. Importantly, the HLR also contains information about +the current locations of these subscribers. That is, if a mobile user is +currently roaming in another provider's cellular network, the HLR +contains enough information to obtain (via a process we'll describe +shortly) an address in the visited network to which a call to the mobile +user should be routed. As we'll see, a special switch in the home +network, known as the Gateway Mobile services Switching Center (GMSC) is +contacted by a correspondent when a call is placed to a mobile user. +Again, in our quest to avoid an alphabet soup of acronyms, we'll refer +to the GMSC here by a more descriptive term, home MSC. The visited +network maintains a database known as the visitor location register +(VLR). The VLR contains an entry for each mobile user that is currently +in the portion of the network served by the VLR. VLR entries thus come +and go as mobile users enter and leave the network. A VLR is usually +co-located with the mobile switching center (MSC) that coordinates the +setup of a call to and from the visited network. + + In practice, a provider's cellular network will serve as a home network +for its subscribers and as a visited network for mobile users whose +subscription is with a different cellular provider. + +Figure 7.30 Placing a call to a mobile user: Indirect routing + +7.7.1 Routing Calls to a Mobile User We're now in a position to describe +how a call is placed to a mobile GSM user in a visited network. We'll +consider a simple example below; more complex scenarios are described in +\[Mouly 1992\]. The steps, as illustrated in Figure 7.30, are as +follows: + +1. The correspondent dials the mobile user's phone number. This number + itself does not refer to a particular telephone line or location + (after all, the phone number is fixed and the user is mobile!). The + leading digits in the number are sufficient to globally identify the + mobile's home network. The call is routed from the correspondent + through the PSTN to the home MSC in the mobile's home network. This + is the first leg of the call. + +2. The home MSC receives the call and interrogates the HLR to determine + the location of the mobile user. In the simplest case, the HLR + returns the mobile station roaming number (MSRN), which we will + refer to as the roaming number. Note that this number is different + from the mobile's permanent phone number, which is associated with + the mobile's home network. The + + roaming number is ephemeral: It is temporarily assigned to a mobile when +it enters a visited network. The roaming number serves a role similar to +that of the care-of address in mobile IP and, like the COA, is invisible +to the correspondent and the mobile. If HLR does not have the roaming +number, it returns the address of the VLR in the visited network. In +this case (not shown in Figure 7.30), the home MSC will need to query +the VLR to obtain the roaming number of the mobile node. But how does +the HLR get the roaming number or the VLR address in the first place? +What happens to these values when the mobile user moves to another +visited network? We'll consider these important questions shortly. + +3. Given the roaming number, the home MSC sets up the second leg of the + call through the network to the MSC in the visited network. The call + is completed, being routed from the correspondent to the home MSC, + and from there to the visited MSC, and from there to the base + station serving the mobile user. An unresolved question in step 2 is + how the HLR obtains information about the location of the mobile + user. When a mobile telephone is switched on or enters a part of a + visited network that is covered by a new VLR, the mobile must + register with the visited network. This is done through the exchange + of signaling messages between the mobile and the VLR. The visited + VLR, in turn, sends a location update request message to the + mobile's HLR. This message informs the HLR of either the roaming + number at which the mobile can be contacted, or the address of the + VLR (which can then later be queried to obtain the mobile number). + As part of this exchange, the VLR also obtains subscriber + information from the HLR about the mobile and determines what + services (if any) should be accorded the mobile user by the visited + network. + +7.7.2 Handoffs in GSM A handoff occurs when a mobile station changes its +association from one base station to another during a call. As shown in +Figure 7.31, a mobile's call is initially (before handoff) routed to the +mobile through one base station (which we'll refer to as the old base +station), and after handoff is routed to the mobile through another base + + Figure 7.31 Handoff scenario between base stations with a common MSC + +station (which we'll refer to as the new base station). Note that a +handoff between base stations results not only in the mobile +transmitting/receiving to/from a new base station, but also in the +rerouting of the ongoing call from a switching point within the network +to the new base station. Let's initially assume that the old and new +base stations share the same MSC, and that the rerouting occurs at this +MSC. There may be several reasons for handoff to occur, including (1) +the signal between the current base station and the mobile may have +deteriorated to such an extent that the call is in danger of being +dropped, and (2) a cell may have become overloaded, handling a large +number of calls. This congestion may be alleviated by handing off +mobiles to less congested nearby cells. While it is associated with a +base station, a mobile periodically measures the strength of a beacon +signal from its current base station as well as beacon signals from +nearby base stations that it can "hear." These measurements are reported +once or twice a second to the mobile's current base station. Handoff in +GSM is initiated by the old base station based on these measurements, +the current loads of mobiles in nearby cells, and other factors \[Mouly +1992\]. The GSM standard does not specify the specific algorithm to be +used by a base station to determine whether or not to perform handoff. +Figure 7.32 illustrates the steps involved when a base station does +decide to hand off a mobile user: + +1. The old base station (BS) informs the visited MSC that a handoff is + to be performed and the BS (or possible set of BSs) to which the + mobile is to be handed off. + +2. The visited MSC initiates path setup to the new BS, allocating the + resources needed to carry the rerouted call, and signaling the new + BS that a handoff is about to occur. + +3. The new BS allocates and activates a radio channel for use by the + mobile. + +4. The new BS signals back to the visited MSC and the old BS that the + visited-MSC-to-new-BS path has been established and that the mobile + should be + + Figure 7.32 Steps in accomplishing a handoff between base stations with +a common MSC + +informed of the impending handoff. The new BS provides all of the +information that the mobile will need to associate with the new BS. + +5. The mobile is informed that it should perform a handoff. Note that + up until this point, the mobile has been blissfully unaware that the + network has been laying the groundwork (e.g., allocating a channel + in the new BS and allocating a path from the visited MSC to the new + BS) for a handoff. + +6. The mobile and the new BS exchange one or more messages to fully + activate the new channel in the new BS. + +7. The mobile sends a handoff complete message to the new BS, which is + forwarded up to the visited MSC. The visited MSC then reroutes the + ongoing call to the mobile via the new BS. + +8. The resources allocated along the path to the old BS are then + released. Let's conclude our discussion of handoff by considering + what happens when the mobile moves to a BS that is associated with a + different MSC than the old BS, and what happens when this inter-MSC + handoff occurs more than once. As shown in Figure 7.33, GSM defines + the notion of an anchor MSC. The anchor MSC is the MSC visited by + the mobile when a call first begins; the anchor MSC thus remains + unchanged during the call. Throughout the call's duration and + regardless of the number of inter-MSC + +Figure 7.33 Rerouting via the anchor MSC + + Table 7.2 Commonalities between mobile IP and GSM mobility GSM element + +Comment on GSM element + +Mobile IP element + +Home system + +Network to which the mobile user's permanent phone number + +Home + +belongs. + +network + +Gateway mobile + +Home MSC: point of contact to obtain routable address of + +Home + +switching center or + +mobile user. HLR: database in home system containing + +agent + +simply home MSC, + +permanent phone number, profile information, current location + +Home location register + +of mobile user, subscription information. + +(HLR) Visited system + +Network other than home system where mobile user is + +Visited + +currently residing. + +network + +Visited mobile services + +Visited MSC: responsible for setting up calls to/from mobile + +Foreign + +switching center, + +nodes in cells associated with MSC. VLR: temporary database + +agent + +Visitor location register + +entry in visited system, containing subscription information for + +(VLR) + +each visiting mobile user. + + Mobile station roaming + +Routable address for telephone call segment between home + +Care-of + +number (MSRN) or + +MSC and visited MSC, visible to neither the mobile nor the + +address + +simply roaming number + +correspondent. + +transfers performed by the mobile, the call is routed from the home MSC +to the anchor MSC, and then from the anchor MSC to the visited MSC where +the mobile is currently located. When a mobile moves from the coverage +area of one MSC to another, the ongoing call is rerouted from the anchor +MSC to the new visited MSC containing the new base station. Thus, at all +times there are at most three MSCs (the home MSC, the anchor MSC, and +the visited MSC) between the correspondent and the mobile. Figure 7.33 +illustrates the routing of a call among the MSCs visited by a mobile +user. Rather than maintaining a single MSC hop from the anchor MSC to +the current MSC, an alternative approach would have been to simply chain +the MSCs visited by the mobile, having an old MSC forward the ongoing +call to the new MSC each time the mobile moves to a new MSC. Such MSC +chaining can in fact occur in IS-41 cellular networks, with an optional +path minimization step to remove MSCs between the anchor MSC and the +current visited MSC \[Lin 2001\]. Let's wrap up our discussion of GSM +mobility management with a comparison of mobility management in GSM and +Mobile IP. The comparison in Table 7.2 indicates that although IP and +cellular networks are fundamentally different in many ways, they share a +surprising number of common functional elements and overall approaches +in handling mobility. + + 7.8 Wireless and Mobility: Impact on Higher-Layer Protocols In this +chapter, we've seen that wireless networks differ significantly from +their wired counterparts at both the link layer (as a result of wireless +channel characteristics such as fading, multipath, and hidden terminals) +and at the network layer (as a result of mobile users who change their +points of attachment to the network). But are there important +differences at the transport and application layers? It's tempting to +think that these differences will be minor, since the network layer +provides the same best-effort delivery service model to upper layers in +both wired and wireless networks. Similarly, if protocols such as TCP or +UDP are used to provide transport-layer services to applications in both +wired and wireless networks, then the application layer should remain +unchanged as well. In one sense our intuition is right---TCP and UDP can +(and do) operate in networks with wireless links. On the other hand, +transport protocols in general, and TCP in particular, can sometimes +have very different performance in wired and wireless networks, and it +is here, in terms of performance, that differences are manifested. Let's +see why. Recall that TCP retransmits a segment that is either lost or +corrupted on the path between sender and receiver. In the case of mobile +users, loss can result from either network congestion (router buffer +overflow) or from handoff (e.g., from delays in rerouting segments to a +mobile's new point of attachment to the network). In all cases, TCP's +receiver-to-sender ACK indicates only that a segment was not received +intact; the sender is unaware of whether the segment was lost due to +congestion, during handoff, or due to detected bit errors. In all cases, +the sender's response is the same---to retransmit the segment. TCP's +congestion-control response is also the same in all cases---TCP +decreases its congestion window, as discussed in Section 3.7. By +unconditionally decreasing its congestion window, TCP implicitly assumes +that segment loss results from congestion rather than corruption or +handoff. We saw in Section 7.2 that bit errors are much more common in +wireless networks than in wired networks. When such bit errors occur or +when handoff loss occurs, there's really no reason for the TCP sender to +decrease its congestion window (and thus decrease its sending rate). +Indeed, it may well be the case that router buffers are empty and +packets are flowing along the end-to-end path unimpeded by congestion. +Researchers realized in the early to mid 1990s that given high bit error +rates on wireless links and the possibility of handoff loss, TCP's +congestion-control response could be problematic in a wireless setting. +Three broad classes of approaches are possible for dealing with this +problem: Local recovery. Local recovery protocols recover from bit +errors when and where (e.g., at the wireless link) they occur, e.g., the +802.11 ARQ protocol we studied in Section 7.3, or more sophisticated +approaches that use both ARQ and FEC \[Ayanoglu 1995\]. + + TCP sender awareness of wireless links. In the local recovery +approaches, the TCP sender is blissfully unaware that its segments are +traversing a wireless link. An alternative approach is for the TCP +sender and receiver to be aware of the existence of a wireless link, to +distinguish between congestive losses occurring in the wired network and +corruption/loss occurring at the wireless link, and to invoke congestion +control only in response to congestive wired-network losses. +\[Balakrishnan 1997\] investigates various types of TCP, assuming that +end systems can make this distinction. \[Liu 2003\] investigates +techniques for distinguishing between losses on the wired and wireless +segments of an end-to-end path. Split-connection approaches. In a +split-connection approach \[Bakre 1995\], the end-to-end connection +between the mobile user and the other end point is broken into two +transport-layer connections: one from the mobile host to the wireless +access point, and one from the wireless access point to the other +communication end point (which we'll assume here is a wired host). The +end-to-end connection is thus formed by the concatenation of a wireless +part and a wired part. The transport layer over the wireless segment can +be a standard TCP connection \[Bakre 1995\], or a specially tailored +error recovery protocol on top of UDP. \[Yavatkar 1994\] investigates +the use of a transport-layer selective repeat protocol over the wireless +connection. Measurements reported in \[Wei 2006\] indicate that split +TCP connections are widely used in cellular data networks, and that +significant improvements can indeed be made through the use of split TCP +connections. Our treatment of TCP over wireless links has been +necessarily brief here. In-depth surveys of TCP challenges and solutions +in wireless networks can be found in \[Hanabali 2005; Leung 2006\]. We +encourage you to consult the references for details of this ongoing area +of research. Having considered transport-layer protocols, let us next +consider the effect of wireless and mobility on application-layer +protocols. Here, an important consideration is that wireless links often +have relatively low bandwidths, as we saw in Figure 7.2. As a result, +applications that operate over wireless links, particularly over +cellular wireless links, must treat bandwidth as a scarce commodity. For +example, a Web server serving content to a Web browser executing on a 4G +phone will likely not be able to provide the same image-rich content +that it gives to a browser operating over a wired connection. Although +wireless links do provide challenges at the application layer, the +mobility they enable also makes possible a rich set of location-aware +and context-aware applications \[Chen 2000; Baldauf 2007\]. More +generally, wireless and mobile networks will play a key role in +realizing the ubiquitous computing environments of the future \[Weiser +1991\]. It's fair to say that we've only seen the tip of the iceberg +when it comes to the impact of wireless and mobile networks on networked +applications and their protocols! + + 7.9 Summary Wireless and mobile networks have revolutionized telephony +and are having an increasingly profound impact in the world of computer +networks as well. With their anytime, anywhere, untethered access into +the global network infrastructure, they are not only making network +access more ubiquitous, they are also enabling an exciting new set of +location-dependent services. Given the growing importance of wireless +and mobile networks, this chapter has focused on the principles, common +link technologies, and network architectures for supporting wireless and +mobile communication. We began this chapter with an introduction to +wireless and mobile networks, drawing an important distinction between +the challenges posed by the wireless nature of the communication links +in such networks, and by the mobility that these wireless links enable. +This allowed us to better isolate, identify, and master the key concepts +in each area. We focused first on wireless communication, considering +the characteristics of a wireless link in Section 7.2. In Sections 7.3 +and 7.4, we examined the link-level aspects of the IEEE 802.11 (WiFi) +wireless LAN standard, two IEEE 802.15 personal area networks (Bluetooth +and Zigbee), and 3G and 4G cellular Internet access. We then turned our +attention to the issue of mobility. In Section 7.5, we identified +several forms of mobility, with points along this spectrum posing +different challenges and admitting different solutions. We considered +the problems of locating and routing to a mobile user, as well as +approaches for handing off the mobile user who dynamically moves from +one point of attachment to the network to another. We examined how these +issues were addressed in the mobile IP standard and in GSM, in Sections +7.6 and 7.7, respectively. Finally, we considered the impact of wireless +links and mobility on transport-layer protocols and networked +applications in Section 7.8. Although we have devoted an entire chapter +to the study of wireless and mobile networks, an entire book (or more) +would be required to fully explore this exciting and rapidly expanding +field. We encourage you to delve more deeply into this field by +consulting the many references provided in this chapter. + + Homework Problems and Questions + +Chapter 7 Review Questions + +Section 7.1 R1. What does it mean for a wireless network to be operating +in "infrastructure mode"? If the network is not in infrastructure mode, +what mode of operation is it in, and what is the difference between that +mode of operation and infrastructure mode? R2. What are the four types +of wireless networks identified in our taxonomy in Section 7.1 ? Which +of these types of wireless networks have you used? + +Section 7.2 R3. What are the differences between the following types of +wireless channel impairments: path loss, multipath propagation, +interference from other sources? R4. As a mobile node gets farther and +farther away from a base station, what are two actions that a base +station could take to ensure that the loss probability of a transmitted +frame does not increase? + +Sections 7.3 and 7.4 R5. Describe the role of the beacon frames in +802.11. R6. True or false: Before an 802.11 station transmits a data +frame, it must first send an RTS frame and receive a corresponding CTS +frame. R7. Why are acknowledgments used in 802.11 but not in wired +Ethernet? R8. True or false: Ethernet and 802.11 use the same frame +structure. R9. Describe how the RTS threshold works. R10. Suppose the +IEEE 802.11 RTS and CTS frames were as long as the standard DATA and ACK +frames. Would there be any advantage to using the CTS and RTS frames? +Why or why not? R11. Section 7.3.4 discusses 802.11 mobility, in which a +wireless station moves from one BSS to another within the same subnet. +When the APs are interconnected with a switch, an AP may need to send a +frame with a spoofed MAC address to get the switch to forward the frame +properly. Why? + + R12. What are the differences between a master device in a Bluetooth +network and a base station in an 802.11 network? R13. What is meant by a +super frame in the 802.15.4 Zigbee standard? R14. What is the role of +the "core network" in the 3G cellular data architecture? R15. What is +the role of the RNC in the 3G cellular data network architecture? What +role does the RNC play in the cellular voice network? R16. What is the +role of the eNodeB, MME, P-GW, and S-GW in 4G architecture? R17. What +are three important differences between the 3G and 4G cellular +architectures? + +Sections 7.5 and 7.6 R18. If a node has a wireless connection to the +Internet, does that node have to be mobile? Explain. Suppose that a user +with a laptop walks around her house with her laptop, and always +accesses the Internet through the same access point. Is this user mobile +from a network standpoint? Explain. R19. What is the difference between +a permanent address and a care-of address? Who assigns a care-of +address? R20. Consider a TCP connection going over Mobile IP. True or +false: The TCP connection phase between the correspondent and the mobile +host goes through the mobile's home network, but the data transfer phase +is directly between the correspondent and the mobile host, bypassing the +home network. + +Section 7.7 R21. What are the purposes of the HLR and VLR in GSM +networks? What elements of mobile IP are similar to the HLR and VLR? +R22. What is the role of the anchor MSC in GSM networks? + +Section 7.8 R23. What are three approaches that can be taken to avoid +having a single wireless link degrade the performance of an end-to-end +transport-layer TCP connection? + +Problems P1. Consider the single-sender CDMA example in Figure 7.5 . +What would be the sender's output (for the 2 data bits shown) if the +sender's CDMA code were (1,−1,1,−1,1,−1,1,−1)? P2. Consider sender 2 in +Figure 7.6 . What is the sender's output to the channel (before it is +added to the signal from sender 1), Zi,m2? + + P3. Suppose that the receiver in Figure 7.6 wanted to receive the data +being sent by sender 2. Show (by calculation) that the receiver is +indeed able to recover sender 2's data from the aggregate channel signal +by using sender 2's code. P4. For the two-sender, two-receiver example, +give an example of two CDMA codes containing 1 and 21 values that do not +allow the two receivers to extract the original transmitted bits from +the two CDMA senders. P5. Suppose there are two ISPs providing WiFi +access in a particular café, with each ISP operating its own AP and +having its own IP address block. + +a. Further suppose that by accident, each ISP has configured its AP to + operate over channel 11. Will the 802.11 protocol completely break + down in this situation? Discuss what happens when two stations, each + associated with a different ISP, attempt to transmit at the same + time. + +b. Now suppose that one AP operates over channel 1 and the other over + channel 11. How do your answers change? P6. In step 4 of the CSMA/CA + protocol, a station that successfully transmits a frame begins the + CSMA/CA protocol for a second frame at step 2, rather than at + step 1. What rationale might the designers of CSMA/CA have had in + mind by having such a station not transmit the second frame + immediately (if the channel is sensed idle)? P7. Suppose an 802.11b + station is configured to always reserve the channel with the RTS/CTS + sequence. Suppose this station suddenly wants to transmit 1,000 + bytes of data, and all other stations are idle at this time. As a + function of SIFS and DIFS, and ignoring propagation delay and + assuming no bit errors, calculate the time required to transmit the + frame and receive the acknowledgment. P8. Consider the scenario + shown in Figure 7.34 , in which there are four wireless nodes, A, B, + C, and D. The radio coverage of the four nodes is shown via the + shaded ovals; all nodes share the same frequency. When A transmits, + it + +Figure 7.34 Scenario for problem P8 + +can only be heard/received by B; when B transmits, both A and C can +hear/receive from B; when C transmits, both B and D can hear/receive +from C; when D transmits, only C can hear/receive + + from D. Suppose now that each node has an infinite supply of messages +that it wants to send to each of the other nodes. If a message's +destination is not an immediate neighbor, then the message must be +relayed. For example, if A wants to send to D, a message from A must +first be sent to B, which then sends the message to C, which then sends +the message to D. Time is slotted, with a message transmission time +taking exactly one time slot, e.g., as in slotted Aloha. During a slot, +a node can do one of the following: (i) send a message, (ii) receive a +message (if exactly one message is being sent to it), (iii) remain +silent. As always, if a node hears two or more simultaneous +transmissions, a collision occurs and none of the transmitted messages +are received successfully. You can assume here that there are no +bit-level errors, and thus if exactly one message is sent, it will be +received correctly by those within the transmission radius of the +sender. + +a. Suppose now that an omniscient controller (i.e., a controller that + knows the state of every node in the network) can command each node + to do whatever it (the omniscient controller) wishes, i.e., to send + a message, to receive a message, or to remain silent. Given this + omniscient controller, what is the maximum rate at which a data + message can be transferred from C to A, given that there are no + other messages between any other source/destination pairs? + +b. Suppose now that A sends messages to B, and D sends messages to C. + What is the combined maximum rate at which data messages can flow + from A to B and from D to C? + +c. Suppose now that A sends messages to B, and C sends messages to D. + What is the combined maximum rate at which data messages can flow + from A to B and from C to D? + +d. Suppose now that the wireless links are replaced by wired links. + Repeat questions (a) through (c) again in this wired scenario. + +e. Now suppose we are again in the wireless scenario, and that for + every data message sent from source to destination, the destination + will send an ACK message back to the source (e.g., as in TCP). Also + suppose that each ACK message takes up one slot. Repeat questions + (a)--(c) above for this scenario. P9. Describe the format of the + 802.15.1 Bluetooth frame. You will have to do some reading outside + of the text to find this information. Is there anything in the frame + format that inherently limits the number of active nodes in an + 802.15.1 network to eight active nodes? Explain. P10. Consider the + following idealized LTE scenario. The downstream channel (see Figure + 7.21 ) is slotted in time, across F frequencies. There are four + nodes, A, B, C, and D, reachable from the base station at rates of + 10 Mbps, 5 Mbps, 2.5 Mbps, and 1 Mbps, respectively, on the + downstream channel. These rates assume that the base station + utilizes all time slots available on all F frequencies to send to + just one station. The base station has an infinite amount of data to + send to each of the nodes, and can send to any one of these four + nodes using any of the F frequencies during any time slot in the + downstream sub-frame. + +f. What is the maximum rate at which the base station can send to the + nodes, assuming it + + can send to any node it chooses during each time slot? Is your solution +fair? Explain and define what you mean by "fair." + +b. If there is a fairness requirement that each node must receive an + equal amount of data during each one second interval, what is the + average transmission rate by the base station (to all nodes) during + the downstream sub-frame? Explain how you arrived at your answer. + +c. Suppose that the fairness criterion is that any node can receive at + most twice as much data as any other node during the sub-frame. What + is the average transmission rate by the base station (to all nodes) + during the sub-frame? Explain how you arrived at your answer. P11. + In Section 7.5 , one proposed solution that allowed mobile users to + maintain their IP addresses as they moved among foreign networks was + to have a foreign network advertise a highly specific route to the + mobile user and use the existing routing infrastructure to propagate + this information throughout the network. We identified scalability + as one concern. Suppose that when a mobile user moves from one + network to another, the new foreign network advertises a specific + route to the mobile user, and the old foreign network withdraws its + route. Consider how routing information propagates in a + distance-vector algorithm (particularly for the case of interdomain + routing among networks that span the globe). + +d. Will other routers be able to route datagrams immediately to the new + foreign network as soon as the foreign network begins advertising + its route? + +e. Is it possible for different routers to believe that different + foreign networks contain the mobile user? + +f. Discuss the timescale over which other routers in the network will + eventually learn the path to the mobile users. P12. Suppose the + correspondent in Figure 7.23 were mobile. Sketch the additional + networklayer infrastructure that would be needed to route the + datagram from the original mobile user to the (now mobile) + correspondent. Show the structure of the datagram(s) between the + original mobile user and the (now mobile) correspondent, as in + Figure 7.24 . P13. In mobile IP, what effect will mobility have on + end-to-end delays of datagrams between the source and destination? + P14. Consider the chaining example discussed at the end of Section + 7.7.2 . Suppose a mobile user visits foreign networks A, B, and C, + and that a correspondent begins a connection to the mobile user when + it is resident in foreign network A. List the sequence of messages + between foreign agents, and between foreign agents and the home + agent as the mobile user moves from network A to network B to + network C. Next, suppose chaining is not performed, and the + correspondent (as well as the home agent) must be explicitly + notified of the changes in the mobile user's care-of address. List + the sequence of messages that would need to be exchanged in this + second scenario. + + P15. Consider two mobile nodes in a foreign network having a foreign +agent. Is it possible for the two mobile nodes to use the same care-of +address in mobile IP? Explain your answer. P16. In our discussion of how +the VLR updated the HLR with information about the mobile's current +location, what are the advantages and disadvantages of providing the +MSRN as opposed to the address of the VLR to the HLR? + +Wireshark Lab At the Web site for this textbook, +www.pearsonhighered.com/cs-resources, you'll find a Wireshark lab for +this chapter that captures and studies the 802.11 frames exchanged +between a wireless laptop and an access point. + +AN INTERVIEW WITH... Deborah Estrin Deborah Estrin is a Professor of +Computer Science at Cornell Tech in New York City and a Professor of +Public Health at Weill Cornell Medical College. She is founder of the +Health Tech Hub at Cornell Tech and co-founder of the non-profit startup +Open mHealth. She received her Ph.D. (1985) in Computer Science from +M.I.T. and her B.S. (1980) from UC Berkeley. Estrin's early research +focused on the design of network protocols, including multicast and +inter-domain routing. In 2002 Estrin founded the NSF-funded Science and +Technology Center at UCLA, Center for Embedded Networked Sensing (CENS +http://cens.ucla.edu.). CENS launched new areas of multi-disciplinary +computer systems research from sensor networks for environmental +monitoring, to participatory sensing for citizen science. Her current +focus is on mobile health and small data, leveraging the pervasiveness +of mobile devices and digital interactions for health and life +management, as described in her 2013 TEDMED talk. Professor Estrin is an +elected member of the American Academy of Arts and Sciences (2007) and +the National Academy of Engineering (2009). She is a fellow of the IEEE, +ACM, and AAAS. She was selected as the first ACM-W Athena Lecturer +(2006), awarded the Anita Borg Institute's Women of Vision Award for +Innovation (2007), inducted into the WITI hall of fame (2008) and +awarded Doctor Honoris Causa from EPFL (2008) and Uppsala University +(2011). + + Please describe a few of the most exciting projects you have worked on +during your career. What were the biggest challenges? In the mid-90s at +USC and ISI, I had the great fortune to work with the likes of Steve +Deering, Mark Handley, and Van Jacobson on the design of multicast +routing protocols (in particular, PIM). I tried to carry many of the +architectural design lessons from multicast into the design of +ecological monitoring arrays, where for the first time I really began to +take applications and multidisciplinary research seriously. That +interest in jointly innovating in the social and technological space is +what interests me so much about my latest area of research, mobile +health. The challenges in these projects were as diverse as the problem +domains, but what they all had in common was the need to keep our eyes +open to whether we had the problem definition right as we iterated +between design and deployment, prototype and pilot. None of them were +problems that could be solved analytically, with simulation or even in +constructed laboratory experiments. They all challenged our ability to +retain clean architectures in the presence of messy problems and +contexts, and they all called for extensive collaboration. What changes +and innovations do you see happening in wireless networks and mobility +in the future? In a prior edition of this interview I said that I have +never put much faith into predicting the future, but I did go on to +speculate that we might see the end of feature phones (i.e., those that +are not programmable and are used only for voice and text messaging) as +smart phones become more and more powerful and the primary point of +Internet access for many---and now not so many years later that is +clearly the case. I also predicted that we would see the continued +proliferation of embedded SIMs by which all sorts of devices have the +ability to communicate via the cellular network at low data rates. While +that has occurred, we see many devices and "Internet of Things" that use +embedded WiFi and other lower power, shorter range, forms of +connectivity to local hubs. I did not anticipate at that time the +emergence of a large consumer wearables market. By the time the next +edition is published I expect broad proliferation of personal +applications that leverage data from IoT and other digital traces. Where +do you see the future of networking and the Internet? Again I think its +useful to look both back and forward. Previously I observed that the +efforts in named data and software-defined networking would emerge to +create a more manageable, evolvable, and richer infrastructure and more +generally represent moving the role of architecture higher up in the +stack. In the beginnings of the Internet, architecture was layer 4 and +below, with + + applications being more siloed/monolithic, sitting on top. Now data and +analytics dominate transport. The adoption of SDN (which I'm really +happy to see is featured in this 7th edition of this book) has been well +beyond what I ever anticipated. However, looking up the stack, our +dominant applications increasingly live in walled gardens, whether +mobile apps or large consumer platforms such as Facebook. As Data +Science and Big Data techniques develop, they might help to lure these +applications out of their silos because of the value in connecting with +other apps and platforms. What people inspired you professionally? There +are three people who come to mind. First, Dave Clark, the secret sauce +and under-sung hero of the Internet community. I was lucky to be around +in the early days to see him act as the "organizing principle" of the +IAB and Internet governance; the priest of rough consensus and running +code. Second, Scott Shenker, for his intellectual brilliance, integrity, +and persistence. I strive for, but rarely attain, his clarity in +defining problems and solutions. He is always the first person I e-mail +for advice on matters large and small. Third, my sister Judy Estrin, who +had the creativity and courage to spend her career bringing ideas and +concepts to market. Without the Judys of the world the Internet +technologies would never have transformed our lives. What are your +recommendations for students who want careers in computer science and +networking? First, build a strong foundation in your academic work, +balanced with any and every real-world work experience you can get. As +you look for a working environment, seek opportunities in problem areas +you really care about and with smart teams that you can learn from. + + Chapter 8 Security in Computer Networks + +Way back in Section 1.6 we described some of the more prevalent and +damaging classes of Internet attacks, including malware attacks, denial +of service, sniffing, source masquerading, and message modification and +deletion. Although we have since learned a tremendous amount about +computer networks, we still haven't examined how to secure networks from +those attacks. Equipped with our newly acquired expertise in computer +networking and Internet protocols, we'll now study in-depth secure +communication and, in particular, how computer networks can be defended +from those nasty bad guys. Let us introduce Alice and Bob, two people +who want to communicate and wish to do so "securely." This being a +networking text, we should remark that Alice and Bob could be two +routers that want to exchange routing tables securely, a client and +server that want to establish a secure transport connection, or two +e-mail applications that want to exchange secure e-mail---all case +studies that we will consider later in this chapter. Alice and Bob are +well-known fixtures in the security community, perhaps because their +names are more fun than a generic entity named "A" that wants to +communicate securely with a generic entity named "B." Love affairs, +wartime communication, and business transactions are the commonly cited +human needs for secure communications; preferring the first to the +latter two, we're happy to use Alice and Bob as our sender and receiver, +and imagine them in this first scenario. We said that Alice and Bob want +to communicate and wish to do so "securely," but what precisely does +this mean? As we will see, security (like love) is a many-splendored +thing; that is, there are many facets to security. Certainly, Alice and +Bob would like for the contents of their communication to remain secret +from an eavesdropper. They probably would also like to make sure that +when they are communicating, they are indeed communicating with each +other, and that if their communication is tampered with by an +eavesdropper, that this tampering is detected. In the first part of this +chapter, we'll cover the fundamental cryptography techniques that allow +for encrypting communication, authenticating the party with whom one is +communicating, and ensuring message integrity. In the second part of +this chapter, we'll examine how the fundamental cryptography principles +can be used to create secure networking protocols. Once again taking a +top-down approach, we'll examine secure protocols in each of the (top +four) layers, beginning with the application layer. We'll examine how to +secure e-mail, how to secure a TCP connection, how to provide blanket +security at the network layer, and how to secure a wireless LAN. In the +third part of this chapter we'll consider operational security, + + which is about protecting organizational networks from attacks. In +particular, we'll take a careful look at how firewalls and intrusion +detection systems can enhance the security of an organizational network. + + 8.1 What Is Network Security? Let's begin our study of network security +by returning to our lovers, Alice and Bob, who want to communicate +"securely." What precisely does this mean? Certainly, Alice wants only +Bob to be able to understand a message that she has sent, even though +they are communicating over an insecure medium where an intruder (Trudy, +the intruder) may intercept whatever is transmitted from Alice to Bob. +Bob also wants to be sure that the message he receives from Alice was +indeed sent by Alice, and Alice wants to make sure that the person with +whom she is communicating is indeed Bob. Alice and Bob also want to make +sure that the contents of their messages have not been altered in +transit. They also want to be assured that they can communicate in the +first place (i.e., that no one denies them access to the resources +needed to communicate). Given these considerations, we can identify the +following desirable properties of secure communication. Confidentiality. +Only the sender and intended receiver should be able to understand the +contents of the transmitted message. Because eavesdroppers may intercept +the message, this necessarily requires that the message be somehow +encrypted so that an intercepted message cannot be understood by an +interceptor. This aspect of confidentiality is probably the most +commonly perceived meaning of the term secure communication. We'll study +cryptographic techniques for encrypting and decrypting data in Section +8.2. Message integrity. Alice and Bob want to ensure that the content of +their communication is not altered, either maliciously or by accident, +in transit. Extensions to the checksumming techniques that we +encountered in reliable transport and data link protocols can be used to +provide such message integrity. We will study message integrity in +Section 8.3. End-point authentication. Both the sender and receiver +should be able to confirm the identity of the other party involved in +the communication---to confirm that the other party is indeed who or +what they claim to be. Face-to-face human communication solves this +problem easily by visual recognition. When communicating entities +exchange messages over a medium where they cannot see the other party, +authentication is not so simple. When a user wants to access an inbox, +how does the mail server verify that the user is the person he or she +claims to be? We study end-point authentication in Section 8.4. +Operational security. Almost all organizations (companies, universities, +and so on) today have networks that are attached to the public Internet. +These networks therefore can potentially be compromised. Attackers can +attempt to deposit worms into the hosts in the network, obtain corporate +secrets, map the internal network configurations, and launch DoS +attacks. We'll see in Section 8.9 that operational devices such as +firewalls and intrusion detection systems are used to counter attacks +against an organization's network. A firewall sits between the +organization's network and the public network, controlling packet access +to and from the network. An intrusion detection + + system performs "deep packet inspection," alerting the network +administrators about suspicious activity. Having established what we +mean by network security, let's next consider exactly what information +an intruder may have access to, and what actions can be taken by the +intruder. Figure 8.1 illustrates the scenario. Alice, the sender, wants +to send data to Bob, the receiver. In order to exchange data securely, +while meeting the requirements of confidentiality, end-point +authentication, and message integrity, Alice and Bob will exchange +control messages and data messages (in much the same way that TCP +senders and receivers exchange control segments and data segments). + +Figure 8.1 Sender, receiver, and intruder (Alice, Bob, and Trudy) + +All or some of these messages will typically be encrypted. As discussed +in Section 1.6, an intruder can potentially perform +eavesdropping---sniffing and recording control and data messages on the +channel. modification, insertion, or deletion of messages or message +content. As we'll see, unless appropriate countermeasures are taken, +these capabilities allow an intruder to mount a wide variety of security +attacks: snooping on communication (possibly stealing passwords and +data), impersonating another entity, hijacking an ongoing session, +denying service to legitimate network users by overloading system +resources, and so on. A summary of reported attacks is maintained at the +CERT Coordination Center \[CERT 2016\]. Having established that there +are indeed real threats loose in the Internet, what are the Internet +equivalents of Alice and Bob, our friends who need to communicate +securely? Certainly, Bob and Alice might be human users at two end +systems, for example, a real Alice and a real Bob who really do want to +exchange secure e-mail. They might also be participants in an electronic +commerce transaction. For example, a real Bob might want to transfer his +credit card number securely to a Web server to purchase + + an item online. Similarly, a real Alice might want to interact with her +bank online. The parties needing secure communication might themselves +also be part of the network infrastructure. Recall that the domain name +system (DNS, see Section 2.4) or routing daemons that exchange routing +information (see Chapter 5) require secure communication between two +parties. The same is true for network management applications, a topic +we examined in Chapter 5). An intruder that could actively interfere +with DNS lookups (as discussed in Section 2.4), routing computations +\[RFC 4272\], or network management functions \[RFC 3414\] could wreak +havoc in the Internet. Having now established the framework, a few of +the most important definitions, and the need for network security, let +us next delve into cryptography. While the use of cryptography in +providing confidentiality is self-evident, we'll see shortly that it is +also central to providing end-point authentication and message +integrity---making cryptography a cornerstone of network security. + + 8.2 Principles of Cryptography Although cryptography has a long history +dating back at least as far as Julius Caesar, modern cryptographic +techniques, including many of those used in the Internet, are based on +advances made in the past 30 years. Kahn's book, The Codebreakers \[Kahn +1967\], and Singh's book, The Code Book: The Science of Secrecy from +Ancient Egypt to Quantum Cryptography \[Singh 1999\], provide a +fascinating look at the + +Figure 8.2 Cryptographic components + +long history of cryptography. A complete discussion of cryptography +itself requires a complete book \[Kaufman 1995; Schneier 1995\] and so +we only touch on the essential aspects of cryptography, particularly as +they are practiced on the Internet. We also note that while our focus in +this section will be on the use of cryptography for confidentiality, +we'll see shortly that cryptographic techniques are inextricably woven +into authentication, message integrity, nonrepudiation, and more. +Cryptographic techniques allow a sender to disguise data so that an +intruder can gain no information from the intercepted data. The +receiver, of course, must be able to recover the original data from the +disguised data. Figure 8.2 illustrates some of the important +terminology. Suppose now that Alice wants to send a message to Bob. +Alice's message in its original form (for example, " Bob, I love you. +Alice ") is known as plaintext, or cleartext. Alice encrypts her +plaintext message using an encryption algorithm so that the encrypted +message, known as ciphertext, looks unintelligible to any intruder. +Interestingly, in many modern cryptographic systems, + + including those used in the Internet, the encryption technique itself is +known---published, standardized, and available to everyone (for example, +\[RFC 1321; RFC 3447; RFC 2420; NIST 2001\]), even a potential intruder! +Clearly, if everyone knows the method for encoding data, then there must +be some secret information that prevents an intruder from decrypting the +transmitted data. This is where keys come in. In Figure 8.2, Alice +provides a key, KA, a string of numbers or characters, as input to the +encryption algorithm. The encryption algorithm takes the key and the +plaintext message, m, as input and produces ciphertext as output. The +notation KA(m) refers to the ciphertext form (encrypted using the key +KA) of the plaintext message, m. The actual encryption algorithm that +uses key KA will be evident from the context. Similarly, Bob will +provide a key, KB, to the decryption algorithm that takes the ciphertext +and Bob's key as input and produces the original plaintext as output. +That is, if Bob receives an encrypted message KA(m), he decrypts it by +computing KB(KA(m))=m. In symmetric key systems, Alice's and Bob's keys +are identical and are secret. In public key systems, a pair of keys is +used. One of the keys is known to both Bob and Alice (indeed, it is +known to the whole world). The other key is known only by either Bob or +Alice (but not both). In the following two subsections, we consider +symmetric key and public key systems in more detail. + +8.2.1 Symmetric Key Cryptography All cryptographic algorithms involve +substituting one thing for another, for example, taking a piece of +plaintext and then computing and substituting the appropriate ciphertext +to create the encrypted message. Before studying a modern key-based +cryptographic system, let us first get our feet wet by studying a very +old, very simple symmetric key algorithm attributed to Julius Caesar, +known as the Caesar cipher (a cipher is a method for encrypting data). +For English text, the Caesar cipher would work by taking each letter in +the plaintext message and substituting the letter that is k letters +later (allowing wraparound; that is, having the letter z followed by the +letter a) in the alphabet. For example if k=3, then the letter a in +plaintext becomes d in ciphertext; b in plaintext becomes e in +ciphertext, and so on. Here, the value of k serves as the key. As an +example, the plaintext message " bob, i love you. Alice " becomes " ere, +l oryh brx. dolfh " in ciphertext. While the ciphertext does indeed look +like gibberish, it wouldn't take long to break the code if you knew that +the Caesar cipher was being used, as there are only 25 possible key +values. An improvement on the Caesar cipher is the monoalphabetic +cipher, which also substitutes one letter of the alphabet with another +letter of the alphabet. However, rather than substituting according to a +regular pattern (for example, substitution with an offset of k for all +letters), any letter can be substituted for any other letter, as long as +each letter has a unique substitute letter, and vice versa. The +substitution + + rule in Figure 8.3 shows one possible rule for encoding plaintext. The +plaintext message " bob, i love you. Alice " becomes "nkn, s gktc wky. +Mgsbc." Thus, as in the case of the Caesar cipher, this looks like +gibberish. A monoalphabetic cipher would also appear to be better than +the Caesar cipher in that there are 26! (on the order of 1026) possible +pairings of letters rather than 25 possible pairings. A brute-force +approach of trying all 1026 possible pairings + +Figure 8.3 A monoalphabetic cipher + +would require far too much work to be a feasible way of breaking the +encryption algorithm and decoding the message. However, by statistical +analysis of the plaintext language, for example, knowing that the +letters e and t are the most frequently occurring letters in typical +English text (accounting for 13 percent and 9 percent of letter +occurrences), and knowing that particular two-and three-letter +occurrences of letters appear quite often together (for example, "in," +"it," "the," "ion," "ing," and so forth) make it relatively easy to +break this code. If the intruder has some knowledge about the possible +contents of the message, then it is even easier to break the code. For +example, if Trudy the intruder is Bob's wife and suspects Bob of having +an affair with Alice, then she might suspect that the names "bob" and +"alice" appear in the text. If Trudy knew for certain that those two +names appeared in the ciphertext and had a copy of the example +ciphertext message above, then she could immediately determine seven of +the 26 letter pairings, requiring 109 fewer possibilities to be checked +by a brute-force method. Indeed, if Trudy suspected Bob of having an +affair, she might well expect to find some other choice words in the +message as well. When considering how easy it might be for Trudy to +break Bob and Alice's encryption scheme, one can distinguish three +different scenarios, depending on what information the intruder has. +Ciphertext-only attack. In some cases, the intruder may have access only +to the intercepted ciphertext, with no certain information about the +contents of the plaintext message. We have seen how statistical analysis +can help in a ciphertext-only attack on an encryption scheme. +Known-plaintext attack. We saw above that if Trudy somehow knew for sure +that "bob" and "alice" appeared in the ciphertext message, then she +could have determined the (plaintext, ciphertext) pairings for the +letters a, l, i, c, e, b, and o. Trudy might also have been fortunate +enough to have recorded all of the ciphertext transmissions and then +found Bob's own decrypted version of one of the transmissions scribbled +on a piece of paper. When an intruder knows some of the (plaintext, +ciphertext) pairings, we refer to this as a known-plaintext attack on +the encryption scheme. Chosen-plaintext attack. In a chosen-plaintext +attack, the intruder is able to choose the plaintext + + message and obtain its corresponding ciphertext form. For the simple +encryption algorithms we've seen so far, if Trudy could get Alice to +send the message, " The quick brown fox jumps over the lazy dog, " she +could completely break the encryption scheme. We'll see shortly that for +more sophisticated encryption techniques, a chosen-plaintext attack does +not necessarily mean that the encryption technique can be broken. Five +hundred years ago, techniques improving on monoalphabetic encryption, +known as polyalphabetic encryption, were invented. The idea behind +polyalphabetic encryption is to use multiple monoalphabetic ciphers, +with a specific + +Figure 8.4 A polyalphabetic cipher using two Caesar ciphers + +monoalphabetic cipher to encode a letter in a specific position in the +plaintext message. Thus, the same letter, appearing in different +positions in the plaintext message, might be encoded differently. An +example of a polyalphabetic encryption scheme is shown in Figure 8.4. It +has two Caesar ciphers (with k=5 and k=19), shown as rows. We might +choose to use these two Caesar ciphers, C1 and C2, in the repeating +pattern C1, C2, C2, C1, C2. That is, the first letter of plaintext is to +be encoded using C1, the second and third using C2, the fourth using C1, +and the fifth using C2. The pattern then repeats, with the sixth letter +being encoded using C1, the seventh with C2, and so on. The plaintext +message " bob, i love you. " is thus encrypted " ghu, n etox dhz. " Note +that the first b in the plaintext message is encrypted using C1, while +the second b is encrypted using C2. In this example, the encryption and +decryption "key" is the knowledge of the two Caesar keys (k=5, k=19) and +the pattern C1, C2, C2, C1, C2. Block Ciphers Let us now move forward to +modern times and examine how symmetric key encryption is done today. +There are two broad classes of symmetric encryption techniques: stream +ciphers and block ciphers. We'll briefly examine stream ciphers in +Section 8.7 when we investigate security for wireless LANs. In this +section, we focus on block ciphers, which are used in many secure +Internet protocols, including PGP (for secure e-mail), SSL (for securing +TCP connections), and IPsec (for securing the network-layer transport). +In a block cipher, the message to be encrypted is processed in blocks of +k bits. For example, if k=64, then the message is broken into 64-bit +blocks, and each block is encrypted independently. To encode a block, +the cipher uses a one-to-one mapping to map the k-bit block of cleartext +to a k-bit block of + + ciphertext. Let's look at an example. Suppose that k=3, so that the +block cipher maps 3-bit inputs (cleartext) to 3-bit outputs +(ciphertext). One possible mapping is given in Table 8.1. Notice that +this is a one-to-one mapping; that is, there is a different output for +each input. This block cipher breaks the message up into 3-bit blocks +and encrypts each block according to the above mapping. You should +verify that the message 010110001111 gets encrypted into 101000111001. +Continuing with this 3-bit block example, note that the mapping in Table +8.1 is just one mapping of many possible mappings. How many possible +mappings are Table 8.1 A specific 3-bit block cipher input + +output + +input + +output + +000 + +110 + +100 + +011 + +001 + +111 + +101 + +010 + +010 + +101 + +110 + +000 + +011 + +100 + +111 + +001 + +there? To answer this question, observe that a mapping is nothing more +than a permutation of all the possible inputs. There are 23(=8) possible +inputs (listed under the input columns). These eight inputs can be +permuted in 8!=40,320 different ways. Since each of these permutations +specifies a mapping, there are 40,320 possible mappings. We can view +each of these mappings as a key---if Alice and Bob both know the mapping +(the key), they can encrypt and decrypt the messages sent between them. +The brute-force attack for this cipher is to try to decrypt ciphtertext +by using all mappings. With only 40,320 mappings (when k=3), this can +quickly be accomplished on a desktop PC. To thwart brute-force attacks, +block ciphers typically use much larger blocks, consisting of k=64 bits +or even larger. Note that the number of possible mappings for a general +k-block cipher is 2k!, which is astronomical for even moderate values of +k (such as k=64). Although full-table block ciphers, as just described, +with moderate values of k can produce robust symmetric key encryption +schemes, they are unfortunately difficult to implement. For k=64 and for +a given mapping, Alice and Bob would need to maintain a table with 264 +input values, which is an infeasible task. Moreover, if Alice and Bob +were to change keys, they would have to each regenerate the table. Thus, +a full-table block cipher, providing predetermined mappings between all +inputs and outputs (as in the example above), is simply out of the +question. + + Instead, block ciphers typically use functions that simulate randomly +permuted tables. An example (adapted from \[Kaufman 1995\]) of such a +function for k=64 bits is shown in Figure 8.5. The function first breaks +a 64-bit block into 8 chunks, with each chunk consisting of 8 bits. Each +8-bit chunk is processed by an 8-bit to 8-bit table, which is of +manageable size. For example, the first chunk is processed by the table +denoted by T1. Next, the 8 output chunks are reassembled into a 64-bit +block. The positions of the 64 bits in the block are then scrambled +(permuted) to produce a 64-bit output. This output is fed back to the +64-bit input, where another cycle begins. After n such cycles, the +function provides a 64-bit block of ciphertext. The purpose of the +rounds is to make each input bit affect most (if not all) of the final +output bits. (If only one round were used, a given input bit would +affect only 8 of the 64 output bits.) The key for this block cipher +algorithm would be the eight permutation tables (assuming the scramble +function is publicly known). + +Figure 8.5 An example of a block cipher + +Today there are a number of popular block ciphers, including DES +(standing for Data Encryption Standard), 3DES, and AES (standing for +Advanced Encryption Standard). Each of these standards uses functions, +rather than predetermined tables, along the lines of Figure 8.5 (albeit +more complicated and specific to each cipher). Each of these algorithms +also uses a string of bits for a key. For example, DES uses 64-bit +blocks with a 56-bit key. AES uses 128-bit blocks and can operate with +keys that are 128, 192, and 256 bits long. An algorithm's key determines +the specific "mini-table" mappings and permutations within the +algorithm's internals. The brute-force attack for each of these ciphers +is to cycle through all the keys, applying the decryption algorithm with +each key. Observe that with a key length of n, there are 2n possible +keys. NIST \[NIST 2001\] estimates that a machine that could crack +56-bit DES in one second (that is, try all 256 keys in one second) would +take approximately 149 trillion years to crack a 128-bit AES key. + + Cipher-Block Chaining In computer networking applications, we typically +need to encrypt long messages (or long streams of data). If we apply a +block cipher as described by simply chopping up the message into k-bit +blocks and independently encrypting each block, a subtle but important +problem occurs. To see this, observe that two or more of the cleartext +blocks can be identical. For example, the cleartext in two or more +blocks could be "HTTP/1.1". For these identical blocks, a block cipher +would, of course, produce the same ciphertext. An attacker could +potentially guess the cleartext when it sees identical ciphertext blocks +and may even be able to decrypt the entire message by identifying +identical ciphtertext blocks and using knowledge about the underlying +protocol structure \[Kaufman 1995\]. To address this problem, we can mix +some randomness into the ciphertext so that identical plaintext blocks +produce different ciphertext blocks. To explain this idea, let m(i) +denote the ith plaintext block, c(i) denote the ith ciphertext block, +and a⊕b denote the exclusive-or (XOR) of two bit strings, a and b. +(Recall that the 0⊕0=1⊕1=0 and 0⊕1=1⊕0=1, and the XOR of two bit strings +is done on a bit-by-bit basis. So, for example, +10101010⊕11110000=01011010.) Also, denote the block-cipher encryption +algorithm with key S as KS. The basic idea is as follows. The sender +creates a random k-bit number r(i) for the ith block and calculates +c(i)=KS(m(i)⊕r(i)). Note that a new k-bit random number is chosen for +each block. The sender then sends c(1), r(1), c(2), r(2), c(3), r(3), +and so on. Since the receiver receives c(i) and r(i), it can recover +each block of the plaintext by computing m(i)=KS(c(i))⊕r(i). It is +important to note that, although r(i) is sent in the clear and thus can +be sniffed by Trudy, she cannot obtain the plaintext m(i), since she +does not know the key KS. Also note that if two plaintext blocks m(i) +and m(j) are the same, the corresponding ciphertext blocks c(i) and c(j) +will be different (as long as the random numbers r(i) and r(j) are +different, which occurs with very high probability). As an example, +consider the 3-bit block cipher in Table 8.1. Suppose the plaintext is +010010010. If Alice encrypts this directly, without including the +randomness, the resulting ciphertext becomes 101101101. If Trudy sniffs +this ciphertext, because each of the three cipher blocks is the same, +she can correctly surmise that each of the three plaintext blocks are +the same. Now suppose instead Alice generates the random blocks +r(1)=001, r(2)=111, and r(3)=100 and uses the above technique to +generate the ciphertext c(1)=100, c(2)=010, and c(3)=000. Note that the +three ciphertext blocks are different even though the plaintext blocks +are the same. Alice then sends c(1), r(1), c(2), and r(2). You should +verify that Bob can obtain the original plaintext using the shared key +KS. The astute reader will note that introducing randomness solves one +problem but creates another: namely, Alice must transmit twice as many +bits as before. Indeed, for each cipher bit, she must now also send a +random bit, doubling the required bandwidth. In order to have our cake +and eat it too, block ciphers typically use a technique called Cipher +Block Chaining (CBC). The basic idea is to send only one random value +along with the very first message, and then have the sender and receiver +use the + + computed coded blocks in place of the subsequent random number. +Specifically, CBC operates as follows: + +1. Before encrypting the message (or the stream of data), the sender + generates a random k-bit string, called the Initialization Vector + (IV). Denote this initialization vector by c(0). The sender sends + the IV to the receiver in cleartext. + +2. For the first block, the sender calculates m(1)⊕c(0), that is, + calculates the exclusive-or of the first block of cleartext with + the IV. It then runs the result through the block-cipher algorithm + to get the corresponding ciphertext block; that is, + c(1)=KS(m(1)⊕c(0)). The sender sends the encrypted block c(1) to the + receiver. + +3. For the ith block, the sender generates the ith ciphertext block + from c(i)= KS(m(i)⊕c(i−1)). Let's now examine some of the + consequences of this approach. First, the receiver will still be + able to recover the original message. Indeed, when the receiver + receives c(i), it decrypts it with KS to obtain s(i)=m(i)⊕c(i−1); + since the receiver also knows c(i−1), it then obtains the cleartext + block from m(i)=s(i)⊕c(i−1). Second, even if two cleartext blocks + are identical, the corresponding ciphtertexts (almost always) will + be different. Third, although the sender sends the IV in the clear, + an intruder will still not be able to decrypt the ciphertext blocks, + since the intruder does not know the secret key, S. Finally, the + sender only sends one overhead block (the IV), thereby negligibly + increasing the bandwidth usage for long messages (consisting of + hundreds of blocks). As an example, let's now determine the + ciphertext for the 3-bit block cipher in Table 8.1 with plaintext + 010010010 and IV=c(0)=001. The sender first uses the IV to calculate + c(1)=KS(m(1)⊕c(0))=100. The sender then calculates c(2)= + KS(m(2)⊕c(1))=KS(010⊕100)=000, and C(3)=KS(m(3)⊕c(2))=KS(010⊕ + 000)=101. The reader should verify that the receiver, knowing the IV + and KS can recover the original plaintext. CBC has an important + consequence when designing secure network protocols: we'll need to + provide a mechanism within the protocol to distribute the IV from + sender to receiver. We'll see how this is done for several protocols + later in this chapter. + +8.2.2 Public Key Encryption For more than 2,000 years (since the time of +the Caesar cipher and up to the 1970s), encrypted communication required +that the two communicating parties share a common secret---the symmetric +key used for encryption and decryption. One difficulty with this +approach is that the two parties must somehow agree on the shared key; +but to do so requires (presumably secure) communication! Perhaps the +parties could first meet and agree on the key in person (for example, +two of Caesar's centurions might meet at the Roman baths) and thereafter +communicate with encryption. In a networked world, + + however, communicating parties may never meet and may never converse +except over the network. Is it possible for two parties to communicate +with encryption without having a shared secret key that is known in +advance? In 1976, Diffie and Hellman \[Diffie 1976\] demonstrated an +algorithm (known now as Diffie-Hellman Key Exchange) to do just that---a +radically different and marvelously elegant approach toward secure +communication that has led to the development of today's public key +cryptography systems. We'll see shortly that public key cryptography +systems also have several wonderful properties that make them useful not +only + +Figure 8.6 Public key cryptography + +for encryption, but for authentication and digital signatures as well. +Interestingly, it has recently come to light that ideas similar to those +in \[Diffie 1976\] and \[RSA 1978\] had been independently developed in +the early 1970s in a series of secret reports by researchers at the +Communications-Electronics Security Group in the United Kingdom \[Ellis +1987\]. As is often the case, great ideas can spring up independently in +many places; fortunately, public key advances took place not only in +private, but also in the public view, as well. The use of public key +cryptography is conceptually quite simple. Suppose Alice wants to +communicate with Bob. As shown in Figure 8.6, rather than Bob and Alice +sharing a single secret key (as in the case of symmetric key systems), +Bob (the recipient of Alice's messages) instead has two keys---a public +key that is available to everyone in the world (including Trudy the +intruder) and a private key that is known only to Bob. We will use the +notation KB+ and KB− to refer to Bob's public and private keys, +respectively. In order to communicate with Bob, Alice first fetches +Bob's public key. Alice then encrypts her message, m, to Bob using Bob's +public key and a known (for example, standardized) encryption algorithm; +that is, Alice computes KB−(m). Bob receives Alice's encrypted message +and uses his private key and a known (for example, standardized) +decryption algorithm to decrypt Alice's encrypted message. That is, Bob +computes KB−(KB+(m)). We will see below that there are +encryption/decryption + + algorithms and techniques for choosing public and private keys such that +KB−(KB+(m))=m; that is, applying Bob's public key, KB+, to a message, m +(to get KB−(m)), and then applying Bob's private key, KB−, to the +encrypted version of m (that is, computing KB−(KB+(m))) gives back m. +This is a remarkable result! In this manner, Alice can use Bob's +publicly available key to send a secret message to Bob without either of +them having to distribute any secret keys! We will see shortly that we +can interchange the public key and private key encryption and get the +same remarkable result----that is, KB−(B+(m))=KB+(KB−(m))=m. The use of +public key cryptography is thus conceptually simple. But two immediate +worries may spring to mind. A first concern is that although an intruder +intercepting Alice's encrypted message will see only gibberish, the +intruder knows both the key (Bob's public key, which is available for +all the world to see) and the algorithm that Alice used for encryption. +Trudy can thus mount a chosen-plaintext attack, using the known +standardized encryption algorithm and Bob's publicly available +encryption key to encode any message she chooses! Trudy might well try, +for example, to encode messages, or parts of messages, that she suspects +that Alice might send. Clearly, if public key cryptography is to work, +key selection and encryption/decryption must be done in such a way that +it is impossible (or at least so hard as to be nearly impossible) for an +intruder to either determine Bob's private key or somehow otherwise +decrypt or guess Alice's message to Bob. A second concern is that since +Bob's encryption key is public, anyone can send an encrypted message to +Bob, including Alice or someone claiming to be Alice. In the case of a +single shared secret key, the fact that the sender knows the secret key +implicitly identifies the sender to the receiver. In the case of public +key cryptography, however, this is no longer the case since anyone can +send an encrypted message to Bob using Bob's publicly available key. A +digital signature, a topic we will study in Section 8.3, is needed to +bind a sender to a message. RSA While there may be many algorithms that +address these concerns, the RSA algorithm (named after its founders, Ron +Rivest, Adi Shamir, and Leonard Adleman) has become almost synonymous +with public key cryptography. Let's first see how RSA works and then +examine why it works. RSA makes extensive use of arithmetic operations +using modulo-n arithmetic. So let's briefly review modular arithmetic. +Recall that x mod n simply means the remainder of x when divided by n; +so, for example, 19 mod 5=4. In modular arithmetic, one performs the +usual operations of addition, multiplication, and exponentiation. +However, the result of each operation is replaced by the integer +remainder that is left when the result is divided by n. Adding and +multiplying with modular arithmetic is facilitated with the following +handy facts: \[ (a mod n)+(b mod n)\]mod n=(a+b)mod n\[ (a mod n)−(b mod +n)\]mod n=(a−b)mod n\[ (a mod n)⋅(b mod n)\]mod n=(a⋅b)mod n + + It follows from the third fact that (a mod n)d n=ad mod n, which is an +identity that we will soon find very useful. Now suppose that Alice +wants to send to Bob an RSA-encrypted message, as shown in Figure 8.6. +In our discussion of RSA, let's always keep in mind that a message is +nothing but a bit pattern, and every bit pattern can be uniquely +represented by an integer number (along with the length of the bit +pattern). For example, suppose a message is the bit pattern 1001; this +message can be represented by the decimal integer 9. Thus, when +encrypting a message with RSA, it is equivalent to encrypting the unique +integer number that represents the message. There are two interrelated +components of RSA: The choice of the public key and the private key The +encryption and decryption algorithm To generate the public and private +RSA keys, Bob performs the following steps: + +1. Choose two large prime numbers, p and q. How large should p and q + be? The larger the values, the more difficult it is to break RSA, + but the longer it takes to perform the encoding and decoding. RSA + Laboratories recommends that the product of p and q be on the order + of 1,024 bits. For a discussion of how to find large prime numbers, + see \[Caldwell 2012\]. + +2. Compute n=pq and z=(p−1)(q−1). + +3. Choose a number, e, less than n, that has no common factors (other + than 1) with z. (In this case, e and z are said to be relatively + prime.) The letter e is used since this value will be used in + encryption. + +4. Find a number, d, such that ed−1 is exactly divisible (that is, with + no remainder) by z. The letter d is used because this value will be + used in decryption. Put another way, given e, we choose d such that + ed modz=1 + +5. The public key that Bob makes available to the world, KB+, is the + pair of numbers (n, e); his private key, KB−, is the pair of numbers + (n, d). The encryption by Alice and the decryption by Bob are done + as follows: Suppose Alice wants to send Bob a bit pattern + represented by the integer number m (with m\<n). To encode, Alice + performs the exponentiation me, and then computes the integer + remainder when me is divided by n. In other words, the encrypted + value, c, of Alice's plaintext message, m, is c=memod n + + The bit pattern corresponding to this ciphertext c is sent to Bob. To +decrypt the received ciphertext message, c, Bob computes m=cdmod n which +requires the use of his private key (n, d). Table 8.2 Alice's RSA +encryption, e=5, n=35 Plaintext Letter + +m: numeric representation + +me + +Ciphertext c=me mod n + +l + +12 + +248832 + +17 + +o + +15 + +759375 + +15 + +v + +22 + +5153632 + +22 + +e + +5 + +3125 + +10 + +As a simple example of RSA, suppose Bob chooses p=5 and q=7. +(Admittedly, these values are far too small to be secure.) Then n=35 and +z=24. Bob chooses e=5, since 5 and 24 have no common factors. Finally, +Bob chooses d=29, since 5⋅29−1 (that is, ed−1) is exactly divisible by +24. Bob makes the two values, n=35 and e=5, public and keeps the value +d=29 secret. Observing these two public values, suppose Alice now wants +to send the letters l, o, v, and e to Bob. Interpreting each letter as a +number between 1 and 26 (with a being 1, and z being 26), Alice and Bob +perform the encryption and decryption shown in Tables 8.2 and 8.3, +respectively. Note that in this example, we consider each of the four +letters as a distinct message. A more realistic example would be to +convert the four letters into their 8-bit ASCII representations and then +encrypt the integer corresponding to the resulting 32-bit bit pattern. +(Such a realistic example generates numbers that are much too long to +print in a textbook!) Given that the "toy" example in Tables 8.2 and 8.3 +has already produced some extremely large numbers, and given that we saw +earlier that p and q should each be several hundred bits long, several +practical issues regarding RSA come to mind. How does one choose large +prime numbers? How does one then choose e and d? How does one perform +exponentiation with large numbers? A discussion of these important +issues is beyond the scope of this book; see \[Kaufman 1995\] and the +references therein for details. Table 8.3 Bob's RSA decryption, d=29, +n=35 Ciphertext c + +cd + +m = cd mod n + +Plaintext Letter + + 17 + +4819685721067509150915091411825223071697 + +12 + +l + +15 + +127834039403948858939111232757568359375 + +15 + +o + +22 + +851643319086537701956194499721106030592 + +22 + +v + +10 + +1000000000000000000000000000000 + +5 + +e + +Session Keys We note here that the exponentiation required by RSA is a +rather time-consuming process. By contrast, DES is at least 100 times +faster in software and between 1,000 and 10,000 times faster in hardware +\[RSA Fast 2012\]. As a result, RSA is often used in practice in +combination with symmetric key cryptography. For example, if Alice wants +to send Bob a large amount of encrypted data, she could do the +following. First Alice chooses a key that will be used to encode the +data itself; this key is referred to as a session key, and is denoted by +KS. Alice must inform Bob of the session key, since this is the shared +symmetric key they will use with a symmetric key cipher (e.g., with DES +or AES). Alice encrypts the session key using Bob's public key, that is, +computes c=(KS)e mod n. Bob receives the RSA-encrypted session key, c, +and decrypts it to obtain the session key, KS. Bob now knows the session +key that Alice will use for her encrypted data transfer. Why Does RSA +Work? RSA encryption/decryption appears rather magical. Why should it be +that by applying the encryption algorithm and then the decryption +algorithm, one recovers the original message? In order to understand why +RSA works, again denote n=pq, where p and q are the large prime numbers +used in the RSA algorithm. Recall that, under RSA encryption, a message +(uniquely represented by an integer), m, is exponentiated to the power e +using modulo-n arithmetic, that is, c=memod n Decryption is performed by +raising this value to the power d, again using modulo-n arithmetic. The +result of an encryption step followed by a decryption step is thus (me +mod n)d mod n. Let's now see what we can say about this quantity. As +mentioned earlier, one important property of modulo arithmetic is (a mod +n)d mod n=ad mod n for any values a, n, and d. Thus, using a=me in this +property, we have (memod n)dmod n=medmod n + + It therefore remains to show that medmod n=m. Although we're trying to +remove some of the magic about why RSA works, to establish this, we'll +need to use a rather magical result from number theory here. +Specifically, we'll need the result that says if p and q are prime, +n=pq, and z=(p−1)(q−1), then xy mod n is the same as x(y mod z) mod n +\[Kaufman 1995\]. Applying this result with x=m and y=ed we have medmod +n=m(edmod z)mod n But remember that we have chosen e and d such that +edmod z=1. This gives us medmod n=m1mod n=m which is exactly the result +we are looking for! By first exponentiating to the power of e (that is, +encrypting) and then exponentiating to the power of d (that is, +decrypting), we obtain the original value, m. Even more wonderful is the +fact that if we first exponentiate to the power of d and then +exponentiate to the power of e---that is, we reverse the order of +encryption and decryption, performing the decryption operation first and +then applying the encryption operation---we also obtain the original +value, m. This wonderful result follows immediately from the modular +arithmetic: (mdmod n)emod n=mdemod n=medmod n=(memod n)dmod n The +security of RSA relies on the fact that there are no known algorithms +for quickly factoring a number, in this case the public value n, into +the primes p and q. If one knew p and q, then given the public value e, +one could easily compute the secret key, d. On the other hand, it is not +known whether or not there exist fast algorithms for factoring a number, +and in this sense, the security of RSA is not guaranteed. Another +popular public-key encryption algorithm is the Diffie-Hellman algorithm, +which we will briefly explore in the homework problems. Diffie-Hellman +is not as versatile as RSA in that it cannot be used to encrypt messages +of arbitrary length; it can be used, however, to establish a symmetric +session key, which is in turn used to encrypt messages. + + 8.3 Message Integrity and Digital Signatures In the previous section we +saw how encryption can be used to provide confidentiality to two +communicating entities. In this section we turn to the equally important +cryptography topic of providing message integrity (also known as message +authentication). Along with message integrity, we will discuss two +related topics in this section: digital signatures and end-point +authentication. We define the message integrity problem using, once +again, Alice and Bob. Suppose Bob receives a message (which may be +encrypted or may be in plaintext) and he believes this message was sent +by Alice. To authenticate this message, Bob needs to verify: + +1. The message indeed originated from Alice. +2. The message was not tampered with on its way to Bob. We'll see in + Sections 8.4 through 8.7 that this problem of message integrity is a + critical concern in just about all secure networking protocols. As a + specific example, consider a computer network using a link-state + routing algorithm (such as OSPF) for determining routes between each + pair of routers in the network (see Chapter 5). In a link-state + algorithm, each router needs to broadcast a link-state message to + all other routers in the network. A router's link-state message + includes a list of its directly connected neighbors and the direct + costs to these neighbors. Once a router receives link-state messages + from all of the other routers, it can create a complete map of the + network, run its least-cost routing algorithm, and configure its + forwarding table. One relatively easy attack on the routing + algorithm is for Trudy to distribute bogus link-state messages with + incorrect link-state information. Thus the need for message + integrity---when router B receives a linkstate message from router + A, router B should verify that router A actually created the message + and, further, that no one tampered with the message in transit. In + this section, we describe a popular message integrity technique that + is used by many secure networking protocols. But before doing so, we + need to cover another important topic in cryptography--- + cryptographic hash functions. + +8.3.1 Cryptographic Hash Functions As shown in Figure 8.7, a hash +function takes an input, m, and computes a fixed-size string H(m) + + known as a hash. The Internet checksum (Chapter 3) and CRCs (Chapter 6) +meet this definition. A cryptographic hash function is required to have +the following additional property: It is computationally infeasible to +find any two different messages x and y such that H(x)=H(y). Informally, +this property means that it is computationally infeasible for an +intruder to substitute one message for another message that is protected +by the hash + +Figure 8.7 Hash functions + +Figure 8.8 Initial message and fraudulent message have the same +checksum! + +function. That is, if (m, H(m)) are the message and the hash of the +message created by the sender, then + + an intruder cannot forge the contents of another message, y, that has +the same hash value as the original message. Let's convince ourselves +that a simple checksum, such as the Internet checksum, would make a poor +cryptographic hash function. Rather than performing 1s complement +arithmetic (as in the Internet checksum), let us compute a checksum by +treating each character as a byte and adding the bytes together using +4-byte chunks at a time. Suppose Bob owes Alice \$100.99 and sends an +IOU to Alice consisting of the text string " IOU100.99BOB. " The ASCII +representation (in hexadecimal notation) for these letters is 49 , 4F , +55 , 31 , 30 , 30 , 2E , 39 , 39 , 42 , 4F , 42 . Figure 8.8 (top) shows +that the 4-byte checksum for this message is B2 C1 D2 AC. A slightly +different message (and a much more costly one for Bob) is shown in the +bottom half of Figure 8.8. The messages " IOU100.99BOB " and " +IOU900.19BOB " have the same checksum. Thus, this simple checksum +algorithm violates the requirement above. Given the original data, it is +simple to find another set of data with the same checksum. Clearly, for +security purposes, we are going to need a more powerful hash function +than a checksum. The MD5 hash algorithm of Ron Rivest \[RFC 1321\] is in +wide use today. It computes a 128-bit hash in a four-step process +consisting of a padding step (adding a one followed by enough zeros so +that the length of the message satisfies certain conditions), an append +step (appending a 64-bit representation of the message length before +padding), an initialization of an accumulator, and a final looping step +in which the message's 16-word blocks are processed (mangled) in four +rounds. For a description of MD5 (including a C source code +implementation) see \[RFC 1321\]. The second major hash algorithm in use +today is the Secure Hash Algorithm (SHA-1) \[FIPS 1995\]. This algorithm +is based on principles similar to those used in the design of MD4 \[RFC +1320\], the predecessor to MD5. SHA-1, a US federal standard, is +required for use whenever a cryptographic hash algorithm is needed for +federal applications. It produces a 160-bit message digest. The longer +output length makes SHA-1 more secure. + +8.3.2 Message Authentication Code Let's now return to the problem of +message integrity. Now that we understand hash functions, let's take a +first stab at how we might perform message integrity: + +1. Alice creates message m and calculates the hash H(m) (for example + with SHA-1). +2. Alice then appends H(m) to the message m, creating an extended + message (m, H(m)), and sends the extended message to Bob. + + 3. Bob receives an extended message (m, h) and calculates H(m). If +H(m)=h, Bob concludes that everything is fine. This approach is +obviously flawed. Trudy can create a bogus message m´ in which she says +she is Alice, calculate H(m´), and send Bob (m´, H(m´)). When Bob +receives the message, everything checks out in step 3, so Bob doesn't +suspect any funny business. To perform message integrity, in addition to +using cryptographic hash functions, Alice and Bob will need a shared +secret s. This shared secret, which is nothing more than a string of +bits, is called the authentication key. Using this shared secret, +message integrity can be performed as follows: + +1. Alice creates message m, concatenates s with m to create m+s, and + calculates the hash H(m+s) (for example with SHA-1). H(m+s) is + called the message authentication code (MAC). + +2. Alice then appends the MAC to the message m, creating an extended + message (m, H(m+s)), and sends the extended message to Bob. + +3. Bob receives an extended message (m, h) and knowing s, calculates + the MAC H(m+s). If H(m+s)=h, Bob concludes that everything is fine. + A summary of the procedure is shown in Figure 8.9. Readers should + note that the MAC here (standing for "message authentication code") + is not the same MAC used in link-layer protocols (standing for + "medium access control")! One nice feature of a MAC is that it does + not require an encryption algorithm. Indeed, in many applications, + including the link-state routing algorithm described earlier, + communicating entities are only concerned with message integrity and + are not concerned with message confidentiality. Using a MAC, the + entities can authenticate + +Figure 8.9 Message authentication code (MAC) + + the messages they send to each other without having to integrate complex +encryption algorithms into the integrity process. As you might expect, a +number of different standards for MACs have been proposed over the +years. The most popular standard today is HMAC, which can be used either +with MD5 or SHA-1. HMAC actually runs data and the authentication key +through the hash function twice \[Kaufman 1995; RFC 2104\]. There still +remains an important issue. How do we distribute the shared +authentication key to the communicating entities? For example, in the +link-state routing algorithm, we would somehow need to distribute the +secret authentication key to each of the routers in the autonomous +system. (Note that the routers can all use the same authentication key.) +A network administrator could actually accomplish this by physically +visiting each of the routers. Or, if the network administrator is a lazy +guy, and if each router has its own public key, the network +administrator could distribute the authentication key to any one of the +routers by encrypting it with the router's public key and then sending +the encrypted key over the network to the router. + +8.3.3 Digital Signatures Think of the number of the times you've signed +your name to a piece of paper during the last week. You sign checks, +credit card receipts, legal documents, and letters. Your signature +attests to the fact that you (as opposed to someone else) have +acknowledged and/or agreed with the document's contents. In a digital +world, one often wants to indicate the owner or creator of a document, +or to signify one's agreement with a document's content. A digital +signature is a cryptographic technique for achieving these goals in a +digital world. Just as with handwritten signatures, digital signing +should be done in a way that is verifiable and nonforgeable. That is, it +must be possible to prove that a document signed by an individual was +indeed signed by that individual (the signature must be verifiable) and +that only that individual could have signed the document (the signature +cannot be forged). Let's now consider how we might design a digital +signature scheme. Observe that when Bob signs a message, Bob must put +something on the message that is unique to him. Bob could consider +attaching a MAC for the signature, where the MAC is created by appending +his key (unique to him) to the message, and then taking the hash. But +for Alice to verify the signature, she must also have a copy of the key, +in which case the key would not be unique to Bob. Thus, MACs are not +going to get the job done here. + + Recall that with public-key cryptography, Bob has both a public and +private key, with both of these keys being unique to Bob. Thus, +public-key cryptography is an excellent candidate for providing digital +signatures. Let us now examine how it is done. Suppose that Bob wants to +digitally sign a document, m. We can think of the document as a file or +a message that Bob is going to sign and send. As shown in Figure 8.10, +to sign this document, Bob simply uses his private key, KB−, to compute +KB−(m). At first, it might seem odd that Bob is using his private key +(which, as we saw in Section 8.2, was used to decrypt a message that had +been encrypted with his public key) to sign a document. But recall that +encryption and decryption are nothing more than mathematical operations +(exponentiation to the power of e or d in RSA; see Section 8.2) and +recall that Bob's goal is not to scramble or obscure the contents of the +document, but rather to sign the document in a manner that is verifiable +and nonforgeable. Bob's digital signature of the document is KB−(m). +Does the digital signature KB−(m) meet our requirements of being +verifiable and nonforgeable? Suppose Alice has m and KB−(m). She wants +to prove in court (being + +Figure 8.10 Creating a digital signature for a document + +litigious) that Bob had indeed signed the document and was the only +person who could have possibly signed the document. Alice takes Bob's +public key, KB+, and applies it to the digital signature, KB−(m), +associated with the document, m. That is, she computes KB+(KB−(m)), and +voilà, with a dramatic flurry, she produces m, which exactly matches the +original document! Alice then argues that only Bob could have signed the +document, for the following reasons: Whoever signed the message must +have used the private key, KB−, in computing the signature KB−(m), such +that KB+(KB−(m))=m. The only person who could have known the private +key, KB−, is Bob. Recall from our discussion of + + RSA in Section 8.2 that knowing the public key, KB+, is of no help in +learning the private key, KB−. Therefore, the only person who could know +KB− is the person who generated the pair of keys, (KB+, KB−), in the +first place, Bob. (Note that this assumes, though, that Bob has not +given KB− to anyone, nor has anyone stolen KB− from Bob.) It is also +important to note that if the original document, m, is ever modified to +some alternate form, m´, the signature that Bob created for m will not +be valid for m´, since KB+(KB−(m)) does not equal m´. Thus we see that +digital signatures also provide message integrity, allowing the receiver +to verify that the message was unaltered as well as the source of the +message. One concern with signing data by encryption is that encryption +and decryption are computationally expensive. Given the overheads of +encryption and decryption, signing data via complete +encryption/decryption can be overkill. A more efficient approach is to +introduce hash functions into the digital signature. Recall from Section +8.3.2 that a hash algorithm takes a message, m, of arbitrary length and +computes a fixed-length "fingerprint" of the message, denoted by H(m). +Using a hash function, Bob signs the hash of a message rather than the +message itself, that is, Bob calculates KB−(H(m)). Since H(m) is +generally much smaller than the original message m, the computational +effort required to create the digital signature is substantially +reduced. In the context of Bob sending a message to Alice, Figure 8.11 +provides a summary of the operational procedure of creating a digital +signature. Bob puts his original long message through a hash function. +He then digitally signs the resulting hash with his private key. The +original message (in cleartext) along with the digitally signed message +digest (henceforth referred to as the digital signature) is then sent to +Alice. Figure 8.12 provides a summary of the operational procedure of +the signature. Alice applies the sender's public key to the message to +obtain a hash result. Alice also applies the hash function to the +cleartext message to obtain a second hash result. If the two hashes +match, then Alice can be sure about the integrity and author of the +message. Before moving on, let's briefly compare digital signatures with +MACs, since they have parallels, but also have important subtle +differences. Both digital signatures and + + Figure 8.11 Sending a digitally signed message + +MACs start with a message (or a document). To create a MAC out of the +message, we append an authentication key to the message, and then take +the hash of the result. Note that neither public key nor symmetric key +encryption is involved in creating the MAC. To create a digital +signature, we first take the hash of the message and then encrypt the +message with our private key (using public key cryptography). Thus, a +digital signature is a "heavier" technique, since it requires an +underlying Public Key Infrastructure (PKI) with certification +authorities as described below. We'll see in Section 8.4 that PGP---a +popular secure e-mail system---uses digital signatures for message +integrity. We've seen already that OSPF uses MACs for message integrity. +We'll see in Sections 8.5 and 8.6 that MACs are also used for popular +transport-layer and network-layer security protocols. Public Key +Certification An important application of digital signatures is public +key certification, that is, certifying that a public key belongs to a +specific entity. Public key certification is used in many popular secure +networking protocols, including IPsec and SSL. To gain insight into this +problem, let's consider an Internet-commerce version of the classic +"pizza prank." Alice is in the pizza delivery business and accepts +orders + + Figure 8.12 Verifying a signed message + +over the Internet. Bob, a pizza lover, sends Alice a plaintext message +that includes his home address and the type of pizza he wants. In this +message, Bob also includes a digital signature (that is, a signed hash +of the original plaintext message) to prove to Alice that he is the true +source of the message. To verify the signature, Alice obtains Bob's +public key (perhaps from a public key server or from the e-mail message) +and checks the digital signature. In this manner she makes sure that +Bob, rather than some adolescent prankster, placed the order. This all +sounds fine until clever Trudy comes along. As shown in Figure 8.13, +Trudy is indulging in a prank. She sends a message to Alice in which she +says she is Bob, gives Bob's home address, and orders a pizza. In this +message she also includes her (Trudy's) public key, although Alice +naturally assumes it is Bob's public key. Trudy also attaches a digital +signature, which was created with her own (Trudy's) private key. After +receiving the message, Alice applies Trudy's public key (thinking that +it is Bob's) to the digital signature and concludes that the plaintext +message was + + Figure 8.13 Trudy masquerades as Bob using public key cryptography + +indeed created by Bob. Bob will be very surprised when the delivery +person brings a pizza with pepperoni and anchovies to his home! We see +from this example that for public key cryptography to be useful, you +need to be able to verify that you have the actual public key of the +entity (person, router, browser, and so on) with whom you want to +communicate. For example, when Alice wants to communicate with Bob using +public key cryptography, she needs to verify that the public key that is +supposed to be Bob's is indeed Bob's. Binding a public key to a +particular entity is typically done by a Certification Authority (CA), +whose job is to validate identities and issue certificates. A CA has the +following roles: + +1. A CA verifies that an entity (a person, a router, and so on) is who + it says it is. There are no mandated procedures for how + certification is done. When dealing with a CA, one must trust the CA + to have performed a suitably rigorous identity verification. For + example, if Trudy were able to walk into the Fly-by-Night + + Figure 8.14 Bob has his public key certified by the CA + +CA and simply announce "I am Alice" and receive certificates associated +with the identity of Alice, then one shouldn't put much faith in public +keys certified by the Fly-by-Night CA. On the other hand, one might (or +might not!) be more willing to trust a CA that is part of a federal or +state program. You can trust the identity associated with a public key +only to the extent to which you can trust a CA and its identity +verification techniques. What a tangled web of trust we spin! + +2. Once the CA verifies the identity of the entity, the CA creates a + certificate that binds the public key of the entity to the identity. + The certificate contains the public key and globally unique + identifying information about the owner of the public key (for + example, a human name or an IP address). The certificate is + digitally signed by the CA. These steps are shown in Figure 8.14. + Let us now see how certificates can be used to combat pizza-ordering + pranksters, like Trudy, and other undesirables. When Bob places his + order he also sends his CA-signed certificate. Alice uses the CA's + public key to check the validity of Bob's certificate and extract + Bob's public key. Both the International Telecommunication Union + (ITU) and the IETF have developed standards for CAs. ITU X.509 \[ITU + 2005a\] specifies an authentication service as well as a specific + syntax for certificates. \[RFC 1422\] describes CA-based key + management for use with secure Internet e-mail. It is compatible + with X.509 but goes beyond X.509 by establishing procedures and + conventions for a key management architecture. Table 8.4 describes + some of the important fields in a certificate. Table 8.4 Selected + fields in an X.509 and RFC 1422 public key + + Field Name + +Description + +Version + +Version number of X.509 specification + +Serial + +CA-issued unique identifier for a certificate + +number Signature + +Specifies the algorithm used by CA to sign this certificate + +Issuer + +Identity of CA issuing this certificate, in distinguished name (DN) +\[RFC 4514\] format + +name Validity + +Start and end of period of validity for certificate + +period Subject + +Identity of entity whose public key is associated with this certificate, +in DN format + +name Subject + +The subject's public key as well indication of the public key algorithm +(and algorithm + +public key + +parameters) to be used with this key + + 8.4 End-Point Authentication End-point authentication is the process of +one entity proving its identity to another entity over a computer +network, for example, a user proving its identity to an e-mail server. +As humans, we authenticate each other in many ways: We recognize each +other's faces when we meet, we recognize each other's voices on the +telephone, we are authenticated by the customs official who checks us +against the picture on our passport. In this section, we consider how +one party can authenticate another party when the two are communicating +over a network. We focus here on authenticating a "live" party, at the +point in time when communication is actually occurring. A concrete +example is a user authenticating him or herself to an email server. This +is a subtly different problem from proving that a message received at +some point in the past did indeed come from that claimed sender, as +studied in Section 8.3. When performing authentication over the network, +the communicating parties cannot rely on biometric information, such as +a visual appearance or a voiceprint. Indeed, we will see in our later +case studies that it is often network elements such as routers and +client/server processes that must authenticate each other. Here, +authentication must be done solely on the basis of messages and data +exchanged as part of an authentication protocol. Typically, an +authentication protocol would run before the two communicating parties +run some other protocol (for example, a reliable data transfer protocol, +a routing information exchange protocol, or an e-mail protocol). The +authentication protocol first establishes the identities of the parties +to each other's satisfaction; only after authentication do the parties +get down to the work at hand. As in the case of our development of a +reliable data transfer (rdt) protocol in Chapter 3, we will find it +instructive here to develop various versions of an authentication +protocol, which we will call ap (authentication protocol), and poke +holes in each version + + Figure 8.15 Protocol ap1.0 and a failure scenario + +as we proceed. (If you enjoy this stepwise evolution of a design, you +might also enjoy \[Bryant 1988\], which recounts a fictitious narrative +between designers of an open-network authentication system, and their +discovery of the many subtle issues involved.) Let's assume that Alice +needs to authenticate herself to Bob. + +8.4.1 Authentication Protocol ap1.0 Perhaps the simplest authentication +protocol we can imagine is one where Alice simply sends a message to Bob +saying she is Alice. This protocol is shown in Figure 8.15. The flaw +here is obvious--- there is no way for Bob actually to know that the +person sending the message "I am Alice" is indeed Alice. For example, +Trudy (the intruder) could just as well send such a message. + +8.4.2 Authentication Protocol ap2.0 If Alice has a well-known network +address (e.g., an IP address) from which she always communicates, Bob +could attempt to authenticate Alice by verifying that the source address +on the IP datagram carrying the authentication message matches Alice's +well-known address. In this case, Alice would be authenticated. This +might stop a very network-naive intruder from impersonating Alice, but +it wouldn't stop the determined student studying this book, or many +others! From our study of the network and data link layers, we know that +it is not that hard (for example, if one had access to the operating +system code and could build one's own operating system kernel, as is the + + case with Linux and several other freely available operating systems) to +create an IP datagram, put whatever IP source address we want (for +example, Alice's well-known IP address) into the IP datagram, and send +the datagram over the link-layer protocol to the first-hop router. From +then + +Figure 8.16 Protocol ap2.0 and a failure scenario + +on, the incorrectly source-addressed datagram would be dutifully +forwarded to Bob. This approach, shown in Figure 8.16, is a form of IP +spoofing. IP spoofing can be avoided if Trudy's first-hop router is +configured to forward only datagrams containing Trudy's IP source +address \[RFC 2827\]. However, this capability is not universally +deployed or enforced. Bob would thus be foolish to assume that Trudy's +network manager (who might be Trudy herself) had configured Trudy's +first-hop router to forward only appropriately addressed datagrams. + +8.4.3 Authentication Protocol ap3.0 One classic approach to +authentication is to use a secret password. The password is a shared +secret between the authenticator and the person being authenticated. +Gmail, Facebook, telnet, FTP, and many other services use password +authentication. In protocol ap3.0, Alice thus sends her secret password +to Bob, as shown in Figure 8.17. Since passwords are so widely used, we +might suspect that protocol ap3.0 is fairly secure. If so, we'd be +wrong! The security flaw here is clear. If Trudy eavesdrops on Alice's +communication, then she can learn Alice's password. Lest you think this +is unlikely, consider the fact that when you Telnet to another machine +and log in, the login password is sent unencrypted to the Telnet server. +Someone connected to the Telnet client or server's LAN can possibly +sniff (read and store) all packets transmitted on the LAN and thus steal +the login password. In fact, this is a well-known approach for stealing +passwords (see, for example, \[Jimenez 1997\]). Such a threat is +obviously very real, so ap3.0 clearly won't do. + + 8.4.4 Authentication Protocol ap3.1 Our next idea for fixing ap3.0 is +naturally to encrypt the password. By encrypting the password, we can +prevent Trudy from learning Alice's password. If we assume + +Figure 8.17 Protocol ap3.0 and a failure scenario + +that Alice and Bob share a symmetric secret key, KA−B, then Alice can +encrypt the password and send her identification message, " I am Alice, +" and her encrypted password to Bob. Bob then decrypts the password and, +assuming the password is correct, authenticates Alice. Bob feels +comfortable in authenticating Alice since Alice not only knows the +password, but also knows the shared secret key value needed to encrypt +the password. Let's call this protocol ap3.1. While it is true that +ap3.1 prevents Trudy from learning Alice's password, the use of +cryptography here does not solve the authentication problem. Bob is +subject to a playback attack: Trudy need only eavesdrop on Alice's +communication, record the encrypted version of the password, and play +back the encrypted version of the password to Bob to pretend that she is +Alice. The use of an encrypted password in ap3.1 doesn't make the +situation manifestly different from that of protocol ap3.0 in Figure +8.17. + + 8.4.5 Authentication Protocol ap4.0 The failure scenario in Figure 8.17 +resulted from the fact that Bob could not distinguish between the +original authentication of Alice and the later playback of Alice's +original authentication. That is, Bob could not tell if Alice was live +(that is, was currently really on the other end of the connection) or +whether the messages he was receiving were a recorded playback of a +previous authentication of Alice. The very (very) observant reader will +recall that the three-way TCP handshake protocol needed to address the +same problem---the server side of a TCP connection did not want to +accept a connection if the received SYN segment was an old copy +(retransmission) of a SYN segment from an earlier connection. How did +the TCP server side solve the problem of determining whether the client +was really live? It chose an initial sequence number that had not been +used in a very long time, sent that number to the client, and then +waited for the client to respond with an ACK segment containing that +number. We can adopt the same idea here for authentication purposes. A +nonce is a number that a protocol will use only once in a lifetime. That +is, once a protocol uses a nonce, it will never use that number again. +Our ap4.0 protocol uses a nonce as follows: + +1. Alice sends the message " I am Alice " to Bob. + +2. Bob chooses a nonce, R, and sends it to Alice. + +3. Alice encrypts the nonce using Alice and Bob's symmetric secret key, + KA−B, and sends the encrypted nonce, KA−B (R), back to Bob. As in + protocol ap3.1, it is the fact that Alice knows KA−B and uses it to + encrypt a value that lets Bob know that the message he receives was + generated by Alice. The nonce is used to ensure that Alice is live. + +4. Bob decrypts the received message. If the decrypted nonce equals the + nonce he sent Alice, then Alice is authenticated. Protocol ap4.0 is + illustrated in Figure 8.18. By using the once-in-a-lifetime value, + R, and then checking the returned value, KA−B (R), Bob can be sure + that Alice is both who she says she is (since she knows the secret + key value needed to encrypt R) and live (since she has encrypted the + nonce, R, that Bob just created). The use of a nonce and symmetric + key cryptography forms the basis of ap4.0. A natural question is + whether we can use a nonce and public key cryptography (rather than + symmetric key cryptography) to solve the authentication problem. + This issue is explored in the problems at the end of the chapter. + + Figure 8.18 Protocol ap4.0 and a failure scenario + + 8.5 Securing E-Mail In previous sections, we examined fundamental issues +in network security, including symmetric key and public key +cryptography, end-point authentication, key distribution, message +integrity, and digital signatures. We are now going to examine how these +tools are being used to provide security in the Internet. Interestingly, +it is possible to provide security services in any of the top four +layers of the Internet protocol stack. When security is provided for a +specific application-layer protocol, the application using the protocol +will enjoy one or more security services, such as confidentiality, +authentication, or integrity. When security is provided for a +transport-layer protocol, all applications that use that protocol enjoy +the security services of the transport protocol. When security is +provided at the network layer on a host-tohost basis, all +transport-layer segments (and hence all application-layer data) enjoy +the security services of the network layer. When security is provided on +a link basis, then the data in all frames traveling over the link +receive the security services of the link. In Sections 8.5 through 8.8, +we examine how security tools are being used in the application, +transport, network, and link layers. Being consistent with the general +structure of this book, we begin at the top of the protocol stack and +discuss security at the application layer. Our approach is to use a +specific application, e-mail, as a case study for application-layer +security. We then move down the protocol stack. We'll examine the SSL +protocol (which provides security at the transport layer), IPsec (which +provides security at the network layer), and the security of the IEEE +802.11 wireless LAN protocol. You might be wondering why security +functionality is being provided at more than one layer in the Internet. +Wouldn't it suffice simply to provide the security functionality at the +network layer and be done with it? There are two answers to this +question. First, although security at the network layer can offer +"blanket coverage" by encrypting all the data in the datagrams (that is, +all the transport-layer segments) and by authenticating all the source +IP addresses, it can't provide user-level security. For example, a +commerce site cannot rely on IP-layer security to authenticate a +customer who is purchasing goods at the commerce site. Thus, there is a +need for security functionality at higher layers as well as blanket +coverage at lower layers. Second, it is generally easier to deploy new +Internet services, including security services, at the higher layers of +the protocol stack. While waiting for security to be broadly deployed at +the network layer, which is probably still many years in the future, +many application developers "just do it" and introduce security +functionality into their favorite applications. A classic example is +Pretty Good Privacy (PGP), which provides secure e-mail (discussed later +in this section). Requiring only client and server application code, PGP +was one of the first security technologies to be broadly used in the +Internet. + + 8.5.1 Secure E-Mail We now use the cryptographic principles of Sections +8.2 through 8.3 to create a secure e-mail system. We create this +high-level design in an incremental manner, at each step introducing new +security services. When designing a secure e-mail system, let us keep in +mind the racy example introduced in Section 8.1---the love affair +between Alice and Bob. Imagine that Alice wants to send an e-mail +message to Bob, and Trudy wants to intrude. Before plowing ahead and +designing a secure e-mail system for Alice and Bob, we should consider +which security features would be most desirable for them. First and +foremost is confidentiality. As discussed in Section 8.1, neither Alice +nor Bob wants Trudy to read Alice's e-mail message. The second feature +that Alice and Bob would most likely want to see in the secure e-mail +system is sender authentication. In particular, when Bob receives the +message " I don't love you anymore. I never want to see you again. +Formerly yours, Alice, " he would naturally want to be sure that the +message came from Alice and not from Trudy. Another feature that the two +lovers would appreciate is message integrity, that is, assurance that +the message Alice sends is not modified while en route to Bob. Finally, +the e-mail system should provide receiver authentication; that is, Alice +wants to make sure that she is indeed sending the letter to Bob and not +to someone else (for example, Trudy) who is impersonating Bob. So let's +begin by addressing the foremost concern, confidentiality. The most +straightforward way to provide confidentiality is for Alice to encrypt +the message with symmetric key technology (such as DES or AES) and for +Bob to decrypt the message on receipt. As discussed in Section 8.2, if +the symmetric key is long enough, and if only Alice and Bob have the +key, then it is extremely difficult for anyone else (including Trudy) to +read the message. Although this approach is straightforward, it has the +fundamental difficulty that we discussed in Section 8.2---distributing a +symmetric key so that only Alice and Bob have copies of it. So we +naturally consider an alternative approach---public key cryptography +(using, for example, RSA). In the public key approach, Bob makes his +public key publicly available (e.g., in a public key server or on his +personal Web page), Alice encrypts her message with Bob's public key, +and she sends the encrypted message to Bob's e-mail address. When Bob +receives the message, he simply decrypts it with his private key. +Assuming that Alice knows for sure that the public key is Bob's public +key, this approach is an excellent means to provide the desired +confidentiality. One problem, however, is that public key encryption is +relatively inefficient, particularly for long messages. To overcome the +efficiency problem, let's make use of a session key (discussed in +Section 8.2.2). In particular, Alice (1) selects a random symmetric +session key, KS, (2) encrypts her message, m, with the symmetric key, +(3) encrypts the symmetric key with Bob's public key, KB+, (4) +concatenates the + + encrypted message and the encrypted symmetric key to form a "package," +and (5) sends the package to Bob's + +Figure 8.19 Alice used a symmetric session key, KS, to send a secret +e-mail to Bob + +e-mail address. The steps are illustrated in Figure 8.19. (In this and +the subsequent figures, the circled "+" represents concatenation and the +circled "−" represents deconcatenation.) When Bob receives the package, +he (1) uses his private key, KB−, to obtain the symmetric key, KS, and +(2) uses the symmetric key KS to decrypt the message m. Having designed +a secure e-mail system that provides confidentiality, let's now design +another system that provides both sender authentication and message +integrity. We'll suppose, for the moment, that Alice and Bob are no +longer concerned with confidentiality (they want to share their feelings +with everyone!), and are concerned only about sender authentication and +message integrity. To accomplish this task, we use digital signatures +and message digests, as described in Section 8.3. Specifically, Alice +(1) applies a hash function, H (for example, MD5), to her message, m, to +obtain a message digest, (2) signs the result of the hash function with +her private key, KA−, to create a digital signature, (3) concatenates +the original (unencrypted) message with the signature to create a +package, and (4) sends the package to Bob's e-mail address. When Bob +receives the package, he (1) applies Alice's public key, KA+, to the +signed message digest and (2) compares the result of this operation with +his own hash, H, of the message. The steps are illustrated in Figure +8.20. As discussed in Section 8.3, if the two results are the same, Bob +can be pretty confident that the message came from Alice and is +unaltered. Now let's consider designing an e-mail system that provides +confidentiality, sender authentication, and message integrity. This can +be done by combining the procedures in Figures 8.19 and 8.20. Alice +first creates a preliminary package, exactly as in Figure 8.20, that +consists of her original message along with a digitally signed hash of +the message. She then treats this preliminary package as a message in +itself and sends this new message through the sender steps in Figure +8.19, creating a new package that is sent to Bob. The steps applied by +Alice are shown in Figure 8.21. When Bob receives the + + package, he first applies his side of Figure 8.19 and then his + +Figure 8.20 Using hash functions and digital signatures to provide +sender authentication and message integrity + +side of Figure 8.20. It should be clear that this design achieves the +goal of providing confidentiality, sender authentication, and message +integrity. Note that, in this scheme, Alice uses public key cryptography +twice: once with her own private key and once with Bob's public key. +Similarly, Bob also uses public key cryptography twice---once with his +private key and once with Alice's public key. The secure e-mail design +outlined in Figure 8.21 probably provides satisfactory security for most +e-mail users for most occasions. But there is still one important issue +that remains to be addressed. The design in Figure 8.21 requires Alice +to obtain Bob's public key, and requires Bob to obtain Alice's public +key. The distribution of these public keys is a nontrivial problem. For +example, Trudy might masquerade as Bob and give Alice her own public key +while saying that it is Bob's public key, + +Figure 8.21 Alice uses symmetric key cyptography, public key +cryptography, a hash function, and a digital signature to provide +secrecy, sender authentication, and message integrity + + enabling her to receive the message meant for Bob. As we learned in +Section 8.3, a popular approach for securely distributing public keys is +to certify the public keys using a CA. + +8.5.2 PGP Written by Phil Zimmermann in 1991, Pretty Good Privacy (PGP) +is a nice example of an e-mail encryption scheme \[PGPI 2016\]. Versions +of PGP are available in the public domain; for example, you can find the +PGP software for your favorite platform as well as lots of interesting +reading at the International PGP Home Page \[PGPI 2016\]. The PGP design +is, in essence, the same as the design shown in Figure 8.21. Depending +on the version, the PGP software uses MD5 or SHA for calculating the +message digest; CAST, triple-DES, or IDEA for symmetric key encryption; +and RSA for the public key encryption. When PGP is installed, the +software creates a public key pair for the user. The public key can be +posted on the user's Web site or placed in a public key server. The +private key is protected by the use of a password. The password has to +be entered every time the user accesses the private key. PGP gives the +user the option of digitally signing the message, encrypting the +message, or both digitally signing and encrypting. Figure 8.22 shows a +PGP signed message. This message appears after the MIME header. The +encoded data in the message is KA−(H(m)), that is, the digitally signed +message digest. As we discussed above, in order for Bob to verify the +integrity of the message, he needs to have access to Alice's public key. +Figure 8.23 shows a secret PGP message. This message also appears after +the MIME header. Of course, the plaintext message is not included within +the secret e-mail message. When a sender (such as Alice) wants both +confidentiality and integrity, PGP contains a message like that of +Figure 8.23 within the message of Figure 8.22. PGP also provides a +mechanism for public key certification, but the mechanism is quite +different from the more conventional CA. PGP public keys are certified +by + + Figure 8.22 A PGP signed message + +Figure 8.23 A secret PGP message + +a web of trust. Alice herself can certify any key/username pair when she +believes the pair really belong together. In addition, PGP permits Alice +to say that she trusts another user to vouch for the authenticity of +more keys. Some PGP users sign each other's keys by holding key-signing +parties. Users physically gather, exchange public keys, and certify each +other's keys by signing them with their private keys. + + 8.6 Securing TCP Connections: SSL In the previous section, we saw how +cryptographic techniques can provide confidentiality, data integrity, +and end-point authentication to a specific application, namely, e-mail. +In this section, we'll drop down a layer in the protocol stack and +examine how cryptography can enhance TCP with security services, +including confidentiality, data integrity, and end-point authentication. +This enhanced version of TCP is commonly known as Secure Sockets Layer +(SSL). A slightly modified version of SSL version 3, called Transport +Layer Security (TLS), has been standardized by the IETF \[RFC 4346\]. +The SSL protocol was originally designed by Netscape, but the basic +ideas behind securing TCP had predated Netscape's work (for example, see +Woo \[Woo 1994\]). Since its inception, SSL has enjoyed broad +deployment. SSL is supported by all popular Web browsers and Web +servers, and it is used by Gmail and essentially all Internet commerce +sites (including Amazon, eBay, and TaoBao). Hundreds of billions of +dollars are spent over SSL every year. In fact, if you have ever +purchased anything over the Internet with your credit card, the +communication between your browser and the server for this purchase +almost certainly went over SSL. (You can identify that SSL is being used +by your browser when the URL begins with https: rather than http.) To +understand the need for SSL, let's walk through a typical Internet +commerce scenario. Bob is surfing the Web and arrives at the Alice +Incorporated site, which is selling perfume. The Alice Incorporated site +displays a form in which Bob is supposed to enter the type of perfume +and quantity desired, his address, and his payment card number. Bob +enters this information, clicks on Submit, and expects to receive (via +ordinary postal mail) the purchased perfumes; he also expects to receive +a charge for his order in his next payment card statement. This all +sounds good, but if no security measures are taken, Bob could be in for +a few surprises. If no confidentiality (encryption) is used, an intruder +could intercept Bob's order and obtain his payment card information. The +intruder could then make purchases at Bob's expense. If no data +integrity is used, an intruder could modify Bob's order, having him +purchase ten times more bottles of perfume than desired. Finally, if no +server authentication is used, a server could display Alice +Incorporated's famous logo when in actuality the site maintained by +Trudy, who is masquerading as Alice Incorporated. After receiving Bob's +order, Trudy could take Bob's money and run. Or Trudy could carry out an +identity theft by collecting Bob's name, address, and credit card +number. SSL addresses these issues by enhancing TCP with +confidentiality, data integrity, server authentication, and client +authentication. + + SSL is often used to provide security to transactions that take place +over HTTP. However, because SSL secures TCP, it can be employed by any +application that runs over TCP. SSL provides a simple Application +Programmer Interface (API) with sockets, which is similar and analogous +to TCP's API. When an application wants to employ SSL, the application +includes SSL classes/libraries. As shown in Figure 8.24, although SSL +technically resides in the application layer, from the developer's +perspective it is a transport protocol that provides TCP's services +enhanced with security services. + +8.6.1 The Big Picture We begin by describing a simplified version of +SSL, one that will allow us to get a big-picture understanding of the +why and how of SSL. We will refer to this simplified + +Figure 8.24 Although SSL technically resides in the application layer, +from the developer's perspective it is a transport-layer protocol + +version of SSL as "almost-SSL." After describing almost-SSL, in the next +subsection we'll then describe the real SSL, filling in the details. +Almost-SSL (and SSL) has three phases: handshake, key derivation, and +data transfer. We now describe these three phases for a communication +session between a client (Bob) and a server (Alice), with Alice having a +private/public key pair and a certificate that binds her identity to her +public key. + + Handshake During the handshake phase, Bob needs to (a) establish a TCP +connection with Alice, (b) verify that Alice is really Alice, and (c) +send Alice a master secret key, which will be used by both Alice and Bob +to generate all the symmetric keys they need for the SSL session. These +three steps are shown in Figure 8.25. Note that once the TCP connection +is established, Bob sends Alice a hello message. Alice then responds +with her certificate, which contains her public key. As discussed in +Section 8.3, because the certificate has been certified by a CA, Bob +knows for sure that the public key in the certificate belongs to Alice. +Bob then generates a Master Secret (MS) (which will only be used for +this SSL session), encrypts the MS with Alice's public key to create the +Encrypted Master Secret (EMS), and sends the EMS to Alice. Alice +decrypts the EMS with her private key to get the MS. After this phase, +both Bob and Alice (and no one else) know the master secret for this SSL +session. + +Figure 8.25 The almost-SSL handshake, beginning with a TCP connection + +Key Derivation In principle, the MS, now shared by Bob and Alice, could +be used as the symmetric session key for all subsequent encryption and +data integrity checking. It is, however, generally considered safer for +Alice and Bob to each use different cryptographic keys, and also to use +different keys for encryption and integrity checking. Thus, both Alice +and Bob use the MS to generate four keys: EB= session encryption key for +data sent from Bob to Alice MB= session MAC key for data sent from Bob +to Alice EA= + + session encryption key for data sent from Alice to Bob MA= session MAC +key for data sent from Alice to Bob Alice and Bob each generate the four +keys from the MS. This could be done by simply slicing the MS into four +keys. (But in real SSL it is a little more complicated, as we'll see.) +At the end of the key derivation phase, both Alice and Bob have all four +keys. The two encryption keys will be used to encrypt data; the two MAC +keys will be used to verify the integrity of the data. Data Transfer Now +that Alice and Bob share the same four session keys (EB, MB, EA, and +MA), they can start to send secured data to each other over the TCP +connection. Since TCP is a byte-stream protocol, a natural approach +would be for SSL to encrypt application data on the fly and then pass +the encrypted data on the fly to TCP. But if we were to do this, where +would we put the MAC for the integrity check? We certainly do not want +to wait until the end of the TCP session to verify the integrity of all +of Bob's data that was sent over the entire session! To address this +issue, SSL breaks the data stream into records, appends a MAC to each +record for integrity checking, and then encrypts the record +MAC. To +create the MAC, Bob inputs the record data along with the key MB into a +hash function, as discussed in Section 8.3. To encrypt the package +record +MAC, Bob uses his session encryption key EB. This encrypted +package is then passed to TCP for transport over the Internet. Although +this approach goes a long way, it still isn't bullet-proof when it comes +to providing data integrity for the entire message stream. In +particular, suppose Trudy is a woman-in-the-middle and has the ability +to insert, delete, and replace segments in the stream of TCP segments +sent between Alice and Bob. Trudy, for example, could capture two +segments sent by Bob, reverse the order of the segments, adjust the TCP +sequence numbers (which are not encrypted), and then send the two +reverse-ordered segments to Alice. Assuming that each TCP segment +encapsulates exactly one record, let's now take a look at how Alice +would process these segments. + +1. TCP running in Alice would think everything is fine and pass the two + records to the SSL sublayer. + +2. SSL in Alice would decrypt the two records. + +3. SSL in Alice would use the MAC in each record to verify the data + integrity of the two records. + +4. SSL would then pass the decrypted byte streams of the two records to + the application layer; but the complete byte stream received by + Alice would not be in the correct order due to reversal of the + records! You are encouraged to walk through similar scenarios for + when Trudy removes segments or when Trudy replays segments. + + The solution to this problem, as you probably guessed, is to use +sequence numbers. SSL does this as follows. Bob maintains a sequence +number counter, which begins at zero and is incremented for each SSL +record he sends. Bob doesn't actually include a sequence number in the +record itself, but when he calculates the MAC, he includes the sequence +number in the MAC calculation. Thus, the MAC is now a hash of the data +plus the MAC key MB plus the current sequence number. Alice tracks Bob's +sequence numbers, allowing her to verify the data integrity of a record +by including the appropriate sequence number in the MAC calculation. +This use of SSL sequence numbers prevents Trudy from carrying out a +woman-in-the-middle attack, such as reordering or replaying segments. +(Why?) SSL Record The SSL record (as well as the almost-SSL record) is +shown in Figure 8.26. The record consists of a type field, version +field, length field, data field, and MAC field. Note that the first +three fields are not encrypted. The type field indicates whether the +record is a handshake message or a message that contains application +data. It is also used to close the SSL connection, as discussed below. +SSL at the receiving end uses the length field to extract the SSL +records out of the incoming TCP byte stream. The version field is +self-explanatory. + +8.6.2 A More Complete Picture The previous subsection covered the +almost-SSL protocol; it served to give us a basic understanding of the +why and how of SSL. Now that we have a basic understanding of SSL, we +can dig a little deeper and examine the essentials of the actual SSL +protocol. In parallel to reading this description of the SSL protocol, +you are encouraged to complete the Wireshark SSL lab, available at the +textbook's Web site. + +Figure 8.26 Record format for SSL + +SSL Handshake SSL does not mandate that Alice and Bob use a specific +symmetric key algorithm, a specific public-key algorithm, or a specific +MAC. Instead, SSL allows Alice and Bob to agree on the cryptographic +algorithms at the beginning of the SSL session, during the handshake +phase. Additionally, during the handshake phase, Alice and Bob send +nonces to each other, which are used in the creation of the + + session keys (EB, MB, EA, and MA). The steps of the real SSL handshake +are as follows: + +1. The client sends a list of cryptographic algorithms it supports, + along with a client nonce. + +2. From the list, the server chooses a symmetric algorithm (for + example, AES), a public key algorithm (for example, RSA with a + specific key length), and a MAC algorithm. It sends back to the + client its choices, as well as a certificate and a server nonce. + +3. The client verifies the certificate, extracts the server's public + key, generates a Pre-Master Secret (PMS), encrypts the PMS with the + server's public key, and sends the encrypted PMS to the server. + +4. Using the same key derivation function (as specified by the SSL + standard), the client and server independently compute the Master + Secret (MS) from the PMS and nonces. The MS is then sliced up to + generate the two encryption and two MAC keys. Furthermore, when the + chosen symmetric cipher employs CBC (such as 3DES or AES), then two + Initialization Vectors (IVs)--- one for each side of the + connection---are also obtained from the MS. Henceforth, all messages + sent between client and server are encrypted and authenticated (with + the MAC). + +5. The client sends a MAC of all the handshake messages. + +6. The server sends a MAC of all the handshake messages. The last two + steps protect the handshake from tampering. To see this, observe + that in step 1, the client typically offers a list of + algorithms---some strong, some weak. This list of algorithms is sent + in cleartext, since the encryption algorithms and keys have not yet + been agreed upon. Trudy, as a woman-in-themiddle, could delete the + stronger algorithms from the list, forcing the client to select a + weak algorithm. To prevent such a tampering attack, in step 5 the + client sends a MAC of the concatenation of all the handshake + messages it sent and received. The server can compare this MAC with + the MAC of the handshake messages it received and sent. If there is + an inconsistency, the server can terminate the connection. + Similarly, the server sends a MAC of the handshake messages it has + seen, allowing the client to check for inconsistencies. You may be + wondering why there are nonces in steps 1 and 2. Don't sequence + numbers suffice for preventing the segment replay attack? The answer + is yes, but they don't alone prevent the "connection replay attack." + Consider the following connection replay attack. Suppose Trudy + sniffs all messages between Alice and Bob. The next day, Trudy + masquerades as Bob and sends to Alice exactly the same sequence of + messages that Bob sent to Alice on the previous day. If Alice + doesn't use nonces, she will respond with exactly the same sequence + of messages she sent the previous day. Alice will not suspect any + funny business, as each message she receives will pass the integrity + check. If Alice is an ecommerce server, she will think that Bob is + placing a second order (for exactly the same thing). On the other + hand, by including a nonce in the protocol, Alice will send + different nonces for each TCP session, causing the encryption keys + to be different on the two days. Therefore, when Alice receives + played-back SSL records from Trudy, the records will fail the + integrity checks, and the bogus e-commerce transaction will not + succeed. In summary, in SSL, nonces are used to defend against the + "connection replay attack" + + and sequence numbers are used to defend against replaying individual +packets during an ongoing session. Connection Closure At some point, +either Bob or Alice will want to end the SSL session. One approach would +be to let Bob end the SSL session by simply terminating the underlying +TCP connection---that is, by having Bob send a TCP FIN segment to Alice. +But such a naive design sets the stage for the truncation attack whereby +Trudy once again gets in the middle of an ongoing SSL session and ends +the session early with a TCP FIN. If Trudy were to do this, Alice would +think she received all of Bob's data when actuality she only received a +portion of it. The solution to this problem is to indicate in the type +field whether the record serves to terminate the SSL session. (Although +the SSL type is sent in the clear, it is authenticated at the receiver +using the record's MAC.) By including such a field, if Alice were to +receive a TCP FIN before receiving a closure SSL record, she would know +that something funny was going on. This completes our introduction to +SSL. We've seen that it uses many of the cryptography principles +discussed in Sections 8.2 and 8.3. Readers who want to explore SSL on +yet a deeper level can read Rescorla's highly readable book on SSL +\[Rescorla 2001\]. + + 8.7 Network-Layer Security: IPsec and Virtual Private Networks The IP +security protocol, more commonly known as IPsec, provides security at +the network layer. IPsec secures IP datagrams between any two +network-layer entities, including hosts and routers. As we will soon +describe, many institutions (corporations, government branches, +non-profit organizations, and so on) use IPsec to create virtual private +networks (VPNs) that run over the public Internet. Before getting into +the specifics of IPsec, let's step back and consider what it means to +provide confidentiality at the network layer. With network-layer +confidentiality between a pair of network entities (for example, between +two routers, between two hosts, or between a router and a host), the +sending entity encrypts the payloads of all the datagrams it sends to +the receiving entity. The encrypted payload could be a TCP segment, a +UDP segment, an ICMP message, and so on. If such a network-layer service +were in place, all data sent from one entity to the other---including +e-mail, Web pages, TCP handshake messages, and management messages (such +as ICMP and SNMP)---would be hidden from any third party that might be +sniffing the network. For this reason, network-layer security is said to +provide "blanket coverage." In addition to confidentiality, a +network-layer security protocol could potentially provide other security +services. For example, it could provide source authentication, so that +the receiving entity can verify the source of the secured datagram. A +network-layer security protocol could provide data integrity, so that +the receiving entity can check for any tampering of the datagram that +may have occurred while the datagram was in transit. A network-layer +security service could also provide replay-attack prevention, meaning +that Bob could detect any duplicate datagrams that an attacker might +insert. We will soon see that IPsec indeed provides mechanisms for all +these security services, that is, for confidentiality, source +authentication, data integrity, and replay-attack prevention. + +8.7.1 IPsec and Virtual Private Networks (VPNs) An institution that +extends over multiple geographical regions often desires its own IP +network, so that its hosts and servers can send data to each other in a +secure and confidential manner. To achieve this goal, the institution +could actually deploy a stand-alone physical network---including +routers, links, and a DNS infrastructure---that is completely separate +from the public Internet. Such a disjoint network, dedicated to a +particular institution, is called a private network. Not surprisingly, a +private network can be very costly, as the institution needs to +purchase, install, and maintain its own physical network infrastructure. + + Instead of deploying and maintaining a private network, many +institutions today create VPNs over the existing public Internet. With a +VPN, the institution's inter-office traffic is sent over the public +Internet rather than over a physically independent network. But to +provide confidentiality, the inter-office traffic is encrypted before it +enters the public Internet. A simple example of a VPN is shown in Figure +8.27. Here the institution consists of a headquarters, a branch office, +and traveling salespersons that typically access the Internet from their +hotel rooms. (There is only one salesperson shown in the figure.) In +this VPN, whenever two hosts within headquarters send IP datagrams to +each other or whenever two hosts within the branch office want to +communicate, they use good-old vanilla IPv4 (that is, without IPsec +services). However, when two of the institution's hosts + +Figure 8.27 Virtual private network (VPN) + +communicate over a path that traverses the public Internet, the traffic +is encrypted before it enters the Internet. To get a feel for how a VPN +works, let's walk through a simple example in the context of Figure +8.27. When a host in headquarters sends an IP datagram to a salesperson +in a hotel, the gateway router in headquarters converts the vanilla IPv4 +datagram into an IPsec datagram and then forwards this IPsec datagram +into the Internet. This IPsec datagram actually has a traditional IPv4 +header, so that the routers in the public Internet process the datagram +as if it were an ordinary IPv4 datagram---to them, the datagram is a +perfectly ordinary datagram. But, as shown Figure 8.27, the payload of +the IPsec datagram includes an IPsec header, which is used for IPsec +processing; furthermore, the payload of the + + IPsec datagram is encrypted. When the IPsec datagram arrives at the +salesperson's laptop, the OS in the laptop decrypts the payload (and +provides other security services, such as verifying data integrity) and +passes the unencrypted payload to the upper-layer protocol (for example, +to TCP or UDP). We have just given a high-level overview of how an +institution can employ IPsec to create a VPN. To see the forest through +the trees, we have brushed aside many important details. Let's now take +a closer look. + +8.7.2 The AH and ESP Protocols IPsec is a rather complex animal---it is +defined in more than a dozen RFCs. Two important RFCs are RFC 4301, +which describes the overall IP security architecture, and RFC 6071, +which provides an overview of the IPsec protocol suite. Our goal in this +textbook, as usual, is not simply to re-hash the dry and arcane RFCs, +but instead take a more operational and pedagogic approach to describing +the protocols. In the IPsec protocol suite, there are two principal +protocols: the Authentication Header (AH) protocol and the Encapsulation +Security Payload (ESP) protocol. When a source IPsec entity (typically a +host or a router) sends secure datagrams to a destination entity (also a +host or a router), it does so with either the AH protocol or the ESP +protocol. The AH protocol provides source authentication and data +integrity but does not provide confidentiality. The ESP protocol +provides source authentication, data integrity, and confidentiality. +Because confidentiality is often critical for VPNs and other IPsec +applications, the ESP protocol is much more widely used than the AH +protocol. In order to de-mystify IPsec and avoid much of its +complication, we will henceforth focus exclusively on the ESP protocol. +Readers wanting to learn also about the AH protocol are encouraged to +explore the RFCs and other online resources. + +8.7.3 Security Associations IPsec datagrams are sent between pairs of +network entities, such as between two hosts, between two routers, or +between a host and router. Before sending IPsec datagrams from source +entity to destination entity, the source and destination entities create +a network-layer logical connection. This logical connection is called a +security association (SA). An SA is a simplex logical connection; that +is, it is unidirectional from source to destination. If both entities +want to send secure datagrams to each other, then two SAs (that is, two +logical connections) need to be established, one in each direction. For +example, consider once again the institutional VPN in Figure 8.27. This +institution consists of a + + headquarters office, a branch office and, say, n traveling salespersons. +For the sake of example, let's suppose that there is bi-directional +IPsec traffic between headquarters and the branch office and +bidirectional IPsec traffic between headquarters and the salespersons. +In this VPN, how many SAs are there? To answer this question, note that +there are two SAs between the headquarters gateway router and the +branch-office gateway router (one in each direction); for each +salesperson's laptop, there are two SAs between the headquarters gateway +router and the laptop (again, one in each direction). So, in total, +there are (2+2n) SAs. Keep in mind, however, that not all traffic sent +into the Internet by the gateway routers or by the laptops will be IPsec +secured. For example, a host in headquarters may want to access a Web +server (such as Amazon or Google) in the public Internet. Thus, the +gateway router (and the laptops) will emit into the Internet both +vanilla IPv4 datagrams and secured IPsec datagrams. + +Figure 8.28 Security association (SA) from R1 to R2 + +Let's now take a look "inside" an SA. To make the discussion tangible +and concrete, let's do this in the context of an SA from router R1 to +router R2 in Figure 8.28. (You can think of Router R1 as the +headquarters gateway router and Router R2 as the branch office gateway +router from Figure 8.27.) Router R1 will maintain state information +about this SA, which will include: A 32-bit identifier for the SA, +called the Security Parameter Index (SPI) The origin interface of the SA +(in this case 200.168.1.100) and the destination interface of the SA (in +this case 193.68.2.23) The type of encryption to be used (for example, +3DES with CBC) The encryption key The type of integrity check (for +example, HMAC with MD5) The authentication key Whenever router R1 needs +to construct an IPsec datagram for forwarding over this SA, it accesses +this state information to determine how it should authenticate and +encrypt the datagram. Similarly, router R2 will maintain the same state +information for this SA and will use this information to authenticate +and decrypt any IPsec datagram that arrives from the SA. An IPsec entity +(router or host) often maintains state information for many SAs. For +example, in the VPN + + example in Figure 8.27 with n salespersons, the headquarters gateway +router maintains state information for (2+2n) SAs. An IPsec entity +stores the state information for all of its SAs in its Security +Association Database (SAD), which is a data structure in the entity's OS +kernel. + +8.7.4 The IPsec Datagram Having now described SAs, we can now describe +the actual IPsec datagram. IPsec has two different packet forms, one for +the so-called tunnel mode and the other for the so-called transport +mode. The tunnel mode, being more appropriate for VPNs, + +Figure 8.29 IPsec datagram format + +is more widely deployed than the transport mode. In order to further +de-mystify IPsec and avoid much of its complication, we henceforth focus +exclusively on the tunnel mode. Once you have a solid grip on the tunnel +mode, you should be able to easily learn about the transport mode on +your own. The packet format of the IPsec datagram is shown in Figure +8.29. You might think that packet formats are boring and insipid, but we +will soon see that the IPsec datagram actually looks and tastes like a +popular Tex-Mex delicacy! Let's examine the IPsec fields in the context +of Figure 8.28. Suppose router R1 receives an ordinary IPv4 datagram +from host 172.16.1.17 (in the headquarters network) which is destined to +host 172.16.2.48 (in the branch-office network). Router R1 uses the +following recipe to convert this "original IPv4 datagram" into an IPsec +datagram: Appends to the back of the original IPv4 datagram (which +includes the original header fields!) an "ESP trailer" field Encrypts +the result using the algorithm and key specified by the SA Appends to +the front of this encrypted quantity a field called "ESP header"; the +resulting package is called the "enchilada" Creates an authentication +MAC over the whole enchilada using the algorithm and key specified in + + the SA Appends the MAC to the back of the enchilada forming the payload +Finally, creates a brand new IP header with all the classic IPv4 header +fields (together normally 20 bytes long), which it appends before the +payload Note that the resulting IPsec datagram is a bona fide IPv4 +datagram, with the traditional IPv4 header fields followed by a payload. +But in this case, the payload contains an ESP header, the original IP +datagram, an ESP trailer, and an ESP authentication field (with the +original datagram and ESP trailer encrypted). The original IP datagram +has 172.16.1.17 for the source IP address and 172.16.2.48 for the +destination IP address. Because the IPsec datagram includes the original +IP datagram, these addresses are included (and encrypted) as part of the +payload of the IPsec packet. But what about the source and destination +IP addresses that are in the new IP header, that is, in the left-most +header of the IPsec datagram? As you might expect, they are set to the +source and destination router interfaces at the two ends of the tunnels, +namely, 200.168.1.100 and 193.68.2.23. Also, the protocol number in this +new IPv4 header field is not set to that of TCP, UDP, or SMTP, but +instead to 50, designating that this is an IPsec datagram using the ESP +protocol. After R1 sends the IPsec datagram into the public Internet, it +will pass through many routers before reaching R2. Each of these routers +will process the datagram as if it were an ordinary datagram---they are +completely oblivious to the fact that the datagram is carrying +IPsec-encrypted data. For these public Internet routers, because the +destination IP address in the outer header is R2, the ultimate +destination of the datagram is R2. Having walked through an example of +how an IPsec datagram is constructed, let's now take a closer look at +the ingredients in the enchilada. We see in Figure 8.29 that the ESP +trailer consists of three fields: padding; pad length; and next header. +Recall that block ciphers require the message to be encrypted to be an +integer multiple of the block length. Padding (consisting of meaningless +bytes) is used so that when added to the original datagram (along with +the pad length and next header fields), the resulting "message" is an +integer number of blocks. The pad-length field indicates to the +receiving entity how much padding was inserted (and thus needs to be +removed). The next header identifies the type (e.g., UDP) of data +contained in the payload-data field. The payload data (typically the +original IP datagram) and the ESP trailer are concatenated and then +encrypted. Appended to the front of this encrypted unit is the ESP +header, which is sent in the clear and consists of two fields: the SPI +and the sequence number field. The SPI indicates to the receiving entity +the SA to which the datagram belongs; the receiving entity can then +index its SAD with the SPI to determine the appropriate +authentication/decryption algorithms and keys. The sequence number field +is used to defend against replay attacks. The sending entity also +appends an authentication MAC. As stated earlier, the sending entity +calculates + + a MAC over the whole enchilada (consisting of the ESP header, the +original IP datagram, and the ESP trailer---with the datagram and +trailer being encrypted). Recall that to calculate a MAC, the sender +appends a secret MAC key to the enchilada and then calculates a +fixed-length hash of the result. When R2 receives the IPsec datagram, R2 +observes that the destination IP address of the datagram is R2 itself. +R2 therefore processes the datagram. Because the protocol field (in the +left-most IP header) is 50, R2 sees that it should apply IPsec ESP +processing to the datagram. First, peering into the enchilada, R2 uses +the SPI to determine to which SA the datagram belongs. Second, it +calculates the MAC of the enchilada and verifies that the MAC is +consistent with the value in the ESP MAC field. If it is, it knows that +the enchilada comes from R1 and has not been tampered with. Third, it +checks the sequence-number field to verify that the datagram is fresh +(and not a replayed datagram). Fourth, it decrypts the encrypted unit +using the decryption algorithm and key associated with the SA. Fifth, it +removes padding and extracts the original, vanilla IP datagram. And +finally, sixth, it forwards the original datagram into the branch office +network toward its ultimate destination. Whew, what a complicated +recipe, huh? Well no one ever said that preparing and unraveling an +enchilada was easy! There is actually another important subtlety that +needs to be addressed. It centers on the following question: When R1 +receives an (unsecured) datagram from a host in the headquarters +network, and that datagram is destined to some destination IP address +outside of headquarters, how does R1 know whether it should be converted +to an IPsec datagram? And if it is to be processed by IPsec, how does R1 +know which SA (of many SAs in its SAD) should be used to construct the +IPsec datagram? The problem is solved as follows. Along with a SAD, the +IPsec entity also maintains another data structure called the Security +Policy Database (SPD). The SPD indicates what types of datagrams (as a +function of source IP address, destination IP address, and protocol +type) are to be IPsec processed; and for those that are to be IPsec +processed, which SA should be used. In a sense, the information in a SPD +indicates "what" to do with an arriving datagram; the information in the +SAD indicates "how" to do it. Summary of IPsec Services So what services +does IPsec provide, exactly? Let us examine these services from the +perspective of an attacker, say Trudy, who is a woman-in-the-middle, +sitting somewhere on the path between R1 and R2 in Figure 8.28. Assume +throughout this discussion that Trudy does not know the authentication +and encryption keys used by the SA. What can and cannot Trudy do? First, +Trudy cannot see the original datagram. If fact, not only is the data in +the original datagram hidden from Trudy, but so is the protocol number, +the source IP address, and the destination IP address. For datagrams +sent over the SA, Trudy only knows that the datagram originated from +some host in 172.16.1.0/24 and is destined to some host in +172.16.2.0/24. She does not know if it is carrying TCP, UDP, or ICMP +data; she does not know if it is carrying HTTP, SMTP, or some other type +of application data. This confidentiality thus goes a lot farther than +SSL. Second, suppose Trudy tries to tamper with a datagram in the SA by +flipping some of its bits. When this tampered datagram arrives at R2, it +will fail the integrity check (using the MAC), thwarting + + Trudy's vicious attempts once again. Third, suppose Trudy tries to +masquerade as R1, creating a IPsec datagram with source 200.168.1.100 +and destination 193.68.2.23. Trudy's attack will be futile, as this +datagram will again fail the integrity check at R2. Finally, because +IPsec includes sequence numbers, Trudy will not be able create a +successful replay attack. In summary, as claimed at the beginning of +this section, IPsec provides---between any pair of devices that process +packets through the network layer--- confidentiality, source +authentication, data integrity, and replay-attack prevention. + +8.7.5 IKE: Key Management in IPsec When a VPN has a small number of end +points (for example, just two routers as in Figure 8.28), the network +administrator can manually enter the SA information +(encryption/authentication algorithms and keys, and the SPIs) into the +SADs of the endpoints. Such "manual keying" is clearly impractical for a +large VPN, which may consist of hundreds or even thousands of IPsec +routers and hosts. Large, geographically distributed deployments require +an automated mechanism for creating the SAs. IPsec does this with the +Internet Key Exchange (IKE) protocol, specified in RFC 5996. IKE has +some similarities with the handshake in SSL (see Section 8.6). Each +IPsec entity has a certificate, which includes the entity's public key. +As with SSL, the IKE protocol has the two entities exchange +certificates, negotiate authentication and encryption algorithms, and +securely exchange key material for creating session keys in the IPsec +SAs. Unlike SSL, IKE employs two phases to carry out these tasks. Let's +investigate these two phases in the context of two routers, R1 and R2, +in Figure 8.28. The first phase consists of two exchanges of message +pairs between R1 and R2: During the first exchange of messages, the two +sides use Diffie-Hellman (see Homework Problems) to create a +bi-directional IKE SA between the routers. To keep us all confused, this +bi-directional IKE SA is entirely different from the IPsec SAs discussed +in Sections 8.6.3 and 8.6.4. The IKE SA provides an authenticated and +encrypted channel between the two routers. During this first +message-pair exchange, keys are established for encryption and +authentication for the IKE SA. Also established is a master secret that +will be used to compute IPSec SA keys later in phase 2. Observe that +during this first step, RSA public and private keys are not used. In +particular, neither R1 nor R2 reveals its identity by signing a message +with its private key. During the second exchange of messages, both sides +reveal their identity to each other by signing their messages. However, +the identities are not revealed to a passive sniffer, since the messages +are sent over the secured IKE SA channel. Also during this phase, the +two sides negotiate the IPsec encryption and authentication algorithms +to be employed by the IPsec SAs. In phase 2 of IKE, the two sides create +an SA in each direction. At the end of phase 2, the encryption + + and authentication session keys are established on both sides for the +two SAs. The two sides can then use the SAs to send secured datagrams, +as described in Sections 8.7.3 and 8.7.4. The primary motivation for +having two phases in IKE is computational cost---since the second phase +doesn't involve any public-key cryptography, IKE can generate a large +number of SAs between the two IPsec entities with relatively little +computational cost. + + 8.8 Securing Wireless LANs Security is a particularly important concern +in wireless networks, where radio waves carrying frames can propagate +far beyond the building containing the wireless base station and hosts. +In this section we present a brief introduction to wireless security. +For a more in-depth treatment, see the highly readable book by Edney and +Arbaugh \[Edney 2003\]. The issue of security in 802.11 has attracted +considerable attention in both technical circles and in the media. While +there has been considerable discussion, there has been little +debate---there seems to be universal agreement that the original 802.11 +specification contains a number of serious security flaws. Indeed, +public domain software can now be downloaded that exploits these holes, +making those who use the vanilla 802.11 security mechanisms as open to +security attacks as users who use no security features at all. In the +following section, we discuss the security mechanisms initially +standardized in the 802.11 specification, known collectively as Wired +Equivalent Privacy (WEP). As the name suggests, WEP is meant to provide +a level of security similar to that found in wired networks. We'll then +discuss a few of the security holes in WEP and discuss the 802.11i +standard, a fundamentally more secure version of 802.11 adopted in 2004. + +8.8.1 Wired Equivalent Privacy (WEP) The IEEE 802.11 WEP protocol was +designed in 1999 to provide authentication and data encryption between a +host and a wireless access point (that is, base station) using a +symmetric shared key approach. WEP does not specify a key management +algorithm, so it is assumed that the host and wireless access point have +somehow agreed on the key via an out-of-band method. Authentication is +carried out as follows: + +1. A wireless host requests authentication by an access point. + +2. The access point responds to the authentication request with a + 128-byte nonce value. + +3. The wireless host encrypts the nonce using the symmetric key that it + shares with the access point. + +4. The access point decrypts the host-encrypted nonce. If the decrypted + nonce matches the nonce value originally sent to the host, then the + host is + + authenticated by the access point. The WEP data encryption algorithm is +illustrated in Figure 8.30. A secret 40-bit symmetric key, KS, is +assumed to be known by both a host and the access point. In addition, a +24-bit Initialization Vector (IV) is appended to the 40-bit key to +create a 64-bit key that will be used to encrypt a single frame. The IV +will + +Figure 8.30 802.11 WEP protocol + +change from one frame to another, and hence each frame will be encrypted +with a different 64-bit key. Encryption is performed as follows. First a +4-byte CRC value (see Section 6.2) is computed for the data payload. The +payload and the four CRC bytes are then encrypted using the RC4 stream +cipher. We will not cover the details of RC4 here (see \[Schneier 1995\] +and \[Edney 2003\] for details). For our purposes, it is enough to know +that when presented with a key value (in this case, the 64-bit (KS, IV) +key), the RC4 algorithm produces a stream of key values, +k1IV,k2IV,k3IV,... that are used to encrypt the data and CRC value in a +frame. For practical purposes, we can think of these operations being +performed a byte at a time. Encryption is performed by XOR-ing the ith +byte of data, di, with the ith key, kiIV, in the stream of key values +generated by the (KS, IV) pair to produce the ith byte of ciphertext, +ci: ci=di⊕kiIV The IV value changes from one frame to the next and is +included in plaintext in the header of each WEP-encrypted 802.11 frame, +as shown in Figure 8.30. The receiver takes the secret 40-bit symmetric +key that it shares with the sender, appends the IV, and uses the +resulting 64-bit key (which is identical to the key used by the sender +to perform encryption) to decrypt the frame: di=ci⊕kiIV Proper use of +the RC4 algorithm requires that the same 64-bit key value never be used +more than once. Recall that the WEP key changes on a frame-by-frame +basis. For a given KS (which changes rarely, if ever), this means that +there are only 224 unique keys. If these keys are chosen randomly, we +can show + + \[Edney 2003\] that the probability of having chosen the same IV value +(and hence used the same 64-bit key) is more than 99 percent after only +12,000 frames. With 1 Kbyte frame sizes and a data transmission rate of +11 Mbps, only a few seconds are needed before 12,000 frames are +transmitted. Furthermore, since the IV is transmitted in plaintext in +the frame, an eavesdropper will know whenever a duplicate IV value is +used. To see one of the several problems that occur when a duplicate key +is used, consider the following chosen-plaintext attack taken by Trudy +against Alice. Suppose that Trudy (possibly using IP spoofing) sends a +request (for example, an HTTP or FTP request) to Alice to transmit a +file with known content, d1, d2, d3, d4,.... Trudy also observes the +encrypted data c1, c2, c3, c4,.... Since di=ci⊕kiIV, if we XOR ci with +each side of this equality we have di⊕ci=kiIV With this relationship, +Trudy can use the known values of di and ci to compute kiIV. The next +time Trudy sees the same value of IV being used, she will know the key +sequence k1IV,k2IV,k3IV,... and will thus be able to decrypt the +encrypted message. There are several additional security concerns with +WEP as well. \[Fluhrer 2001\] described an attack exploiting a known +weakness in RC4 when certain weak keys are chosen. \[Stubblefield 2002\] +discusses efficient ways to implement and exploit this attack. Another +concern with WEP involves the CRC bits shown in Figure 8.30 and +transmitted in the 802.11 frame to detect altered bits in the payload. +However, an attacker who changes the encrypted content (e.g., +substituting gibberish for the original encrypted data), computes a CRC +over the substituted gibberish, and places the CRC into a WEP frame can +produce an 802.11 frame that will be accepted by the receiver. What is +needed here are message integrity techniques such as those we studied in +Section 8.3 to detect content tampering or substitution. For more +details of WEP security, see \[Edney 2003; Wright 2015\] and the +references therein. + +8.8.2 IEEE 802.11i Soon after the 1999 release of IEEE 802.11, work +began on developing a new and improved version of 802.11 with stronger +security mechanisms. The new standard, known as 802.11i, underwent final +ratification in 2004. As we'll see, while WEP provided relatively weak +encryption, only a single way to perform authentication, and no key +distribution mechanisms, IEEE 802.11i provides for much stronger forms +of encryption, an extensible set of authentication mechanisms, and a key +distribution mechanism. In the following, we present an overview of +802.11i; an excellent (streaming audio) technical overview of 802.11i is +\[TechOnline 2012\]. Figure 8.31 overviews the 802.11i framework. In +addition to the wireless client and access point, + + 802.11i defines an authentication server with which the AP can +communicate. Separating the authentication server from the AP allows one +authentication server to serve many APs, centralizing the (often +sensitive) decisions + +Figure 8.31 802.11i: Four phases of operation + +regarding authentication and access within the single server, and +keeping AP costs and complexity low. 802.11i operates in four phases: + +1. Discovery. In the discovery phase, the AP advertises its presence + and the forms of authentication and encryption that can be provided + to the wireless client node. The client then requests the specific + forms of authentication and encryption that it desires. Although the + client and AP are already exchanging messages, the client has not + yet been authenticated nor does it have an encryption key, and so + several more steps will be required before the client can + communicate with an arbitrary remote host over the wireless channel. + +2. Mutual authentication and Master Key (MK) generation. Authentication + takes place between the wireless client and the authentication + server. In this phase, the access point acts essentially as a relay, + forwarding messages between the client and the authentication + server. The Extensible Authentication Protocol (EAP) \[RFC 3748\] + defines the end-to-end message formats used in a simple + request/response mode of interaction between the client and + authentication server. As shown in Figure 8.32, EAP messages are + encapsulated using EAPoL (EAP over LAN, \[IEEE 802.1X\]) and sent + over the 802.11 wireless link. These EAP messages + + are then decapsulated at the access point, and then re-encapsulated +using the RADIUS protocol for transmission over UDP/IP to the +authentication server. While + +Figure 8.32 EAP is an end-to-end protocol. EAP messages are encapsulated +using EAPoL over the wireless link between the client and the access +point, and using RADIUS over UDP/IP between the access point and the +authentication server + +the RADIUS server and protocol \[RFC 2865\] are not required by the +802.11i protocol, they are de facto standard components for 802.11i. The +recently standardized DIAMETER protocol \[RFC 3588\] is likely to +replace RADIUS in the near future. With EAP, the authentication server +can choose one of a number of ways to perform authentication. While +802.11i does not mandate a particular authentication method, the EAPTLS +authentication scheme \[RFC 5216\] is often used. EAP-TLS uses public +key techniques (including nonce encryption and message digests) similar +to those we studied in Section 8.3 to allow the client and the +authentication server to mutually authenticate each other, and to derive +a Master Key (MK) that is known to both parties. + +3. Pairwise Master Key (PMK) generation. The MK is a shared secret + known only to the client and the authentication server, which they + each use to generate a second key, the Pairwise Master Key (PMK). + The authentication server then sends the PMK to the AP. This is + where we wanted to be! The client and AP now have a shared key + (recall that in WEP, the problem of key distribution was not + addressed at all) and have mutually authenticated each other. + They're just about ready to get down to business. + +4. Temporal Key (TK) generation. With the PMK, the wireless client and + AP can now generate additional keys that will be used for + communication. Of particular interest is the Temporal Key (TK), + which will be used to perform the link-level encryption of data sent + over the wireless link and to an arbitrary remote host. 802.11i + provides several forms of encryption, including an AES-based + encryption scheme and a + + strengthened version of WEP encryption. + + 8.9 Operational Security: Firewalls and Intrusion Detection Systems +We've seen throughout this chapter that the Internet is not a very safe +place---bad guys are out there, wreaking all sorts of havoc. Given the +hostile nature of the Internet, let's now consider an organization's +network and the network administrator who administers it. From a network +administrator's point of view, the world divides quite neatly into two +camps---the good guys (who belong to the organization's network, and who +should be able to access resources inside the organization's network in +a relatively unconstrained manner) and the bad guys (everyone else, +whose access to network resources must be carefully scrutinized). In +many organizations, ranging from medieval castles to modern corporate +office buildings, there is a single point of entry/exit where both good +guys and bad guys entering and leaving the organization are +security-checked. In a castle, this was done at a gate at one end of the +drawbridge; in a corporate building, this is done at the security desk. +In a computer network, when traffic entering/leaving a network is +security-checked, logged, dropped, or forwarded, it is done by +operational devices known as firewalls, intrusion detection systems +(IDSs), and intrusion prevention systems (IPSs). + +8.9.1 Firewalls A firewall is a combination of hardware and software +that isolates an organization's internal network from the Internet at +large, allowing some packets to pass and blocking others. A firewall +allows a network administrator to control access between the outside +world and resources within the administered network by managing the +traffic flow to and from these resources. A firewall has three goals: +All traffic from outside to inside, and vice versa, passes through the +firewall. Figure 8.33 shows a firewall, sitting squarely at the boundary +between the administered network and the rest of the Internet. While +large organizations may use multiple levels of firewalls or distributed +firewalls \[Skoudis 2006\], locating a firewall at a single access point +to the network, as shown in Figure 8.33, makes it easier to manage and +enforce a security-access policy. Only authorized traffic, as defined by +the local security policy, will be allowed to pass. With all traffic +entering and leaving the institutional network passing through the +firewall, the firewall can restrict access to authorized traffic. The +firewall itself is immune to penetration. The firewall itself is a +device connected to the network. If not designed or installed properly, +it can be compromised, in which case it provides only + + a false sense of security (which is worse than no firewall at all!). + +Figure 8.33 Firewall placement between the administered network and the +outside world + +Cisco and Check Point are two of the leading firewall vendors today. You +can also easily create a firewall (packet filter) from a Linux box using +iptables (public-domain software that is normally shipped with Linux). +Furthermore, as discussed in Chapters 4 and 5, firewalls are now +frequently implemented in routers and controlled remotely using SDNs. +Firewalls can be classified in three categories: traditional packet +filters, stateful filters, and application gateways. We'll cover each of +these in turn in the following subsections. Traditional Packet Filters +As shown in Figure 8.33, an organization typically has a gateway router +connecting its internal network to its ISP (and hence to the larger +public Internet). All traffic leaving and entering the internal network +passes through this router, and it is at this router where packet +filtering occurs. A packet filter examines each datagram in isolation, +determining whether the datagram should be allowed to pass or should be +dropped based on administrator-specific rules. Filtering decisions are +typically based on: IP source or destination address Protocol type in IP +datagram field: TCP, UDP, ICMP, OSPF, and so on TCP or UDP source and +destination port + + Table 8.5 Policies and corresponding filtering rules for an +organization's network 130.207/16 with Web server at 130.207.244.203 +Policy + +Firewall Setting + +No outside Web access. + +Drop all outgoing packets to any IP address, port 80. + +No incoming TCP connections, except those for + +Drop all incoming TCP SYN packets to any + +organization's public Web server only. + +IP except 130.207.244.203, port 80. + +Prevent Web-radios from eating up the + +Drop all incoming UDP packets---except DNS + +available bandwidth. + +packets. + +Prevent your network from being used for a + +Drop all ICMP ping packets going to a + +smurf DoS attack. + +"broadcast" address (eg 130.207.255.255). + +Prevent your network from being tracerouted. + +Drop all outgoing ICMP TTL expired traffic. + +TCP flag bits: SYN, ACK, and so on ICMP message type Different rules for +datagrams leaving and entering the network Different rules for the +different router interfaces A network administrator configures the +firewall based on the policy of the organization. The policy may take +user productivity and bandwidth usage into account as well as the +security concerns of an organization. Table 8.5 lists a number of +possible polices an organization may have, and how they would be +addressed with a packet filter. For example, if the organization doesn't +want any incoming TCP connections except those for its public Web +server, it can block all incoming TCP SYN segments except TCP SYN +segments with destination port 80 and the destination IP address +corresponding to the Web server. If the organization doesn't want its +users to monopolize access bandwidth with Internet radio applications, +it can block all not-critical UDP traffic (since Internet radio is often +sent over UDP). If the organization doesn't want its internal network to +be mapped (tracerouted) by an outsider, it can block all ICMP TTL +expired messages leaving the organization's network. A filtering policy +can be based on a combination of addresses and port numbers. For +example, a filtering router could forward all Telnet datagrams (those +with a port number of 23) except those going to and coming from a list +of specific IP addresses. This policy permits Telnet connections to and +from hosts on the allowed list. Unfortunately, basing the policy on +external addresses provides no protection against + + datagrams that have had their source addresses spoofed. Filtering can +also be based on whether or not the TCP ACK bit is set. This trick is +quite useful if an organization wants to let its internal clients +connect to external servers but wants to prevent external clients from +connecting to internal servers. Table 8.6 An access control list for a +router interface action + +allow + +source address + +222.22/16 + +dest address + +source + +dest + +flag + +port + +port + +bit + +TCP + +> 1023 + +80 + +any + +222.22/16 + +TCP + +80 + +> 1023 + +ACK + +outside of + +UDP + +> 1023 + +53 + +--- + +222.22/16 + +UDP + +53 + +> 1023 + +--- + +all + +all + +all + +all + +all + +outside of + +protocol + +222.22/16 allow + +outside of 222.22/16 + +allow + +222.22/16 + +222.22/16 allow + +outside of 222.22/16 + +deny + +all + +Recall from Section 3.5 that the first segment in every TCP connection +has the ACK bit set to 0, whereas all the other segments in the +connection have the ACK bit set to 1. Thus, if an organization wants to +prevent external clients from initiating connections to internal +servers, it simply filters all incoming segments with the ACK bit set to +0. This policy kills all TCP connections originating from the outside, +but permits connections originating internally. Firewall rules are +implemented in routers with access control lists, with each router +interface having its own list. An example of an access control list for +an organization 222.22/16 is shown in Table 8.6. This access control +list is for an interface that connects the router to the organization's +external ISPs. Rules are applied to each datagram that passes through +the interface from top to bottom. The first two rules together allow +internal users to surf the Web: The first rule allows any TCP packet +with destination port 80 to leave the organization's network; the second +rule allows any TCP packet with source port 80 and the ACK bit set to +enter the organization's network. Note that if an external source +attempts to establish a TCP connection with an internal host, the +connection will be blocked, even if the source or destination port is +80. The second two rules together allow DNS packets to enter and leave +the organization's + + network. In summary, this rather restrictive access control list blocks +all traffic except Web traffic initiated from within the organization +and DNS traffic. \[CERT Filtering 2012\] provides a list of recommended +port/protocol packet filterings to avoid a number of well-known security +holes in existing network applications. Stateful Packet Filters In a +traditional packet filter, filtering decisions are made on each packet +in isolation. Stateful filters actually track TCP connections, and use +this knowledge to make filtering decisions. Table 8.7 Connection table +for stateful filter source address + +dest address + +source port + +dest port + +222.22.1.7 + +37.96.87.123 + +12699 + +80 + +222.22.93.2 + +199.1.205.23 + +37654 + +80 + +222.22.65.143 + +203.77.240.43 + +48712 + +80 + +To understand stateful filters, let's reexamine the access control list +in Table 8.6. Although rather restrictive, the access control list in +Table 8.6 nevertheless allows any packet arriving from the outside with +ACK = 1 and source port 80 to get through the filter. Such packets could +be used by attackers in attempts to crash internal systems with +malformed packets, carry out denial-of-service attacks, or map the +internal network. The naive solution is to block TCP ACK packets as +well, but such an approach would prevent the organization's internal +users from surfing the Web. Stateful filters solve this problem by +tracking all ongoing TCP connections in a connection table. This is +possible because the firewall can observe the beginning of a new +connection by observing a three-way handshake (SYN, SYNACK, and ACK); +and it can observe the end of a connection when it sees a FIN packet for +the connection. The firewall can also (conservatively) assume that the +connection is over when it hasn't seen any activity over the connection +for, say, 60 seconds. An example connection table for a firewall is +shown in Table 8.7. This connection table indicates that there are +currently three ongoing TCP connections, all of which have been +initiated from within the organization. Additionally, the stateful +filter includes a new column, "check connection," in its access control +list, as shown in Table 8.8. Note that Table 8.8 is identical to the +access control list in Table 8.6, except now it indicates that the +connection should be checked for two of the rules. Let's walk through +some examples to see how the connection table and the extended access +control list + + work hand-in-hand. Suppose an attacker attempts to send a malformed +packet into the organization's network by sending a datagram with TCP +source port 80 and with the ACK flag set. Further suppose that this +packet has source port number 12543 and source IP address 150.23.23.155. +When this packet reaches the firewall, the firewall checks the access +control list in Table 8.7, which indicates that the connection table +must also be checked before permitting this packet to enter the +organization's network. The firewall duly checks the connection table, +sees that this packet is not part of an ongoing TCP connection, and +rejects the packet. As a second example, suppose that an internal user +wants to surf an external Web site. Because this user first sends a TCP +SYN segment, the user's TCP connection gets recorded in the connection +table. When Table 8.8 Access control list for stateful filter action + +allow + +source address + +222.22/16 + +dest address + +outside of + +protocol + +source + +dest + +flag + +check + +port + +port + +bit + +conxion + +TCP + +> 1023 + +80 + +any + +TCP + +80 + +ACK + +222.22/16 allow + +outside of + +222.22/16 + +222.22/16 allow + +222.22/16 + +X + +1023 outside of + +UDP + +> 1023 + +53 + +--- + +UDP + +53 + +--- + +222.22/16 allow + +outside of + +222.22/16 + +222.22/16 deny + +all + +X + +1023 all + +all + +all + +all + +all + +the Web server sends back packets (with the ACK bit necessarily set), +the firewall checks the table and sees that a corresponding connection +is in progress. The firewall will thus let these packets pass, thereby +not interfering with the internal user's Web surfing activity. +Application Gateway In the examples above, we have seen that +packet-level filtering allows an organization to perform coarse-grain +filtering on the basis of the contents of IP and TCP/UDP headers, +including IP addresses, port numbers, and acknowledgment bits. But what +if an organization wants to provide a Telnet service to a restricted set +of internal users (as opposed to IP addresses)? And what if the +organization wants such privileged users to authenticate themselves +first before being allowed to create Telnet sessions to the + + outside world? Such tasks are beyond the capabilities of traditional and +stateful filters. Indeed, information about the identity of the internal +users is application-layer data and is not included in the IP/TCP/UDP +headers. To have finer-level security, firewalls must combine packet +filters with application gateways. Application gateways look beyond the +IP/TCP/UDP headers and make policy decisions based on application data. +An application gateway is an application-specific server through which +all application data (inbound and outbound) must pass. Multiple +application gateways can run on the same host, but each gateway is a +separate server with its own processes. To get some insight into +application gateways, let's design a firewall that allows only a +restricted set of internal users to Telnet outside and prevents all +external clients from Telneting inside. Such a policy can be +accomplished by implementing + +Figure 8.34 Firewall consisting of an application gateway and a filter + +a combination of a packet filter (in a router) and a Telnet application +gateway, as shown in Figure 8.34. The router's filter is configured to +block all Telnet connections except those that originate from the IP +address of the application gateway. Such a filter configuration forces +all outbound Telnet connections to pass through the application gateway. +Consider now an internal user who wants to Telnet to the outside world. +The user must first set up a Telnet session with the application +gateway. An application running in the gateway, which listens for +incoming Telnet sessions, prompts the user for a user ID and password. +When the user supplies this information, the application gateway checks +to see if the user has + + permission to Telnet to the outside world. If not, the Telnet connection +from the internal user to the gateway is terminated by the gateway. If +the user has permission, then the gateway (1) prompts the user for the +host name of the external host to which the user wants to connect, (2) +sets up a Telnet session between the gateway and the external host, and +(3) relays to the external host all data arriving from the user, and +relays to the user all data arriving from the external host. Thus, the +Telnet application gateway not only performs user authorization but also +acts as a Telnet server and a Telnet client, relaying information +between the user and the remote Telnet server. Note that the filter will +permit step 2 because the gateway initiates the Telnet connection to the +outside world. + +CASE HISTORY ANONYMITY AND PRIVACY Suppose you want to visit a +controversial Web site (for example, a political activist site) and you +(1) don't want to reveal your IP address to the Web site, (2) don't want +your local ISP (which may be your home or office ISP) to know that you +are visiting the site, and (3) don't want your local ISP to see the data +you are exchanging with the site. If you use the traditional approach of +connecting directly to the Web site without any encryption, you fail on +all three counts. Even if you use SSL, you fail on the first two counts: +Your source IP address is presented to the Web site in every datagram +you send; and the destination address of every packet you send can +easily be sniffed by your local ISP. To obtain privacy and anonymity, +you can instead use a combination of a trusted proxy server and SSL, as +shown in Figure 8.35. With this approach, you first make an SSL +connection to the trusted proxy. You then send, into this SSL +connection, an HTTP request for a page at the desired site. When the +proxy receives the SSL-encrypted HTTP request, it decrypts the request +and forwards the cleartext HTTP request to the Web site. The Web site +then responds to the proxy, which in turn forwards the response to you +over SSL. Because the Web site only sees the IP address of the proxy, +and not of your client's address, you are indeed obtaining anonymous +access to the Web site. And because all traffic between you and the +proxy is encrypted, your local ISP cannot invade your privacy by logging +the site you visited or recording the data you are exchanging. Many +companies today (such as proxify .com) make available such proxy +services. Of course, in this solution, your proxy knows everything: It +knows your IP address and the IP address of the site you're surfing; and +it can see all the traffic in cleartext exchanged between you and the +Web site. Such a solution, therefore, is only as good as the +trustworthiness of the proxy. A more robust approach, taken by the TOR +anonymizing and privacy service, is to route your traffic through a +series of non-colluding proxy servers \[TOR 2016\]. In particular, TOR +allows independent individuals to contribute proxies to its proxy pool. +When a user connects to a server using TOR, TOR randomly chooses (from +its proxy pool) a chain of three proxies and routes all traffic between +client and server over the chain. In this manner, assuming the proxies +do not collude, no one knows that communication took place between your +IP address and the + + target Web site. Furthermore, although cleartext is sent between the +last proxy and the server, the last proxy doesn't know what IP address +is sending and receiving the cleartext. + +Figure 8.35 Providing anonymity and privacy with a proxy + +Internal networks often have multiple application gateways, for example, +gateways for Telnet, HTTP, FTP, and e-mail. In fact, an organization's +mail server (see Section 2.3) and Web cache are application gateways. +Application gateways do not come without their disadvantages. First, a +different application gateway is needed for each application. Second, +there is a performance penalty to be paid, since all data will be +relayed via the gateway. This becomes a concern particularly when +multiple users or applications are using the same gateway machine. +Finally, the client software must know how to contact the gateway when +the user makes a request, and must know how to tell the application +gateway what external server to connect to. + +8.9.2 Intrusion Detection Systems We've just seen that a packet filter +(traditional and stateful) inspects IP, TCP, UDP, and ICMP header fields +when deciding which packets to let pass through the firewall. However, +to detect many attack types, we need to perform deep packet inspection, +that is, look beyond the header fields and into the actual application +data that the packets carry. As we saw in Section 8.9.1, application +gateways often do deep packet inspection. But an application gateway +only does this for a specific application. Clearly, there is a niche for +yet another device---a device that not only examines the headers of all +packets passing through it (like a packet filter), but also performs +deep packet inspection (unlike a packet filter). When such a device +observes a suspicious packet, or a suspicious series of packets, it +could prevent those packets from entering the organizational network. +Or, because the activity is only + + deemed as suspicious, the device could let the packets pass, but send +alerts to a network administrator, who can then take a closer look at +the traffic and take appropriate actions. A device that generates alerts +when it observes potentially malicious traffic is called an intrusion +detection system (IDS). A device that filters out suspicious traffic is +called an intrusion prevention system (IPS). In this section we study +both systems---IDS and IPS---together, since the most interesting +technical aspect of these systems is how they detect suspicious traffic +(and not whether they send alerts or drop packets). We will henceforth +collectively refer to IDS systems and IPS systems as IDS systems. An IDS +can be used to detect a wide range of attacks, including network mapping +(emanating, for example, from nmap), port scans, TCP stack scans, DoS +bandwidth-flooding attacks, worms and viruses, OS vulnerability attacks, +and application vulnerability attacks. (See Section 1.6 for a survey of +network attacks.) Today, thousands of organizations employ IDS systems. +Many of these deployed systems are proprietary, marketed by Cisco, Check +Point, and other security equipment vendors. But many of the deployed +IDS systems are public-domain systems, such as the immensely popular +Snort IDS system (which we'll discuss shortly). An organization may +deploy one or more IDS sensors in its organizational network. Figure +8.36 shows an organization that has three IDS sensors. When multiple +sensors are deployed, they typically work in concert, sending +information about + + Figure 8.36 An organization deploying a filter, an application gateway, +and IDS sensors + +suspicious traffic activity to a central IDS processor, which collects +and integrates the information and sends alarms to network +administrators when deemed appropriate. In Figure 8.36, the organization +has partitioned its network into two regions: a high-security region, +protected by a packet filter and an application gateway and monitored by +IDS sensors; and a lower-security region---referred to as the +demilitarized zone (DMZ)---which is protected only by the packet filter, +but also monitored by IDS sensors. Note that the DMZ includes the +organization's servers that need to communicate with the outside world, +such as its public Web server and its authoritative DNS server. You may +be wondering at this stage, why multiple IDS sensors? Why not just place +one IDS sensor just behind the packet filter (or even integrated with +the packet filter) in Figure 8.36? We will soon see that an IDS not only +needs to do deep packet inspection, but must also compare each passing +packet with tens of thousands of "signatures"; this can be a significant +amount of processing, particularly if the organization receives +gigabits/sec of traffic from the Internet. By placing the IDS sensors +further downstream, each sensor sees only a fraction of the +organization's traffic, and can more easily keep up. Nevertheless, +high-performance IDS and IPS systems are available today, and many +organizations can actually get by with just one sensor located near its +access router. IDS systems are broadly classified as either +signature-based systems or anomaly-based systems. A signature-based IDS +maintains an extensive database of attack signatures. Each signature is +a set of rules pertaining to an intrusion activity. A signature may +simply be a list of characteristics about a single packet (e.g., source +and destination port numbers, protocol type, and a specific string of +bits in the packet payload), or may relate to a series of packets. The +signatures are normally created by skilled network security engineers +who research known attacks. An organization's network administrator can +customize the signatures or add its own to the database. Operationally, +a signature-based IDS sniffs every packet passing by it, comparing each +sniffed packet with the signatures in its database. If a packet (or +series of packets) matches a signature in the database, the IDS +generates an alert. The alert could be sent to the network administrator +in an e-mail message, could be sent to the network management system, or +could simply be logged for future inspection. Signature-based IDS +systems, although widely deployed, have a number of limitations. Most +importantly, they require previous knowledge of the attack to generate +an accurate signature. In other words, a signature-based IDS is +completely blind to new attacks that have yet to be recorded. Another +disadvantage is that even if a signature is matched, it may not be the +result of an attack, so that a false alarm is generated. Finally, +because every packet must be compared with an extensive collection of +signatures, the IDS can become overwhelmed with processing and actually +fail to detect many malicious + + packets. An anomaly-based IDS creates a traffic profile as it observes +traffic in normal operation. It then looks for packet streams that are +statistically unusual, for example, an inordinate percentage of ICMP +packets or a sudden exponential growth in port scans and ping sweeps. +The great thing about anomaly-based IDS systems is that they don't rely +on previous knowledge about existing attacks---that is, they can +potentially detect new, undocumented attacks. On the other hand, it is +an extremely challenging problem to distinguish between normal traffic +and statistically unusual traffic. To date, most IDS deployments are +primarily signature-based, although some include some anomaly-based +features. Snort Snort is a public-domain, open source IDS with hundreds +of thousands of existing deployments \[Snort 2012; Koziol 2003\]. It can +run on Linux, UNIX, and Windows platforms. It uses the generic sniffing +interface libpcap, which is also used by Wireshark and many other packet +sniffers. It can easily handle 100 Mbps of traffic; for installations +with gibabit/sec traffic rates, multiple Snort sensors may be needed. To +gain some insight into Snort, let's take a look at an example of a Snort +signature: + +alert icmp \$EXTERNAL_NET any -\> \$HOME_NET any (msg:"ICMP PING NMAP"; +dsize: 0; itype: 8;) + +This signature is matched by any ICMP packet that enters the +organization's network ( \$HOME_NET ) from the outside ( \$EXTERNAL_NET +), is of type 8 (ICMP ping), and has an empty payload (dsize = 0). Since +nmap (see Section 1.6) generates ping packets with these specific +characteristics, this signature is designed to detect nmap ping sweeps. +When a packet matches this signature, Snort generates an alert that +includes the message "ICMP PING NMAP" . Perhaps what is most impressive +about Snort is the vast community of users and security experts that +maintain its signature database. Typically within a few hours of a new +attack, the Snort community writes and releases an attack signature, +which is then downloaded by the hundreds of thousands of Snort +deployments distributed around the world. Moreover, using the Snort +signature syntax, network administrators can tailor the signatures to +their own organization's needs by either modifying existing signatures +or creating entirely new ones. + + 8.10 Summary In this chapter, we've examined the various mechanisms that +our secret lovers, Bob and Alice, can use to communicate securely. We've +seen that Bob and Alice are interested in confidentiality (so they alone +are able to understand the contents of a transmitted message), end-point +authentication (so they are sure that they are talking with each other), +and message integrity (so they are sure that their messages are not +altered in transit). Of course, the need for secure communication is not +confined to secret lovers. Indeed, we saw in Sections 8.5 through 8.8 +that security can be used in various layers in a network architecture to +protect against bad guys who have a large arsenal of possible attacks at +hand. The first part of this chapter presented various principles +underlying secure communication. In Section 8.2, we covered +cryptographic techniques for encrypting and decrypting data, including +symmetric key cryptography and public key cryptography. DES and RSA were +examined as specific case studies of these two major classes of +cryptographic techniques in use in today's networks. In Section 8.3, we +examined two approaches for providing message integrity: message +authentication codes (MACs) and digital signatures. The two approaches +have a number of parallels. Both use cryptographic hash functions and +both techniques enable us to verify the source of the message as well as +the integrity of the message itself. One important difference is that +MACs do not rely on encryption whereas digital signatures require a +public key infrastructure. Both techniques are extensively used in +practice, as we saw in Sections 8.5 through 8.8. Furthermore, digital +signatures are used to create digital certificates, which are important +for verifying the validity of public keys. In Section 8.4, we examined +endpoint authentication and introduced nonces to defend against the +replay attack. In Sections 8.5 through 8.8 we examined several security +networking protocols that enjoy extensive use in practice. We saw that +symmetric key cryptography is at the core of PGP, SSL, IPsec, and +wireless security. We saw that public key cryptography is crucial for +both PGP and SSL. We saw that PGP uses digital signatures for message +integrity, whereas SSL and IPsec use MACs. Having now an understanding +of the basic principles of cryptography, and having studied how these +principles are actually used, you are now in position to design your own +secure network protocols! Armed with the techniques covered in Sections +8.2 through 8.8, Bob and Alice can communicate securely. (One can only +hope that they are networking students who have learned this material +and can thus avoid having their tryst uncovered by Trudy!) But +confidentiality is only a small part of the network security picture. As +we learned in Section 8.9, increasingly, the focus in network security +has been on securing the network infrastructure against a potential +onslaught by the bad guys. In the latter part of this chapter, we thus +covered firewalls and IDS systems which inspect packets entering and +leaving an + + organization's network. This chapter has covered a lot of ground, while +focusing on the most important topics in modern network security. +Readers who desire to dig deeper are encouraged to investigate the +references cited in this chapter. In particular, we recommend \[Skoudis +2006\] for attacks and operational security, \[Kaufman 1995\] for +cryptography and how it applies to network security, \[Rescorla 2001\] +for an in-depth but readable treatment of SSL, and \[Edney 2003\] for a +thorough discussion of 802.11 security, including an insightful +investigation into WEP and its flaws. + + Homework Problems and Questions + +Chapter 8 Review Problems + +SECTION 8.1 R1. What are the differences between message confidentiality +and message integrity? Can you have confidentiality without integrity? +Can you have integrity without confidentiality? Justify your answer. R2. +Internet entities (routers, switches, DNS servers, Web servers, user end +systems, and so on) often need to communicate securely. Give three +specific example pairs of Internet entities that may want secure +communication. + +SECTION 8.2 R3. From a service perspective, what is an important +difference between a symmetric-key system and a public-key system? R4. +Suppose that an intruder has an encrypted message as well as the +decrypted version of that message. Can the intruder mount a +ciphertext-only attack, a known-plaintext attack, or a chosenplaintext +attack? R5. Consider an 8-block cipher. How many possible input blocks +does this cipher have? How many possible mappings are there? If we view +each mapping as a key, then how many possible keys does this cipher +have? R6. Suppose N people want to communicate with each of N−1 other +people using symmetric key encryption. All communication between any two +people, i and j, is visible to all other people in this group of N, and +no other person in this group should be able to decode their +communication. How many keys are required in the system as a whole? Now +suppose that public key encryption is used. How many keys are required +in this case? R7. Suppose n=10,000, a=10,023, and b=10,004. Use an +identity of modular arithmetic to calculate in your head (a⋅b)mod n. R8. +Suppose you want to encrypt the message 10101111 by encrypting the +decimal number that corresponds to the message. What is the decimal +number? + +SECTIONS 8.3--8.4 + + R9. In what way does a hash provide a better message integrity check +than a checksum (such as the Internet checksum)? R10. Can you "decrypt" +a hash of a message to get the original message? Explain your answer. +R11. Consider a variation of the MAC algorithm (Figure 8.9 ) where the +sender sends (m, H(m)+s), where H(m)+s is the concatenation of H(m) and +s. Is this variation flawed? Why or why not? R12. What does it mean for +a signed document to be verifiable and nonforgeable? R13. In what way +does the public-key encrypted message hash provide a better digital +signature than the public-key encrypted message? R14. Suppose +certifier.com creates a certificate for foo.com. Typically, the entire +certificate would be encrypted with certifier.com's public key. True or +false? R15. Suppose Alice has a message that she is ready to send to +anyone who asks. Thousands of people want to obtain Alice's message, but +each wants to be sure of the integrity of the message. In this context, +do you think a MAC-based or a digital-signature-based integrity scheme +is more suitable? Why? R16. What is the purpose of a nonce in an +end-point authentication protocol? R17. What does it mean to say that a +nonce is a once-in-a-lifetime value? In whose lifetime? R18. Is the +message integrity scheme based on HMAC susceptible to playback attacks? +If so, how can a nonce be incorporated into the scheme to remove this +susceptibility? + +SECTIONS 8.5--8.8 R19. Suppose that Bob receives a PGP message from +Alice. How does Bob know for sure that Alice created the message (rather +than, say, Trudy)? Does PGP use a MAC for message integrity? R20. In the +SSL record, there is a field for SSL sequence numbers. True or false? +R21. What is the purpose of the random nonces in the SSL handshake? R22. +Suppose an SSL session employs a block cipher with CBC. True or false: +The server sends to the client the IV in the clear. R23. Suppose Bob +initiates a TCP connection to Trudy who is pretending to be Alice. +During the handshake, Trudy sends Bob Alice's certificate. In what step +of the SSL handshake algorithm will Bob discover that he is not +communicating with Alice? R24. Consider sending a stream of packets from +Host A to Host B using IPsec. Typically, a new SA will be established +for each packet sent in the stream. True or false? R25. Suppose that TCP +is being run over IPsec between headquarters and the branch office in +Figure 8.28 . If TCP retransmits the same packet, then the two +corresponding packets sent by R1 packets will have the same sequence +number in the ESP header. True or false? R26. An IKE SA and an IPsec SA +are the same thing. True or false? R27. Consider WEP for 802.11. Suppose +that the data is 10101100 and the keystream is 1111000. What is the +resulting ciphertext? + + R28. In WEP, an IV is sent in the clear in every frame. True or false? + +SECTION 8.9 R29. Stateful packet filters maintain two data structures. +Name them and briefly describe what they do. R30. Consider a traditional +(stateless) packet filter. This packet filter may filter packets based +on TCP flag bits as well as other header fields. True or false? R31. In +a traditional packet filter, each interface can have its own access +control list. True or false? R32. Why must an application gateway work +in conjunction with a router filter to be effective? R33. +Signature-based IDSs and IPSs inspect into the payloads of TCP and UDP +segments. True or false? + +Problems P1. Using the monoalphabetic cipher in Figure 8.3 , encode the +message "This is an easy problem." Decode the message "rmij'u uamu xyj." +P2. Show that Trudy's known-plaintext attack, in which she knows the +(ciphertext, plaintext) translation pairs for seven letters, reduces the +number of possible substitutions to be checked in the example in Section +8.2.1 by approximately 109. P3. Consider the polyalphabetic system shown +in Figure 8.4 . Will a chosen-plaintext attack that is able to get the +plaintext encoding of the message "The quick brown fox jumps over the +lazy dog." be sufficient to decode all messages? Why or why not? P4. +Consider the block cipher in Figure 8.5 . Suppose that each block cipher +Ti simply reverses the order of the eight input bits (so that, for +example, 11110000 becomes 00001111). Further suppose that the 64-bit +scrambler does not modify any bits (so that the output value of the mth +bit is equal to the input value of the mth bit). (a) With n=3 and the +original 64-bit input equal to 10100000 repeated eight times, what is +the value of the output? (b) Repeat part (a) but now change the last bit +of the original 64-bit input from a 0 to a 1. (c) Repeat parts (a) and +(b) but now suppose that the 64-bit scrambler inverses the order of the +64 bits. P5. Consider the block cipher in Figure 8.5 . For a given "key" +Alice and Bob would need to keep eight tables, each 8 bits by 8 bits. +For Alice (or Bob) to store all eight tables, how many bits of storage +are necessary? How does this number compare with the number of bits +required for a full-table 64-bit block cipher? P6. Consider the 3-bit +block cipher in Table 8.1 . Suppose the plaintext is 100100100. (a) +Initially assume that CBC is not used. What is the resulting ciphertext? +(b) Suppose Trudy sniffs the ciphertext. Assuming she knows that a 3-bit +block cipher without CBC is being employed (but doesn't know the +specific cipher), what can she surmise? (c) Now suppose that CBC is used + + with IV=111. What is the resulting ciphertext? P7. (a) Using RSA, choose +p=3 and q=11, and encode the word "dog" by encrypting each letter +separately. Apply the decryption algorithm to the encrypted version to +recover the original plaintext message. (b) Repeat part (a) but now +encrypt "dog" as one message m. P8. Consider RSA with p=5 and q=11. + +a. What are n and z? + +b. Let e be 3. Why is this an acceptable choice for e? + +c. Find d such that de=1 (mod z) and d\<160. + +d. Encrypt the message m=8 using the key (n, e). Let c denote the + corresponding ciphertext. Show all work. Hint: To simplify the + calculations, use the fact: \[ (a mod n)⋅(b mod n)\]mod n=(a⋅b)modn + P9. In this problem, we explore the Diffie-Hellman (DH) public-key + encryption algorithm, which allows two entities to agree on a shared + key. The DH algorithm makes use of a large prime number p and + another large number g less than p. Both p and g are made public (so + that an attacker would know them). In DH, Alice and Bob each + independently choose secret keys, SA and SB, respectively. Alice + then computes her public key, TA, by raising g to SA and then taking + mod p. Bob similarly computes his own public key TB by raising g to + SB and then taking mod p. Alice and Bob then exchange their public + keys over the Internet. Alice then calculates the shared secret key + S by raising TB to SA and then taking mod p. Similarly, Bob + calculates the shared key S′ by raising TA to SB and then taking mod + p. + +e. Prove that, in general, Alice and Bob obtain the same symmetric key, + that is, prove S=S′. + +f. With p = 11 and g = 2, suppose Alice and Bob choose private keys + SA=5 and SB=12, respectively. Calculate Alice's and Bob's public + keys, TA and TB. Show all work. + +g. Following up on part (b), now calculate S as the shared symmetric + key. Show all work. + +h. Provide a timing diagram that shows how Diffie-Hellman can be + attacked by a man-inthe-middle. The timing diagram should have three + vertical lines, one for Alice, one for Bob, and one for the attacker + Trudy. P10. Suppose Alice wants to communicate with Bob using + symmetric key cryptography using a session key KS. In Section 8.2 , + we learned how public-key cryptography can be used to distribute the + session key from Alice to Bob. In this problem, we explore how the + session key can be distributed---without public key + cryptography---using a key distribution center (KDC). The KDC is a + server that shares a unique secret symmetric key with each + registered user. For Alice and Bob, denote these keys by KA-KDC and + KB-KDC. Design a scheme that uses the KDC to distribute KS to Alice + and Bob. Your scheme should use three messages to distribute the + session key: a message from Alice to the KDC; a message from the KDC + to Alice; and finally a message from Alice to Bob. The first message + is KA-KDC (A, B). Using the notation, KA-KDC, KB-KDC, S, A, and B + answer the following questions. + + a. What is the second message? b. What is the third message? P11. +Compute a third message, different from the two messages in Figure 8.8 , +that has the same checksum as the messages in Figure 8.8 . P12. Suppose +Alice and Bob share two secret keys: an authentication key S1 and a +symmetric encryption key S2. Augment Figure 8.9 so that both integrity +and confidentiality are provided. P13. In the BitTorrent P2P file +distribution protocol (see Chapter 2 ), the seed breaks the file into +blocks, and the peers redistribute the blocks to each other. Without any +protection, an attacker can easily wreak havoc in a torrent by +masquerading as a benevolent peer and sending bogus blocks to a small +subset of peers in the torrent. These unsuspecting peers then +redistribute the bogus blocks to other peers, which in turn redistribute +the bogus blocks to even more peers. Thus, it is critical for BitTorrent +to have a mechanism that allows a peer to verify the integrity of a +block, so that it doesn't redistribute bogus blocks. Assume that when a +peer joins a torrent, it initially gets a .torrent file from a fully +trusted source. Describe a simple scheme that allows peers to verify the +integrity of blocks. P14. The OSPF routing protocol uses a MAC rather +than digital signatures to provide message integrity. Why do you think a +MAC was chosen over digital signatures? P15. Consider our authentication +protocol in Figure 8.18 in which Alice authenticates herself to Bob, +which we saw works well (i.e., we found no flaws in it). Now suppose +that while Alice is authenticating herself to Bob, Bob must authenticate +himself to Alice. Give a scenario by which Trudy, pretending to be +Alice, can now authenticate herself to Bob as Alice. (Hint: Consider +that the sequence of operations of the protocol, one with Trudy +initiating and one with Bob initiating, can be arbitrarily interleaved. +Pay particular attention to the fact that both Bob and Alice will use a +nonce, and that if care is not taken, the same nonce can be used +maliciously.) P16. A natural question is whether we can use a nonce and +public key cryptography to solve the end-point authentication problem in +Section 8.4 . Consider the following natural protocol: (1) Alice sends +the message " I am Alice " to Bob. (2) Bob chooses a nonce, R, and sends +it to Alice. (3) Alice uses her private key to encrypt the nonce and +sends the resulting value to Bob. (4) Bob applies Alice's public key to +the received message. Thus, Bob computes R and authenticates Alice. + +a. Diagram this protocol, using the notation for public and private + keys employed in the textbook. + +b. Suppose that certificates are not used. Describe how Trudy can + become a "woman-inthe-middle" by intercepting Alice's messages and + then pretending to be Alice to Bob. P17. Figure 8.19 shows the + operations that Alice must perform with PGP to provide + confidentiality, authentication, and integrity. Diagram the + corresponding operations that Bob must perform on the package + received from Alice. P18. Suppose Alice wants to send an e-mail to + Bob. Bob has a public-private key pair + + (KB+,KB−), and Alice has Bob's certificate. But Alice does not have a +public, private key pair. Alice and Bob (and the entire world) share the +same hash function H(⋅). + +a. In this situation, is it possible to design a scheme so that Bob can + verify that Alice created the message? If so, show how with a block + diagram for Alice and Bob. + +b. Is it possible to design a scheme that provides confidentiality for + sending the message from Alice to Bob? If so, show how with a block + diagram for Alice and Bob. P19. Consider the Wireshark output below + for a portion of an SSL session. + +c. Is Wireshark packet 112 sent by the client or server? + +d. What is the server's IP address and port number? + +e. Assuming no loss and no retransmissions, what will be the sequence + number of the next TCP segment sent by the client? + +f. How many SSL records does Wireshark packet 112 contain? + +g. Does packet 112 contain a Master Secret or an Encrypted Master + Secret or neither? + +h. Assuming that the handshake type field is 1 byte and each length + field is 3 bytes, what are the values of the first and last bytes of + the Master Secret (or Encrypted Master Secret)? + +i. The client encrypted handshake message takes into account how many + SSL records? + +j. The server encrypted handshake message takes into account how many + SSL records? P20. In Section 8.6.1 , it is shown that without + sequence numbers, Trudy (a woman-in-the middle) can wreak havoc in + an SSL session by interchanging TCP segments. Can Trudy do something + similar by deleting a TCP segment? What does she need to do to + succeed at the deletion attack? What effect will it have? + + (Wireshark screenshot reprinted by permission of the Wireshark +Foundation.) + +P21. Suppose Alice and Bob are communicating over an SSL session. +Suppose an attacker, who does not have any of the shared keys, inserts a +bogus TCP segment into a packet stream with correct TCP checksum and +sequence numbers (and correct IP addresses and port numbers). Will SSL +at the receiving side accept the bogus packet and pass the payload to +the receiving application? Why or why not? P22. The following true/false +questions pertain to Figure 8.28 . + +a. When a host in 172.16.1/24 sends a datagram to an Amazon.com server, + the router R1 will encrypt the datagram using IPsec. + +b. When a host in 172.16.1/24 sends a datagram to a host in + 172.16.2/24, the router R1 will change the source and destination + address of the IP datagram. + +c. Suppose a host in 172.16.1/24 initiates a TCP connection to a Web + server in 172.16.2/24. As part of this connection, all datagrams + sent by R1 will have protocol number 50 in the left-most IPv4 header + field. + +d. Consider sending a TCP segment from a host in 172.16.1/24 to a host + in 172.16.2/24. Suppose the acknowledgment for this segment gets + lost, so that TCP resends the segment. Because IPsec uses sequence + numbers, R1 will not resend the TCP segment. + + P23. Consider the example in Figure 8.28 . Suppose Trudy is a +woman-in-the-middle, who can insert datagrams into the stream of +datagrams going from R1 and R2. As part of a replay attack, Trudy sends +a duplicate copy of one of the datagrams sent from R1 to R2. Will R2 +decrypt the duplicate datagram and forward it into the branch-office +network? If not, describe in detail how R2 detects the duplicate +datagram. P24. Consider the following pseudo-WEP protocol. The key is 4 +bits and the IV is 2 bits. The IV is appended to the end of the key when +generating the keystream. Suppose that the shared secret key is 1010. +The keystreams for the four possible inputs are as follows: 101000: +0010101101010101001011010100100 . . . 101001: +1010011011001010110100100101101 . . . 101010: +0001101000111100010100101001111 . . . 101011: +1111101010000000101010100010111 . . . Suppose all messages are 8 bits +long. Suppose the ICV (integrity check) is 4 bits long, and is +calculated by XOR-ing the first 4 bits of data with the last 4 bits of +data. Suppose the pseudoWEP packet consists of three fields: first the +IV field, then the message field, and last the ICV field, with some of +these fields encrypted. + +a. We want to send the message m=10100000 using the IV=11 and using + WEP. What will be the values in the three WEP fields? + +b. Show that when the receiver decrypts the WEP packet, it recovers the + message and the ICV. + +c. Suppose Trudy intercepts a WEP packet (not necessarily with the + IV=11) and wants to modify it before forwarding it to the receiver. + Suppose Trudy flips the first ICV bit. Assuming that Trudy does not + know the keystreams for any of the IVs, what other bit(s) must Trudy + also flip so that the received packet passes the ICV check? + +d. Justify your answer by modifying the bits in the WEP packet in part + (a), decrypting the resulting packet, and verifying the integrity + check. P25. Provide a filter table and a connection table for a + stateful firewall that is as restrictive as possible but + accomplishes the following: + +e. Allows all internal users to establish Telnet sessions with external + hosts. + +f. Allows external users to surf the company Web site at 222.22.0.12. + +g. But otherwise blocks all inbound and outbound traffic. The internal + network is 222.22/16. In your solution, suppose that the connection + table is currently caching three connections, all from inside to + outside. You'll need to invent appropriate IP addresses and port + numbers. P26. Suppose Alice wants to visit the Web site activist.com + using a TOR-like service. This service uses two non-colluding proxy + servers, Proxy1 and Proxy2. Alice first obtains the + + certificates (each containing a public key) for Proxy1 and Proxy2 from +some central server. Denote K1+(),K2+(),K1−(), and K2−() for the +encryption/decryption with public and private RSA keys. + +a. Using a timing diagram, provide a protocol (as simple as possible) + that enables Alice to establish a shared session key S1 with Proxy1. + Denote S1(m) for encryption/decryption of data m with the shared key + S1. + +b. Using a timing diagram, provide a protocol (as simple as possible) + that allows Alice to establish a shared session key S2 with Proxy2 + without revealing her IP address to Proxy2. + +c. Assume now that shared keys S1 and S2 are now established. Using a + timing diagram, provide a protocol (as simple as possible and not + using public-key cryptography) that allows Alice to request an html + page from activist.com without revealing her IP address to Proxy2 + and without revealing to Proxy1 which site she is visiting. Your + diagram should end with an HTTP request arriving at activist.com. + +Wireshark Lab In this lab (available from the book Web site), we +investigate the Secure Sockets Layer (SSL) protocol. Recall from Section +8.6 that SSL is used for securing a TCP connection, and that it is +extensively used in practice for secure Internet transactions. In this +lab, we will focus on the SSL records sent over the TCP connection. We +will attempt to delineate and classify each of the records, with a goal +of understanding the why and how for each record. We investigate the +various SSL record types as well as the fields in the SSL messages. We +do so by analyzing a trace of the SSL records sent between your host and +an e-commerce server. + +IPsec Lab In this lab (available from the book Web site), we will +explore how to create IPsec SAs between linux boxes. You can do the +first part of the lab with two ordinary linux boxes, each with one +Ethernet adapter. But for the second part of the lab, you will need four +linux boxes, two of which having two Ethernet adapters. In the second +half of the lab, you will create IPsec SAs using the ESP protocol in the +tunnel mode. You will do this by first manually creating the SAs, and +then by having IKE create the SAs. + +AN INTERVIEW WITH... Steven M. Bellovin Steven M. Bellovin joined the +faculty at Columbia University after many years at the Network Services +Research Lab at AT&T Labs Research in Florham Park, New Jersey. His +focus is on networks, security, and why the two are incompatible. In +1995, he was awarded the Usenix Lifetime Achievement Award for his work +in the creation of Usenet, the first newsgroup exchange network that +linked two or more computers and allowed users to share information + + and join in discussions. Steve is also an elected member of the National +Academy of Engineering. He received his BA from Columbia University and +his PhD from the University of North Carolina at Chapel Hill. + + What led you to specialize in the networking security area? This is +going to sound odd, but the answer is simple: It was fun. My background +was in systems programming and systems administration, which leads +fairly naturally to security. And I've always been interested in +communications, ranging back to part-time systems programming jobs when +I was in college. My work on security continues to be motivated by two +things---a desire to keep computers useful, which means that their +function can't be corrupted by attackers, and a desire to protect +privacy. What was your vision for Usenet at the time that you were +developing it? And now? We originally viewed it as a way to talk about +computer science and computer programming around the country, with a lot +of local use for administrative matters, for-sale ads, and so on. In +fact, my original prediction was one to two messages per day, from +50--100 sites at the most--- ever. But the real growth was in +people-related topics, including---but not limited to---human +interactions with computers. My favorite newsgroups, over the years, +have been things like rec.woodworking, as well as sci.crypt. To some +extent, netnews has been displaced by the Web. Were I to start designing +it today, it would look very different. But it still excels as a way to +reach a very broad audience that is interested in the topic, without +having to rely on particular Web sites. Has anyone inspired you +professionally? In what ways? Professor Fred Brooks---the founder and +original chair of the computer science department at the University of +North Carolina at Chapel Hill, the manager of the team that developed +the IBM S/360 and OS/360, and the author of The Mythical Man-Month---was +a tremendous influence on my career. More than anything else, he taught +outlook and trade-offs---how to look at problems in the context of the +real world (and how much messier the real world is than a theorist would +like), and how to balance competing interests in designing a solution. +Most computer work is engineering---the art of making the right +trade-offs to satisfy many contradictory objectives. What is your vision +for the future of networking and security? Thus far, much of the +security we have has come from isolation. A firewall, for example, works +by cutting off access to certain machines and services. But we're in an +era of increasing connectivity---it's gotten harder to isolate things. +Worse yet, our production systems require far more separate pieces, +interconnected by networks. Securing all that is one of our biggest +challenges. + + What would you say have been the greatest advances in security? How much +further do we have to go? At least scientifically, we know how to do +cryptography. That's been a big help. But most security problems are due +to buggy code, and that's a much harder problem. In fact, it's the +oldest unsolved problem in computer science, and I think it will remain +that way. The challenge is figuring out how to secure systems when we +have to build them out of insecure components. We can already do that +for reliability in the face of hardware failures; can we do the same for +security? Do you have any advice for students about the Internet and +networking security? Learning the mechanisms is the easy part. Learning +how to "think paranoid" is harder. You have to remember that probability +distributions don't apply---the attackers can and will find improbable +conditions. And the details matter---a lot. + + Chapter 9 Multimedia Networking + +While lounging in bed or riding buses and subways, people in all corners +of the world are currently using the Internet to watch movies and +television shows on demand. Internet movie and television distribution +companies such as Netflix and Amazon in North America and Youku and +Kankan in China have practically become household names. But people are +not only watching Internet videos, they are using sites like YouTube to +upload and distribute their own user-generated content, becoming +Internet video producers as well as consumers. Moreover, network +applications such as Skype, Google Talk, and WeChat (enormously popular +in China) allow people to not only make "telephone calls" over the +Internet, but to also enhance those calls with video and multi-person +conferencing. In fact, we predict that by the end of the current decade +most of the video consumption and voice conversations will take place +end-to-end over the Internet, more typically to wireless devices +connected to the Internet via cellular and WiFi access networks. +Traditional telephony and broadcast television are quickly becoming +obsolete. We begin this chapter with a taxonomy of multimedia +applications in Section 9.1. We'll see that a multimedia application can +be classified as either streaming stored audio/video, conversational +voice/video-over-IP, or streaming live audio/video. We'll see that each +of these classes of applications has its own unique service requirements +that differ significantly from those of traditional elastic applications +such as e-mail, Web browsing, and remote login. In Section 9.2, we'll +examine video streaming in some detail. We'll explore many of the +underlying principles behind video streaming, including client +buffering, prefetching, and adapting video quality to available +bandwidth. In Section 9.3, we investigate conversational voice and +video, which, unlike elastic applications, are highly sensitive to +end-to-end delay but can tolerate occasional loss of data. Here we'll +examine how techniques such as adaptive playout, forward error +correction, and error concealment can mitigate against network-induced +packet loss and delay. We'll also examine Skype as a case study. In +Section 9.4, we'll study RTP and SIP, two popular protocols for +real-time conversational voice and video applications. In Section 9.5, +we'll investigate mechanisms within the network that can be used to +distinguish one class of traffic (e.g., delay-sensitive applications +such as conversational voice) from another (e.g., elastic applications +such as browsing Web pages), and provide differentiated service among +multiple classes of traffic. + + 9.1 Multimedia Networking Applications We define a multimedia network +application as any network application that employs audio or video. In +this section, we provide a taxonomy of multimedia applications. We'll +see that each class of applications in the taxonomy has its own unique +set of service requirements and design issues. But before diving into an +in-depth discussion of Internet multimedia applications, it is useful to +consider the intrinsic characteristics of the audio and video media +themselves. + +9.1.1 Properties of Video Perhaps the most salient characteristic of +video is its high bit rate. Video distributed over the Internet +typically ranges from 100 kbps for low-quality video conferencing to +over 3 Mbps for streaming highdefinition movies. To get a sense of how +video bandwidth demands compare with those of other Internet +applications, let's briefly consider three different users, each using a +different Internet application. Our first user, Frank, is going quickly +through photos posted on his friends' Facebook pages. Let's assume that +Frank is looking at a new photo every 10 seconds, and that photos are on +average 200 Kbytes in size. (As usual, throughout this discussion we +make the simplifying assumption that 1 Kbyte=8,000 bits.) Our second +user, Martha, is streaming music from the Internet ("the cloud") to her +smartphone. Let's assume Martha is using a service such as Spotify to +listen to many MP3 songs, one after the other, each encoded at a rate of +128 kbps. Our third user, Victor, is watching a video that has been +encoded at 2 Mbps. Finally, let's suppose that the session length for +all three users is 4,000 seconds (approximately 67 minutes). Table 9.1 +compares the bit rates and the total bytes transferred for these three +users. We see that video streaming consumes by far the most bandwidth, +having a bit rate of more than ten times greater than that of the +Facebook and music-streaming applications. Therefore, when design Table +9.1 Comparison of bit-rate requirements of three Internet applications +Bit rate + +Bytes transferred in 67 min + +Facebook Frank + +160 kbps + +80 Mbytes + +Martha Music + +128 kbps + +64 Mbytes + +Victor Video + +2 Mbps + +1 Gbyte + + ing networked video applications, the first thing we must keep in mind +is the high bit-rate requirements of video. Given the popularity of +video and its high bit rate, it is perhaps not surprising that Cisco +predicts \[Cisco 2015\] that streaming and stored video will be +approximately 80 percent of global consumer Internet traffic by 2019. +Another important characteristic of video is that it can be compressed, +thereby trading off video quality with bit rate. A video is a sequence +of images, typically being displayed at a constant rate, for example, at +24 or 30 images per second. An uncompressed, digitally encoded image +consists of an array of pixels, with each pixel encoded into a number of +bits to represent luminance and color. There are two types of redundancy +in video, both of which can be exploited by video compression. Spatial +redundancy is the redundancy within a given image. Intuitively, an image +that consists of mostly white space has a high degree of redundancy and +can be efficiently compressed without significantly sacrificing image +quality. Temporal redundancy reflects repetition from image to +subsequent image. If, for example, an image and the subsequent image are +exactly the same, there is no reason to re-encode the subsequent image; +it is instead more efficient simply to indicate during encoding that the +subsequent image is exactly the same. Today's off-the-shelf compression +algorithms can compress a video to essentially any bit rate desired. Of +course, the higher the bit rate, the better the image quality and the +better the overall user viewing experience. We can also use compression +to create multiple versions of the same video, each at a different +quality level. For example, we can use compression to create, say, three +versions of the same video, at rates of 300 kbps, 1 Mbps, and 3 Mbps. +Users can then decide which version they want to watch as a function of +their current available bandwidth. Users with high-speed Internet +connections might choose the 3 Mbps version; users watching the video +over 3G with a smartphone might choose the 300 kbps version. Similarly, +the video in a video conference application can be compressed +"on-the-fly" to provide the best video quality given the available +end-to-end bandwidth between conversing users. + +9.1.2 Properties of Audio Digital audio (including digitized speech and +music) has significantly lower bandwidth requirements than video. +Digital audio, however, has its own unique properties that must be +considered when designing multimedia network applications. To understand +these properties, let's first consider how analog audio (which humans +and musical instruments generate) is converted to a digital signal: The +analog audio signal is sampled at some fixed rate, for example, at 8,000 +samples per second. The value of each sample will be some real number. +Each of the samples is then rounded to one of a finite number of values. +This operation is referred to as quantization. The number of such finite +values---called quantization values---is typically a power + + of two, for example, 256 quantization values. Each of the quantization +values is represented by a fixed number of bits. For example, if there +are 256 quantization values, then each value---and hence each audio +sample---is represented by one byte. The bit representations of all the +samples are then concatenated together to form the digital +representation of the signal. As an example, if an analog audio signal +is sampled at 8,000 samples per second and each sample is quantized and +represented by 8 bits, then the resulting digital signal will have a +rate of 64,000 bits per second. For playback through audio speakers, the +digital signal can then be converted back---that is, decoded---to an +analog signal. However, the decoded analog signal is only an +approximation of the original signal, and the sound quality may be +noticeably degraded (for example, high-frequency sounds may be missing +in the decoded signal). By increasing the sampling rate and the number +of quantization values, the decoded signal can better approximate the +original analog signal. Thus (as with video), there is a trade-off +between the quality of the decoded signal and the bit-rate and storage +requirements of the digital signal. The basic encoding technique that we +just described is called pulse code modulation (PCM). Speech encoding +often uses PCM, with a sampling rate of 8,000 samples per second and 8 +bits per sample, resulting in a rate of 64 kbps. The audio compact disk +(CD) also uses PCM, with a sampling rate of 44,100 samples per second +with 16 bits per sample; this gives a rate of 705.6 kbps for mono and +1.411 Mbps for stereo. PCM-encoded speech and music, however, are rarely +used in the Internet. Instead, as with video, compression techniques are +used to reduce the bit rates of the stream. Human speech can be +compressed to less than 10 kbps and still be intelligible. A popular +compression technique for near CDquality stereo music is MPEG 1 layer 3, +more commonly known as MP3. MP3 encoders can compress to many different +rates; 128 kbps is the most common encoding rate and produces very +little sound degradation. A related standard is Advanced Audio Coding +(AAC), which has been popularized by Apple. As with video, multiple +versions of a prerecorded audio stream can be created, each at a +different bit rate. Although audio bit rates are generally much less +than those of video, users are generally much more sensitive to audio +glitches than video glitches. Consider, for example, a video conference +taking place over the Internet. If, from time to time, the video signal +is lost for a few seconds, the video conference can likely proceed +without too much user frustration. If, however, the audio signal is +frequently lost, the users may have to terminate the session. + +9.1.3 Types of Multimedia Network Applications The Internet supports a +large variety of useful and entertaining multimedia applications. In +this subsection, we classify multimedia applications into three broad +categories: (i) streaming stored + + audio/video, (ii) conversational voice/video-over-IP, and (iii) +streaming live audio/video. As we will soon see, each of these +application categories has its own set of service requirements and +design issues. Streaming Stored Audio and Video To keep the discussion +concrete, we focus here on streaming stored video, which typically +combines video and audio components. Streaming stored audio (such as +Spotify's streaming music service) is very similar to streaming stored +video, although the bit rates are typically much lower. In this class of +applications, the underlying medium is prerecorded video, such as a +movie, a television show, a prerecorded sporting event, or a prerecorded +user-generated video (such as those commonly seen on YouTube). These +prerecorded videos are placed on servers, and users send requests to the +servers to view the videos on demand. Many Internet companies today +provide streaming video, including YouTube (Google), Netflix, Amazon, +and Hulu. Streaming stored video has three key distinguishing features. +Streaming. In a streaming stored video application, the client typically +begins video playout within a few seconds after it begins receiving the +video from the server. This means that the client will be playing out +from one location in the video while at the same time receiving later +parts of the video from the server. This technique, known as streaming, +avoids having to download the entire video file (and incurring a +potentially long delay) before playout begins. Interactivity. Because +the media is prerecorded, the user may pause, reposition forward, +reposition backward, fast-forward, and so on through the video content. +The time from when the user makes such a request until the action +manifests itself at the client should be less than a few seconds for +acceptable responsiveness. Continuous playout. Once playout of the video +begins, it should proceed according to the original timing of the +recording. Therefore, data must be received from the server in time for +its playout at the client; otherwise, users experience video frame +freezing (when the client waits for the delayed frames) or frame +skipping (when the client skips over delayed frames). By far, the most +important performance measure for streaming video is average throughput. +In order to provide continuous playout, the network must provide an +average throughput to the streaming application that is at least as +large the bit rate of the video itself. As we will see in Section 9.2, +by using buffering and prefetching, it is possible to provide continuous +playout even when the throughput fluctuates, as long as the average +throughput (averaged over 5--10 seconds) remains above the video rate +\[Wang 2008\]. For many streaming video applications, prerecorded video +is stored on, and streamed from, a CDN rather than from a single data +center. There are also many P2P video streaming applications for which +the video is stored on users' hosts (peers), with different chunks of +video arriving from different peers + + that may spread around the globe. Given the prominence of Internet video +streaming, we will explore video streaming in some depth in Section 9.2, +paying particular attention to client buffering, prefetching, adapting +quality to bandwidth availability, and CDN distribution. Conversational +Voice- and Video-over-IP Real-time conversational voice over the +Internet is often referred to as Internet telephony, since, from the +user's perspective, it is similar to the traditional circuit-switched +telephone service. It is also commonly called Voice-over-IP (VoIP). +Conversational video is similar, except that it includes the video of +the participants as well as their voices. Most of today's voice and +video conversational systems allow users to create conferences with +three or more participants. Conversational voice and video are widely +used in the Internet today, with the Internet companies Skype, QQ, and +Google Talk boasting hundreds of millions of daily users. In our +discussion of application service requirements in Chapter 2 (Figure +2.4), we identified a number of axes along which application +requirements can be classified. Two of these axes---timing +considerations and tolerance of data loss---are particularly important +for conversational voice and video applications. Timing considerations +are important because audio and video conversational applications are +highly delay-sensitive. For a conversation with two or more interacting +speakers, the delay from when a user speaks or moves until the action is +manifested at the other end should be less than a few hundred +milliseconds. For voice, delays smaller than 150 milliseconds are not +perceived by a human listener, delays between 150 and 400 milliseconds +can be acceptable, and delays exceeding 400 milliseconds can result in +frustrating, if not completely unintelligible, voice conversations. On +the other hand, conversational multimedia applications are +loss-tolerant---occasional loss only causes occasional glitches in +audio/video playback, and these losses can often be partially or fully +concealed. These delay-sensitive but loss-tolerant characteristics are +clearly different from those of elastic data applications such as Web +browsing, e-mail, social networks, and remote login. For elastic +applications, long delays are annoying but not particularly harmful; the +completeness and integrity of the transferred data, however, are of +paramount importance. We will explore conversational voice and video in +more depth in Section 9.3, paying particular attention to how adaptive +playout, forward error correction, and error concealment can mitigate +against network-induced packet loss and delay. Streaming Live Audio and +Video This third class of applications is similar to traditional +broadcast radio and television, except that transmission takes place +over the Internet. These applications allow a user to receive a live +radio or television transmission---such as a live sporting event or an +ongoing news event---transmitted from any corner of the world. Today, +thousands of radio and television stations around the world are +broadcasting content over the Internet. + + Live, broadcast-like applications often have many users who receive the +same audio/video program at the same time. In the Internet today, this +is typically done with CDNs (Section 2.6). As with streaming stored +multimedia, the network must provide each live multimedia flow with an +average throughput that is larger than the video consumption rate. +Because the event is live, delay can also be an issue, although the +timing constraints are much less stringent than those for conversational +voice. Delays of up to ten seconds or so from when the user chooses to +view a live transmission to when playout begins can be tolerated. We +will not cover streaming live media in this book because many of the +techniques used for streaming live media---initial buffering delay, +adaptive bandwidth use, and CDN distribution---are similar to those for +streaming stored media. + + 9.2 Streaming Stored Video For streaming video applications, prerecorded +videos are placed on servers, and users send requests to these servers +to view the videos on demand. The user may watch the video from +beginning to end without interruption, may stop watching the video well +before it ends, or interact with the video by pausing or repositioning +to a future or past scene. Streaming video systems can be classified +into three categories: UDP streaming, HTTP streaming, and adaptive HTTP +streaming (see Section 2.6). Although all three types of systems are +used in practice, the majority of today's systems employ HTTP streaming +and adaptive HTTP streaming. A common characteristic of all three forms +of video streaming is the extensive use of client-side application +buffering to mitigate the effects of varying end-to-end delays and +varying amounts of available bandwidth between server and client. For +streaming video (both stored and live), users generally can tolerate a +small several-second initial delay between when the client requests a +video and when video playout begins at the client. Consequently, when +the video starts to arrive at the client, the client need not +immediately begin playout, but can instead build up a reserve of video +in an application buffer. Once the client has built up a reserve of +several seconds of buffered-but-not-yet-played video, the client can +then begin video playout. There are two important advantages provided by +such client buffering. First, client-side buffering can absorb +variations in server-to-client delay. If a particular piece of video +data is delayed, as long as it arrives before the reserve of +received-but-not-yet-played video is exhausted, this long delay will not +be noticed. Second, if the server-to-client bandwidth briefly drops +below the video consumption rate, a user can continue to enjoy +continuous playback, again as long as the client application buffer does +not become completely drained. Figure 9.1 illustrates client-side +buffering. In this simple example, suppose that video is encoded at a +fixed bit rate, and thus each video block contains video frames that are +to be played out over the same fixed amount of time, Δ. The server +transmits the first video block at t0, the second block at t0+Δ, the +third block at t0+2Δ, and so on. Once the client begins playout, each +block should be played out Δ time units after the previous block in +order to reproduce the timing of the original recorded video. Because of +the variable end-to-end network delays, different video blocks +experience different delays. The first video block arrives at the client +at t1 and the second block arrives at t2. The network delay for the ith +block is the horizontal distance between the time the block was +transmitted by the server and the time it is received at the client; +note that the network delay varies from one video block to another. In +this example, if the client were to begin playout as soon as the first +block arrived at t1, then the second block would not have arrived in +time to be played out at out at t1+Δ. In this case, video playout would +either have to stall (waiting for block 2 to arrive) or block 2 could be +skipped---both resulting in undesirable + + playout impairments. Instead, if the client were to delay the start of +playout until t3, when blocks 1 through 6 have all arrived, periodic +playout can proceed with all blocks having been received before their +playout time. + +Figure 9.1 Client playout delay in video streaming + +9.2.1 UDP Streaming We only briefly discuss UDP streaming here, +referring the reader to more in-depth discussions of the protocols +behind these systems where appropriate. With UDP streaming, the server +transmits video at a rate that matches the client's video consumption +rate by clocking out the video chunks over UDP at a steady rate. For +example, if the video consumption rate is 2 Mbps and each UDP packet +carries 8,000 bits of video, then the server would transmit one UDP +packet into its socket every (8000 bits)/(2 Mbps)=4 msec. As we learned +in Chapter 3, because UDP does not employ a congestion-control +mechanism, the server can push packets into the network at the +consumption rate of the video without the rate-control restrictions of +TCP. UDP streaming typically uses a small client-side buffer, big enough +to hold less than a second of video. Before passing the video chunks to +UDP, the server will encapsulate the video chunks within transport +packets specially designed for transporting audio and video, using the +Real-Time Transport Protocol (RTP) \[RFC 3550\] or a similar (possibly +proprietary) scheme. We delay our coverage of RTP until Section 9.3, +where we discuss RTP in the context of conversational voice and video +systems. Another distinguishing property of UDP streaming is that in +addition to the server-to-client video stream, the client and server +also maintain, in parallel, a separate control connection over which the +client sends commands regarding session state changes (such as pause, +resume, reposition, and so on). The Real- + + Time Streaming Protocol (RTSP) \[RFC 2326\], explained in some detail in +the Web site for this textbook, is a popular open protocol for such a +control connection. Although UDP streaming has been employed in many +open-source systems and proprietary products, it suffers from three +significant drawbacks. First, due to the unpredictable and varying +amount of available bandwidth between server and client, constant-rate +UDP streaming can fail to provide continuous playout. For example, +consider the scenario where the video consumption rate is 1 Mbps and the +server-to-client available bandwidth is usually more than 1 Mbps, but +every few minutes the available bandwidth drops below 1 Mbps for several +seconds. In such a scenario, a UDP streaming system that transmits video +at a constant rate of 1 Mbps over RTP/UDP would likely provide a poor +user experience, with freezing or skipped frames soon after the +available bandwidth falls below 1 Mbps. The second drawback of UDP +streaming is that it requires a media control server, such as an RTSP +server, to process client-to-server interactivity requests and to track +client state (e.g., the client's playout point in the video, whether the +video is being paused or played, and so on) for each ongoing client +session. This increases the overall cost and complexity of deploying a +large-scale video-on-demand system. The third drawback is that many +firewalls are configured to block UDP traffic, preventing the users +behind these firewalls from receiving UDP video. + +9.2.2 HTTP Streaming In HTTP streaming, the video is simply stored in an +HTTP server as an ordinary file with a specific URL. When a user wants +to see the video, the client establishes a TCP connection with the +server and issues an HTTP GET request for that URL. The server then +sends the video file, within an HTTP response message, as quickly as +possible, that is, as quickly as TCP congestion control and flow control +will allow. On the client side, the bytes are collected in a client +application buffer. Once the number of bytes in this buffer exceeds a +predetermined threshold, the client application begins +playback---specifically, it periodically grabs video frames from the +client application buffer, decompresses the frames, and displays them on +the user's screen. We learned in Chapter 3 that when transferring a file +over TCP, the server-to-client transmission rate can vary significantly +due to TCP's congestion control mechanism. In particular, it is not +uncommon for the transmission rate to vary in a "saw-tooth" manner +associated with TCP congestion control. Furthermore, packets can also be +significantly delayed due to TCP's retransmission mechanism. Because of +these characteristics of TCP, the conventional wisdom in the 1990s was +that video streaming would never work well over TCP. Over time, however, +designers of streaming video systems learned that TCP's congestion +control and reliable-data transfer mechanisms do not necessarily +preclude continuous playout when client buffering and prefetching +(discussed in the next section) are used. + + The use of HTTP over TCP also allows the video to traverse firewalls and +NATs more easily (which are often configured to block most UDP traffic +but to allow most HTTP traffic). Streaming over HTTP also obviates the +need for a media control server, such as an RTSP server, reducing the +cost of a largescale deployment over the Internet. Due to all of these +advantages, most video streaming applications today---including YouTube +and Netflix---use HTTP streaming (over TCP) as its underlying streaming +protocol. Prefetching Video As we just learned, client-side buffering +can be used to mitigate the effects of varying end-to-end delays and +varying available bandwidth. In our earlier example in Figure 9.1, the +server transmits video at the rate at which the video is to be played +out. However, for streaming stored video, the client can attempt to +download the video at a rate higher than the consumption rate, thereby +prefetching video frames that are to be consumed in the future. This +prefetched video is naturally stored in the client application buffer. +Such prefetching occurs naturally with TCP streaming, since TCP's +congestion avoidance mechanism will attempt to use all of the available +bandwidth between server and client. To gain some insight into +prefetching, let's take a look at a simple example. Suppose the video +consumption rate is 1 Mbps but the network is capable of delivering the +video from server to client at a constant rate of 1.5 Mbps. Then the +client will not only be able to play out the video with a very small +playout delay, but will also be able to increase the amount of buffered +video data by 500 Kbits every second. In this manner, if in the future +the client receives data at a rate of less than 1 Mbps for a brief +period of time, the client will be able to continue to provide +continuous playback due to the reserve in its buffer. \[Wang 2008\] +shows that when the average TCP throughput is roughly twice the media +bit rate, streaming over TCP results in minimal starvation and low +buffering delays. Client Application Buffer and TCP Buffers Figure 9.2 +illustrates the interaction between client and server for HTTP +streaming. At the server side, the portion of the video file in white +has already been sent into the server's socket, while the darkened +portion is what remains to be sent. After "passing through the socket +door," the bytes are placed in the TCP send buffer before being +transmitted into the Internet, as described in Chapter 3. In Figure 9.2, +because the TCP send buffer at the server side is shown to be full, the +server is momentarily prevented from sending more bytes from the video +file into the socket. On the client side, the client application (media +player) reads bytes from the TCP receive buffer (through its client +socket) and places the bytes into the client application buffer. At the +same time, the client application periodically grabs video frames from +the client application buffer, decompresses the frames, and displays +them on the user's screen. Note that if the client application buffer is +larger than the video file, then the whole process of moving bytes from +the server's storage to the client's application buffer is equivalent to +an ordinary file download over HTTP---the client simply pulls the video +off the server as fast as TCP will allow! + + Figure 9.2 Streaming stored video over HTTP/TCP + +Consider now what happens when the user pauses the video during the +streaming process. During the pause period, bits are not removed from +the client application buffer, even though bits continue to enter the +buffer from the server. If the client application buffer is finite, it +may eventually become full, which will cause "back pressure" all the way +back to the server. Specifically, once the client application buffer +becomes full, bytes can no longer be removed from the client TCP receive +buffer, so it too becomes full. Once the client receive TCP buffer +becomes full, bytes can no longer be removed from the server TCP send +buffer, so it also becomes full. Once the TCP becomes full, the server +cannot send any more bytes into the socket. Thus, if the user pauses the +video, the server may be forced to stop transmitting, in which case the +server will be blocked until the user resumes the video. In fact, even +during regular playback (that is, without pausing), if the client +application buffer becomes full, back pressure will cause the TCP +buffers to become full, which will force the server to reduce its rate. +To determine the resulting rate, note that when the client application +removes f bits, it creates room for f bits in the client application +buffer, which in turn allows the server to send f additional bits. Thus, +the server send rate can be no higher than the video consumption rate at +the client. Therefore, a full client application buffer indirectly +imposes a limit on the rate that video can be sent from server to client +when streaming over HTTP. Analysis of Video Streaming Some simple +modeling will provide more insight into initial playout delay and +freezing due to application buffer depletion. As shown in Figure 9.3, +let B denote the size + + Figure 9.3 Analysis of client-side buffering for video streaming + +(in bits) of the client's application buffer, and let Q denote the +number of bits that must be buffered before the client application +begins playout. (Of course, Q\<B.) Let r denote the video consumption +rate ---the rate at which the client draws bits out of the client +application buffer during playback. So, for example, if the video's +frame rate is 30 frames/sec, and each (compressed) frame is 100,000 +bits, then r=3 Mbps. To see the forest through the trees, we'll ignore +TCP's send and receive buffers. Let's assume that the server sends bits +at a constant rate x whenever the client buffer is not full. (This is a +gross simplification, since TCP's send rate varies due to congestion +control; we'll examine more realistic time-dependent rates x(t) in the +problems at the end of this chapter.) Suppose at time t=0, the +application buffer is empty and video begins arriving to the client +application buffer. We now ask at what time t=tp does playout begin? And +while we are at it, at what time t=tf does the client application buffer +become full? First, let's determine tp, the time when Q bits have +entered the application buffer and playout begins. Recall that bits +arrive to the client application buffer at rate x and no bits are +removed from this buffer before playout begins. Thus, the amount of time +required to build up Q bits (the initial buffering delay) is tp=Q/x. Now +let's determine tf, the point in time when the client application buffer +becomes full. We first observe that if x\<r (that is, if the server send +rate is less than the video consumption rate), then the client buffer +will never become full! Indeed, starting at time tp, the buffer will be +depleted at rate r and will only be filled at rate x\<r. Eventually the +client buffer will empty out entirely, at which time the video will +freeze on the screen while the client buffer waits another tp seconds to +build up Q bits of video. Thus, when the + + available rate in the network is less than the video rate, playout will +alternate between periods of continuous playout and periods of freezing. +In a homework problem, you will be asked to determine the length of each +continuous playout and freezing period as a function of Q, r, and x. Now +let's determine tf for when x\>r. In this case, starting at time tp, the +buffer increases from Q to B at rate x−r since bits are being depleted +at rate r but are arriving at rate x, as shown in Figure 9.3. Given +these hints, you will be asked in a homework problem to determine tf, +the time the client buffer becomes full. Note that when the available +rate in the network is more than the video rate, after the initial +buffering delay, the user will enjoy continuous playout until the video +ends. Early Termination and Repositioning the Video HTTP streaming +systems often make use of the HTTP byte-range header in the HTTP GET +request message, which specifies the specific range of bytes the client +currently wants to retrieve from the desired video. This is particularly +useful when the user wants to reposition (that is, jump) to a future +point in time in the video. When the user repositions to a new position, +the client sends a new HTTP request, indicating with the byte-range +header from which byte in the file should the server send data. When the +server receives the new HTTP request, it can forget about any earlier +request and instead send bytes beginning with the byte indicated in the +byte-range request. While we are on the subject of repositioning, we +briefly mention that when a user repositions to a future point in the +video or terminates the video early, some prefetched-but-not-yet-viewed +data transmitted by the server will go unwatched---a waste of network +bandwidth and server resources. For example, suppose that the client +buffer is full with B bits at some time t0 into the video, and at this +time the user repositions to some instant t\>t0+B/r into the video, and +then watches the video to completion from that point on. In this case, +all B bits in the buffer will be unwatched and the bandwidth and server +resources that were used to transmit those B bits have been completely +wasted. There is significant wasted bandwidth in the Internet due to +early termination, which can be quite costly, particularly for wireless +links \[Ihm 2011\]. For this reason, many streaming systems use only a +moderate-size client application buffer, or will limit the amount of +prefetched video using the byte-range header in HTTP requests \[Rao +2011\]. Repositioning and early termination are analogous to cooking a +large meal, eating only a portion of it, and throwing the rest away, +thereby wasting food. So the next time your parents criticize you for +wasting food by not eating all your dinner, you can quickly retort by +saying they are wasting bandwidth and server resources when they +reposition while watching movies over the Internet! But, of course, two +wrongs do not make a right---both food and bandwidth are not to be +wasted! In Sections 9.2.1 and 9.2.2, we covered UDP streaming and HTTP +streaming, respectively. A third type of streaming is Dynamic Adaptive +Streaming over HTTP (DASH), which uses multiple versions of the + + video, each compressed at a different rate. DASH is discussed in detail +in Section 2.6.2. CDNs are often used to distribute stored and live +video. CDNs are discussed in detail in Section 2.6.3. + + 9.3 Voice-over-IP Real-time conversational voice over the Internet is +often referred to as Internet telephony, since, from the user's +perspective, it is similar to the traditional circuit-switched telephone +service. It is also commonly called Voice-over-IP (VoIP). In this +section we describe the principles and protocols underlying VoIP. +Conversational video is similar in many respects to VoIP, except that it +includes the video of the participants as well as their voices. To keep +the discussion focused and concrete, we focus here only on voice in this +section rather than combined voice and video. + +9.3.1 Limitations of the Best-Effort IP Service The Internet's +network-layer protocol, IP, provides best-effort service. That is to say +the service makes its best effort to move each datagram from source to +destination as quickly as possible but makes no promises whatsoever +about getting the packet to the destination within some delay bound or +about a limit on the percentage of packets lost. The lack of such +guarantees poses significant challenges to the design of real-time +conversational applications, which are acutely sensitive to packet +delay, jitter, and loss. In this section, we'll cover several ways in +which the performance of VoIP over a best-effort network can be +enhanced. Our focus will be on application-layer techniques, that is, +approaches that do not require any changes in the network core or even +in the transport layer at the end hosts. To keep the discussion +concrete, we'll discuss the limitations of best-effort IP service in the +context of a specific VoIP example. The sender generates bytes at a rate +of 8,000 bytes per second; every 20 msecs the sender gathers these bytes +into a chunk. A chunk and a special header (discussed below) are +encapsulated in a UDP segment, via a call to the socket interface. Thus, +the number of bytes in a chunk is (20 msecs)⋅(8,000 bytes/sec)=160 +bytes, and a UDP segment is sent every 20 msecs. If each packet makes it +to the receiver with a constant end-to-end delay, then packets arrive at +the receiver periodically every 20 msecs. In these ideal conditions, the +receiver can simply play back each chunk as soon as it arrives. But +unfortunately, some packets can be lost and most packets will not have +the same end-to-end delay, even in a lightly congested Internet. For +this reason, the receiver must take more care in determining (1) when to +play back a chunk, and (2) what to do with a missing chunk. Packet Loss + + Consider one of the UDP segments generated by our VoIP application. The +UDP segment is encapsulated in an IP datagram. As the datagram wanders +through the network, it passes through router buffers (that is, queues) +while waiting for transmission on outbound links. It is possible that +one or more of the buffers in the path from sender to receiver is full, +in which case the arriving IP datagram may be discarded, never to arrive +at the receiving application. Loss could be eliminated by sending the +packets over TCP (which provides for reliable data transfer) rather than +over UDP. However, retransmission mechanisms are often considered +unacceptable for conversational real-time audio applications such as +VoIP, because they increase end-to-end delay \[Bolot 1996\]. +Furthermore, due to TCP congestion control, packet loss may result in a +reduction of the TCP sender's transmission rate to a rate that is lower +than the receiver's drain rate, possibly leading to buffer starvation. +This can have a severe impact on voice intelligibility at the receiver. +For these reasons, most existing VoIP applications run over UDP by +default. \[Baset 2006\] reports that UDP is used by Skype unless a user +is behind a NAT or firewall that blocks UDP segments (in which case TCP +is used). But losing packets is not necessarily as disastrous as one +might think. Indeed, packet loss rates between 1 and 20 percent can be +tolerated, depending on how voice is encoded and transmitted, and on how +the loss is concealed at the receiver. For example, forward error +correction (FEC) can help conceal packet loss. We'll see below that with +FEC, redundant information is transmitted along with the original +information so that some of the lost original data can be recovered from +the redundant information. Nevertheless, if one or more of the links +between sender and receiver is severely congested, and packet loss +exceeds 10 to 20 percent (for example, on a wireless link), then there +is really nothing that can be done to achieve acceptable audio quality. +Clearly, best-effort service has its limitations. End-to-End Delay +End-to-end delay is the accumulation of transmission, processing, and +queuing delays in routers; propagation delays in links; and end-system +processing delays. For real-time conversational applications, such as +VoIP, end-to-end delays smaller than 150 msecs are not perceived by a +human listener; delays between 150 and 400 msecs can be acceptable but +are not ideal; and delays exceeding 400 msecs can seriously hinder the +interactivity in voice conversations. The receiving side of a VoIP +application will typically disregard any packets that are delayed more +than a certain threshold, for example, more than 400 msecs. Thus, +packets that are delayed by more than the threshold are effectively +lost. Packet Jitter A crucial component of end-to-end delay is the +varying queuing delays that a packet experiences in the network's +routers. Because of these varying delays, the time from when a packet is +generated at the + + source until it is received at the receiver can fluctuate from packet to +packet, as shown in Figure 9.1. This phenomenon is called jitter. As an +example, consider two consecutive packets in our VoIP application. The +sender sends the second packet 20 msecs after sending the first packet. +But at the receiver, the spacing between these packets can become +greater than 20 msecs. To see this, suppose the first packet arrives at +a nearly empty queue at a router, but just before the second packet +arrives at the queue a large number of packets from other sources arrive +at the same queue. Because the first packet experiences a small queuing +delay and the second packet suffers a large queuing delay at this +router, the first and second packets become spaced by more than 20 +msecs. The spacing between consecutive packets can also become less than +20 msecs. To see this, again consider two consecutive packets. Suppose +the first packet joins the end of a queue with a large number of +packets, and the second packet arrives at the queue before this first +packet is transmitted and before any packets from other sources arrive +at the queue. In this case, our two packets find themselves one right +after the other in the queue. If the time it takes to transmit a packet +on the router's outbound link is less than 20 msecs, then the spacing +between first and second packets becomes less than 20 msecs. The +situation is analogous to driving cars on roads. Suppose you and your +friend are each driving in your own cars from San Diego to Phoenix. +Suppose you and your friend have similar driving styles, and that you +both drive at 100 km/hour, traffic permitting. If your friend starts out +one hour before you, depending on intervening traffic, you may arrive at +Phoenix more or less than one hour after your friend. If the receiver +ignores the presence of jitter and plays out chunks as soon as they +arrive, then the resulting audio quality can easily become +unintelligible at the receiver. Fortunately, jitter can often be removed +by using sequence numbers, timestamps, and a playout delay, as discussed +below. + +9.3.2 Removing Jitter at the Receiver for Audio For our VoIP +application, where packets are being generated periodically, the +receiver should attempt to provide periodic playout of voice chunks in +the presence of random network jitter. This is typically done by +combining the following two mechanisms: Prepending each chunk with a +timestamp. The sender stamps each chunk with the time at which the chunk +was generated. Delaying playout of chunks at the receiver. As we saw in +our earlier discussion of Figure 9.1, the playout delay of the received +audio chunks must be long enough so that most of the packets are +received before their scheduled playout times. This playout delay can +either be fixed throughout the duration of the audio session or vary +adaptively during the audio session lifetime. We now discuss how these +three mechanisms, when combined, can alleviate or even eliminate the +effects of jitter. We examine two playback strategies: fixed playout +delay and adaptive playout delay. + + Fixed Playout Delay With the fixed-delay strategy, the receiver attempts +to play out each chunk exactly q msecs after the chunk is generated. So +if a chunk is timestamped at the sender at time t, the receiver plays +out the chunk at time t+q, assuming the chunk has arrived by that time. +Packets that arrive after their scheduled playout times are discarded +and considered lost. What is a good choice for q? VoIP can support +delays up to about 400 msecs, although a more satisfying conversational +experience is achieved with smaller values of q. On the other hand, if q +is made much smaller than 400 msecs, then many packets may miss their +scheduled playback times due to the network-induced packet jitter. +Roughly speaking, if large variations in end-to-end delay are typical, +it is preferable to use a large q; on the other hand, if delay is small +and variations in delay are also small, it is preferable to use a small +q, perhaps less than 150 msecs. The trade-off between the playback delay +and packet loss is illustrated in Figure 9.4. The figure shows the times +at which packets are generated and played + +Figure 9.4 Packet loss for different fixed playout delays + +out for a single talk spurt. Two distinct initial playout delays are +considered. As shown by the leftmost staircase, the sender generates +packets at regular intervals---say, every 20 msecs. The first packet in +this talk spurt is received at time r. As shown in the figure, the +arrivals of subsequent packets are not evenly spaced due to the network +jitter. For the first playout schedule, the fixed initial playout delay +is set to p−r. With this schedule, the fourth + + packet does not arrive by its scheduled playout time, and the receiver +considers it lost. For the second playout schedule, the fixed initial +playout delay is set to p′−r. For this schedule, all packets arrive +before their scheduled playout times, and there is therefore no loss. +Adaptive Playout Delay The previous example demonstrates an important +delay-loss trade-off that arises when designing a playout strategy with +fixed playout delays. By making the initial playout delay large, most +packets will make their deadlines and there will therefore be negligible +loss; however, for conversational services such as VoIP, long delays can +become bothersome if not intolerable. Ideally, we would like the playout +delay to be minimized subject to the constraint that the loss be below a +few percent. The natural way to deal with this trade-off is to estimate +the network delay and the variance of the network delay, and to adjust +the playout delay accordingly at the beginning of each talk spurt. This +adaptive adjustment of playout delays at the beginning of the talk +spurts will cause the sender's silent periods to be compressed and +elongated; however, compression and elongation of silence by a small +amount is not noticeable in speech. Following \[Ramjee 1994\], we now +describe a generic algorithm that the receiver can use to adaptively +adjust its playout delays. To this end, let ti= the timestamp of the ith +packet = the time the packet was generated by the sender ri= the time +packet i is received by receiver pi= the time packet i is played at +receiver The end-to-end network delay of the ith packet is ri−ti. Due to +network jitter, this delay will vary from packet to packet. Let di +denote an estimate of the average network delay upon reception of the +ith packet. This estimate is constructed from the timestamps as follows: +di=(1−u)di−1+u(ri−ti) where u is a fixed constant (for example, u=0.01). +Thus di is a smoothed average of the observed network delays +r1−t1,...,ri−ti. The estimate places more weight on the recently +observed network delays than on the observed network delays of the +distant past. This form of estimate should not be completely unfamiliar; +a similar idea is used to estimate round-trip times in TCP, as discussed +in Chapter 3. Let vi denote an estimate of the average deviation of the +delay from the estimated average delay. This estimate is also +constructed from the timestamps: vi=(1−u)vi−1+u\| ri−ti−di\| + + The estimates di and vi are calculated for every packet received, +although they are used only to determine the playout point for the first +packet in any talk spurt. Once having calculated these estimates, the +receiver employs the following algorithm for the playout of packets. If +packet i is the first packet of a talk spurt, its playout time, pi, is +computed as: pi=ti+di+Kvi where K is a positive constant (for example, +K=4). The purpose of the Kvi term is to set the playout time far enough +into the future so that only a small fraction of the arriving packets in +the talk spurt will be lost due to late arrivals. The playout point for +any subsequent packet in a talk spurt is computed as an offset from the +point in time when the first packet in the talk spurt was played out. In +particular, let qi=pi−ti be the length of time from when the first +packet in the talk spurt is generated until it is played out. If packet +j also belongs to this talk spurt, it is played out at time pj=tj+qi The +algorithm just described makes perfect sense assuming that the receiver +can tell whether a packet is the first packet in the talk spurt. This +can be done by examining the signal energy in each received packet. + +9.3.3 Recovering from Packet Loss We have discussed in some detail how a +VoIP application can deal with packet jitter. We now briefly describe +several schemes that attempt to preserve acceptable audio quality in the +presence of packet loss. Such schemes are called loss recovery schemes. +Here we define packet loss in a broad sense: A packet is lost either if +it never arrives at the receiver or if it arrives after its scheduled +playout time. Our VoIP example will again serve as a context for +describing loss recovery schemes. As mentioned at the beginning of this +section, retransmitting lost packets may not be feasible in a realtime +conversational application such as VoIP. Indeed, retransmitting a packet +that has missed its playout deadline serves absolutely no purpose. And +retransmitting a packet that overflowed a router queue cannot normally +be accomplished quickly enough. Because of these considerations, VoIP +applications often use some type of loss anticipation scheme. Two types +of loss anticipation schemes are forward error correction (FEC) and +interleaving. + + Forward Error Correction (FEC) The basic idea of FEC is to add redundant +information to the original packet stream. For the cost of marginally +increasing the transmission rate, the redundant information can be used +to reconstruct approximations or exact versions of some of the lost +packets. Following \[Bolot 1996\] and \[Perkins 1998\], we now outline +two simple FEC mechanisms. The first mechanism sends a redundant encoded +chunk after every n chunks. The redundant chunk is obtained by exclusive +OR-ing the n original chunks \[Shacham 1990\]. In this manner if any one +packet of the group of n+1 packets is lost, the receiver can fully +reconstruct the lost packet. But if two or more packets in a group are +lost, the receiver cannot reconstruct the lost packets. By keeping n+1, +the group size, small, a large fraction of the lost packets can be +recovered when loss is not excessive. However, the smaller the group +size, the greater the relative increase of the transmission rate. In +particular, the transmission rate increases by a factor of 1/n, so that, +if n=3, then the transmission rate increases by 33 percent. Furthermore, +this simple scheme increases the playout delay, as the receiver must +wait to receive the entire group of packets before it can begin playout. +For more practical details about how FEC works for multimedia transport +see \[RFC 5109\]. The second FEC mechanism is to send a lower-resolution +audio stream as the redundant information. For example, the sender might +create a nominal audio stream and a corresponding low-resolution, lowbit +rate audio stream. (The nominal stream could be a PCM encoding at 64 +kbps, and the lower-quality stream could be a GSM encoding at 13 kbps.) +The low-bit rate stream is referred to as the redundant stream. As shown +in Figure 9.5, the sender constructs the nth packet by taking the nth +chunk from the nominal stream and appending to it the (n−1)st chunk from +the redundant stream. In this manner, whenever there is nonconsecutive +packet loss, the receiver can conceal the loss by playing out the lowbit +rate encoded chunk that arrives with the subsequent packet. Of course, +low-bit rate chunks give lower quality than the nominal chunks. However, +a stream of mostly high-quality chunks, occasional lowquality chunks, +and no missing chunks gives good overall audio quality. Note that in +this scheme, the receiver only has to receive two packets before +playback, so that the increased playout delay is small. Furthermore, if +the low-bit rate encoding is much less than the nominal encoding, then +the marginal increase in the transmission rate will be small. In order +to cope with consecutive loss, we can use a simple variation. Instead of +appending just the (n−1)st low-bit rate chunk to the nth nominal chunk, +the sender can append the (n−1)st and (n−2)nd lowbit rate chunk, or +append the (n−1)st and (n−3)rd low-bit rate chunk, and so on. By +appending more lowbit rate chunks to each nominal chunk, the audio +quality at the receiver becomes acceptable for a wider variety of harsh +best-effort environments. On the other hand, the additional chunks +increase the transmission bandwidth and the playout delay. + + Figure 9.5 Piggybacking lower-quality redundant information + +Interleaving As an alternative to redundant transmission, a VoIP +application can send interleaved audio. As shown in Figure 9.6, the +sender resequences units of audio data before transmission, so that +originally adjacent units are separated by a certain distance in the +transmitted stream. Interleaving can mitigate the effect of packet +losses. If, for example, units are 5 msecs in length and chunks are 20 +msecs (that is, four units per chunk), then the first chunk could +contain units 1, 5, 9, and 13; the second chunk could contain units 2, +6, 10, and 14; and so on. Figure 9.6 shows that the loss of a single +packet from an interleaved stream results in multiple small gaps in the +reconstructed stream, as opposed to the single large gap that would +occur in a noninterleaved stream. Interleaving can significantly improve +the perceived quality of an audio stream \[Perkins 1998\]. It also has +low overhead. The obvious disadvantage of interleaving is that it +increases latency. This limits its use for conversational applications +such as VoIP, although it can perform well for streaming stored audio. A +major advantage of interleaving is that it does not increase the +bandwidth requirements of a stream. Error Concealment Error concealment +schemes attempt to produce a replacement for a lost packet that is +similar to the original. As discussed in \[Perkins 1998\], this is +possible since audio + + Figure 9.6 Sending interleaved audio + +signals, and in particular speech, exhibit large amounts of short-term +self-similarity. As such, these techniques work for relatively small +loss rates (less than 15 percent), and for small packets (4--40 msecs). +When the loss length approaches the length of a phoneme (5--100 msecs) +these techniques break down, since whole phonemes may be missed by the +listener. Perhaps the simplest form of receiver-based recovery is packet +repetition. Packet repetition replaces lost packets with copies of the +packets that arrived immediately before the loss. It has low +computational complexity and performs reasonably well. Another form of +receiver-based recovery is interpolation, which uses audio before and +after the loss to interpolate a suitable packet to cover the loss. +Interpolation performs somewhat better than packet repetition but is +significantly more computationally intensive \[Perkins 1998\]. + +9.3.4 Case Study: VoIP with Skype Skype is an immensely popular VoIP +application with over 50 million accounts active on a daily basis. In +addition to providing host-to-host VoIP service, Skype offers +host-to-phone services, phone-to-host services, and multi-party +host-to-host video conferencing services. (Here, a host is again any +Internet connected IP device, including PCs, tablets, and smartphones.) +Skype was acquired by Microsoft in 2011. + + Because the Skype protocol is proprietary, and because all Skype's +control and media packets are encrypted, it is difficult to precisely +determine how Skype operates. Nevertheless, from the Skype Web site and +several measurement studies, researchers have learned how Skype +generally works \[Baset 2006; Guha 2006; Chen 2006; Suh 2006; Ren 2006; +Zhang X 2012\]. For both voice and video, the Skype clients have at +their disposal many different codecs, which are capable of encoding the +media at a wide range of rates and qualities. For example, video rates +for Skype have been measured to be as low as 30 kbps for a low-quality +session up to almost 1 Mbps for a high quality session \[Zhang X 2012\]. +Typically, Skype's audio quality is better than the "POTS" (Plain Old +Telephone Service) quality provided by the wire-line phone system. +(Skype codecs typically sample voice at 16,000 samples/sec or higher, +which provides richer tones than POTS, which samples at 8,000/sec.) By +default, Skype sends audio and video packets over UDP. However, control +packets are sent over TCP, and media packets are also sent over TCP when +firewalls block UDP streams. Skype uses FEC for loss recovery for both +voice and video streams sent over UDP. The Skype client also adapts the +audio and video streams it sends to current network conditions, by +changing video quality and FEC overhead \[Zhang X 2012\]. Skype uses P2P +techniques in a number of innovative ways, nicely illustrating how P2P +can be used in applications that go beyond content distribution and file +sharing. As with instant messaging, host-to-host Internet telephony is +inherently P2P since, at the heart of the application, pairs of users +(that is, peers) communicate with each other in real time. But Skype +also employs P2P techniques for two other important functions, namely, +for user location and for NAT traversal. + + Figure 9.7 Skype peers + +As shown in Figure 9.7, the peers (hosts) in Skype are organized into a +hierarchical overlay network, with each peer classified as a super peer +or an ordinary peer. Skype maintains an index that maps Skype usernames +to current IP addresses (and port numbers). This index is distributed +over the super peers. When Alice wants to call Bob, her Skype client +searches the distributed index to determine Bob's current IP address. +Because the Skype protocol is proprietary, it is currently not known how +the index mappings are organized across the super peers, although some +form of DHT organization is very possible. P2P techniques are also used +in Skype relays, which are useful for establishing calls between hosts +in home networks. Many home network configurations provide access to the +Internet through NATs, as discussed in Chapter 4. Recall that a NAT +prevents a host from outside the home network from initiating a +connection to a host within the home network. If both Skype callers have +NATs, then there is a problem---neither can accept a call initiated by +the other, making a call seemingly impossible. The clever use of super +peers and relays nicely solves this problem. Suppose that when Alice +signs in, she is assigned to a non-NATed super peer and initiates a +session to that super peer. (Since Alice is initiating the session, her +NAT permits this session.) This session allows Alice and her super peer +to exchange control messages. The same happens for Bob when he signs in. +Now, when Alice wants to call Bob, she informs her super peer, who in +turn informs Bob's super peer, who in turn informs Bob of Alice's +incoming call. If Bob accepts the call, the two super peers select a +third non-NATed super peer---the relay peer---whose job will be to relay +data between Alice and Bob. Alice's and Bob's super peers then instruct +Alice and Bob respectively to initiate a session with the relay. As +shown in Figure 9.7, Alice then sends voice packets to the relay over +the Alice-to-relay connection (which was initiated by Alice), and the +relay then forwards these packets over the relay-to-Bob connection +(which was initiated by Bob); packets from Bob to Alice flow over these +same two relay connections in reverse. And voila!---Bob and Alice have +an end-to-end connection even though neither can accept a session +originating from outside. Up to now, our discussion on Skype has focused +on calls involving two persons. Now let's examine multi-party audio +conference calls. With N\>2 participants, if each user were to send a +copy of its audio stream to each of the N−1 other users, then a total of +N(N−1) audio streams would need to be sent into the network to support +the audio conference. To reduce this bandwidth usage, Skype employs a +clever distribution technique. Specifically, each user sends its audio +stream to the conference initiator. The conference initiator combines +the audio streams into one stream (basically by adding all the audio +signals together) and then sends a copy of each combined stream to each +of the other N−1 participants. In this manner, the number of streams is +reduced to 2(N−1). For ordinary two-person video conversations, Skype +routes the call peer-to-peer, unless NAT traversal is required, in which +case the call is relayed through a non-NATed peer, as described earlier. +For a video conference call involving N\>2 participants, due to the +nature of the video medium, Skype does not combine the call into one + + stream at one location and then redistribute the stream to all the +participants, as it does for voice calls. Instead, each participant's +video stream is routed to a server cluster (located in Estonia as of +2011), which in turn relays to each participant the N−1 streams of the +N−1 other participants \[Zhang X 2012\]. You may be wondering why each +participant sends a copy to a server rather than directly sending a copy +of its video stream to each of the other N−1 participants? Indeed, for +both approaches, N(N−1) video streams are being collectively received by +the N participants in the conference. The reason is, because upstream +link bandwidths are significantly lower than downstream link bandwidths +in most access links, the upstream links may not be able to support the +N−1 streams with the P2P approach. VoIP systems such as Skype, WeChat, +and Google Talk introduce new privacy concerns. Specifically, when Alice +and Bob communicate over VoIP, Alice can sniff Bob's IP address and then +use geo-location services \[MaxMind 2016; Quova 2016\] to determine +Bob's current location and ISP (for example, his work or home ISP). In +fact, with Skype it is possible for Alice to block the transmission of +certain packets during call establishment so that she obtains Bob's +current IP address, say every hour, without Bob knowing that he is being +tracked and without being on Bob's contact list. Furthermore, the IP +address discovered from Skype can be correlated with IP addresses found +in BitTorrent, so that Alice can determine the files that Bob is +downloading \[LeBlond 2011\]. Moreover, it is possible to partially +decrypt a Skype call by doing a traffic analysis of the packet sizes in +a stream \[White 2011\]. + + 9.4 Protocols for Real-Time Conversational Applications Real-time +conversational applications, including VoIP and video conferencing, are +compelling and very popular. It is therefore not surprising that +standards bodies, such as the IETF and ITU, have been busy for many +years (and continue to be busy!) at hammering out standards for this +class of applications. With the appropriate standards in place for +real-time conversational applications, independent companies are +creating new products that interoperate with each other. In this section +we examine RTP and SIP for real-time conversational applications. Both +standards are enjoying widespread implementation in industry products. + +9.4.1 RTP In the previous section, we learned that the sender side of a +VoIP application appends header fields to the audio chunks before +passing them to the transport layer. These header fields include +sequence numbers and timestamps. Since most multimedia networking +applications can make use of sequence numbers and timestamps, it is +convenient to have a standardized packet structure that includes fields +for audio/video data, sequence number, and timestamp, as well as other +potentially useful fields. RTP, defined in RFC 3550, is such a standard. +RTP can be used for transporting common formats such as PCM, ACC, and +MP3 for sound and MPEG and H.263 for video. It can also be used for +transporting proprietary sound and video formats. Today, RTP enjoys +widespread implementation in many products and research prototypes. It +is also complementary to other important real-time interactive +protocols, such as SIP. In this section, we provide an introduction to +RTP. We also encourage you to visit Henning Schulzrinne's RTP site +\[Schulzrinne-RTP 2012\], which provides a wealth of information on the +subject. Also, you may want to visit the RAT site \[RAT 2012\], which +documents VoIP application that uses RTP. RTP Basics RTP typically runs +on top of UDP. The sending side encapsulates a media chunk within an RTP +packet, then encapsulates the packet in a UDP segment, and then hands +the segment to IP. The receiving side extracts the RTP packet from the +UDP segment, then extracts the media chunk from the RTP packet, and then +passes the chunk to the media player for decoding and rendering. As an +example, consider the use of RTP to transport voice. Suppose the voice +source is PCM-encoded + + (that is, sampled, quantized, and digitized) at 64 kbps. Further suppose +that the application collects the encoded data in 20-msec chunks, that +is, 160 bytes in a chunk. The sending side precedes each chunk of the +audio data with an RTP header that includes the type of audio encoding, +a sequence number, and a timestamp. The RTP header is normally 12 bytes. +The audio chunk along with the RTP header form the RTP packet. The RTP +packet is then sent into the UDP socket interface. At the receiver side, +the application receives the RTP packet from its socket interface. The +application extracts the audio chunk from the RTP packet and uses the +header fields of the RTP packet to properly decode and play back the +audio chunk. If an application incorporates RTP---instead of a +proprietary scheme to provide payload type, sequence numbers, or +timestamps---then the application will more easily interoperate with +other networked multimedia applications. For example, if two different +companies develop VoIP software and they both incorporate RTP into their +product, there may be some hope that a user using one of the VoIP +products will be able to communicate with a user using the other VoIP +product. In Section 9.4.2, we'll see that RTP is often used in +conjunction with SIP, an important standard for Internet telephony. It +should be emphasized that RTP does not provide any mechanism to ensure +timely delivery of data or provide other quality-of-service (QoS) +guarantees; it does not even guarantee delivery of packets or prevent +out-of-order delivery of packets. Indeed, RTP encapsulation is seen only +at the end systems. Routers do not distinguish between IP datagrams that +carry RTP packets and IP datagrams that don't. RTP allows each source +(for example, a camera or a microphone) to be assigned its own +independent RTP stream of packets. For example, for a video conference +between two participants, four RTP streams could be opened---two streams +for transmitting the audio (one in each direction) and two streams for +transmitting the video (again, one in each direction). However, many +popular encoding techniques---including MPEG 1 and MPEG 2---bundle the +audio and video into a single stream during the encoding process. When +the audio and video are bundled by the encoder, then only one RTP stream +is generated in each direction. RTP packets are not limited to unicast +applications. They can also be sent over one-to-many and manyto-many +multicast trees. For a many-to-many multicast session, all of the +session's senders and sources typically use the same multicast group for +sending their RTP streams. RTP multicast streams belonging together, +such as audio and video streams emanating from multiple senders in a +video conference application, belong to an RTP session. + +Figure 9.8 RTP header fields + + RTP Packet Header Fields As shown in Figure 9.8, the four main RTP +packet header fields are the payload type, sequence number, timestamp, +and source identifier fields. The payload type field in the RTP packet +is 7 bits long. For an audio stream, the payload type field is used to +indicate the type of audio encoding (for example, PCM, adaptive delta +modulation, linear predictive encoding) that is being used. If a sender +decides to change the encoding in the middle of a session, the sender +can inform the receiver of the change through this payload type field. +The sender may want to change the encoding in order to increase the +audio quality or to decrease the RTP stream bit rate. Table 9.2 lists +some of the audio payload types currently supported by RTP. For a video +stream, the payload type is used to indicate the type of video encoding +(for example, motion JPEG, MPEG 1, MPEG 2, H.261). Again, the sender can +change video encoding on the fly during a session. Table 9.3 lists some +of the video payload types currently supported by RTP. The other +important fields are the following: Sequence number field. The sequence +number field is 16 bits long. The sequence number increments by one for +each RTP packet sent, and may be used by the receiver to detect packet +loss and to restore packet sequence. For example, if the receiver side +of the application receives a stream of RTP packets with a gap between +sequence numbers 86 and 89, then the receiver knows that packets 87 and +88 are missing. The receiver can then attempt to conceal the lost data. +Timestamp field. The timestamp field is 32 bits long. It reflects the +sampling instant of the first byte in the RTP data packet. As we saw in +the preceding section, the receiver can use timestamps to remove packet +jitter introduced in the network and to provide synchronous playout at +the receiver. The timestamp is derived from a sampling clock at the +sender. As an example, for audio the timestamp clock increments by one +for each sampling period (for example, each 125 μsec for an 8 kHz +sampling clock); if the audio application generates chunks consisting of +160 encoded samples, then the timestamp increases by 160 for each RTP +packet when the source is active. The timestamp clock continues to +increase at a constant rate even if the source is inactive. +Synchronization source identifier (SSRC). The SSRC field is 32 bits +long. It identifies the source of the RTP stream. Typically, each stream +in an RTP session has a distinct SSRC. The SSRC is not the IP address of +the sender, but instead is a number that the source assigns randomly +when the new stream is started. The probability that two streams get +assigned the same SSRC is very small. Should this happen, the two +sources pick a new SSRC value. Table 9.2 Audio payload types supported +by RTP Payload-Type Number + +Audio Format + +Sampling Rate + +Rate + +0 + +PCM μ-law + +8 kHz + +64 kbps + + 1 + +1016 + +8 kHz + +4.8 kbps + +3 + +GSM + +8 kHz + +13 kbps + +7 + +LPC + +8 kHz + +2.4 kbps + +9 + +G.722 + +16 kHz + +48--64 kbps + +14 + +MPEG Audio + +90 kHz + +--- + +15 + +G.728 + +8 kHz + +16 kbps + +Table 9.3 Some video payload types supported by RTP Payload-Type Number + +Video Format + +26 + +Motion JPEG + +31 + +H.261 + +32 + +MPEG 1 video + +33 + +MPEG 2 video + +9.4.2 SIP The Session Initiation Protocol (SIP), defined in \[RFC 3261; +RFC 5411\], is an open and lightweight protocol that does the following: +It provides mechanisms for establishing calls between a caller and a +callee over an IP network. It allows the caller to notify the callee +that it wants to start a call. It allows the participants to agree on +media encodings. It also allows participants to end calls. It provides +mechanisms for the caller to determine the current IP address of the +callee. Users do not have a single, fixed IP address because they may be +assigned addresses dynamically (using DHCP) and because they may have +multiple IP devices, each with a different IP address. It provides +mechanisms for call management, such as adding new media streams during +the call, + + changing the encoding during the call, inviting new participants during +the call, call transfer, and call holding. Setting Up a Call to a Known +IP Address To understand the essence of SIP, it is best to take a look +at a concrete example. In this example, Alice is at her PC and she wants +to call Bob, who is also working at his PC. Alice's and Bob's PCs are +both equipped with SIP-based software for making and receiving phone +calls. In this initial example, we'll assume that Alice knows the IP +address of Bob's PC. Figure 9.9 illustrates the SIP call-establishment +process. In Figure 9.9, we see that an SIP session begins when Alice +sends Bob an INVITE message, which resembles an HTTP request message. +This INVITE message is sent over UDP to the well-known port 5060 for +SIP. (SIP messages can also be sent over TCP.) The INVITE message +includes an identifier for Bob (bob@193.64.210.89), an indication of +Alice's current IP address, an indication that Alice desires to receive +audio, which is to be encoded in format AVP 0 (PCM encoded μ-law) and + + Figure 9.9 SIP call establishment when Alice knows Bob's IP address + +encapsulated in RTP, and an indication that she wants to receive the RTP +packets on port 38060. After receiving Alice's INVITE message, Bob sends +an SIP response message, which resembles an HTTP response message. This +response SIP message is also sent to the SIP port 5060. Bob's response +includes a 200 OK as well as an indication of his IP address, his +desired encoding and packetization for reception, and his port number to +which the audio packets should be sent. Note that in this example Alice +and Bob are going to use different audio-encoding mechanisms: Alice is +asked to encode her audio with GSM whereas Bob is asked to encode his +audio with PCM μ-law. After receiving Bob's response, Alice sends Bob an +SIP acknowledgment message. After this SIP transaction, Bob and Alice +can talk. (For visual convenience, Figure 9.9 shows Alice talking after +Bob, but in truth they would normally talk at the same time.) Bob will +encode and packetize the audio as requested and send the audio packets +to port number 38060 at IP address 167.180.112.24. Alice will also +encode and packetize the audio as requested and send the audio packets +to port number 48753 at IP address 193.64.210.89. From this simple +example, we have learned a number of key characteristics of SIP. First, +SIP is an outof-band protocol: The SIP messages are sent and received in +sockets that are different from those used for sending and receiving the +media data. Second, the SIP messages themselves are ASCII-readable and +resemble HTTP messages. Third, SIP requires all messages to be +acknowledged, so it can run over UDP or TCP. In this example, let's +consider what would happen if Bob does not have a PCM μ-law codec for +encoding audio. In this case, instead of responding with 200 OK, Bob +would likely respond with a 606 Not Acceptable and list in the message +all the codecs he can use. Alice would then choose one of the listed +codecs and send another INVITE message, this time advertising the chosen +codec. Bob could also simply reject the call by sending one of many +possible rejection reply codes. (There are many such codes, including +"busy," "gone," "payment required," and "forbidden.") SIP Addresses In +the previous example, Bob's SIP address is sip:bob@193.64.210.89. +However, we expect many---if not most---SIP addresses to resemble e-mail +addresses. For example, Bob's address might be sip:bob@domain.com. When +Alice's SIP device sends an INVITE message, the message would include +this e-mail-like address; the SIP infrastructure would then route the +message to the IP device that Bob is currently using (as we'll discuss +below). Other possible forms for the SIP address could be Bob's legacy +phone number or simply Bob's first/middle/last name (assuming it is +unique). An interesting feature of SIP addresses is that they can be +included in Web pages, just as people's email addresses are included in +Web pages with the mailto URL. For example, suppose Bob has a + + personal homepage, and he wants to provide a means for visitors to the +homepage to call him. He could then simply include the URL +sip:bob@domain.com. When the visitor clicks on the URL, the SIP +application in the visitor's device is launched and an INVITE message is +sent to Bob. SIP Messages In this short introduction to SIP, we'll not +cover all SIP message types and headers. Instead, we'll take a brief +look at the SIP INVITE message, along with a few common header lines. +Let us again suppose that Alice wants to initiate a VoIP call to Bob, +and this time Alice knows only Bob's SIP address, bob@domain.com, and +does not know the IP address of the device that Bob is currently using. +Then her message might look something like this: + +INVITE sip:bob@domain.com SIP/2.0 Via: SIP/2.0/UDP 167.180.112.24 From: +sip:alice@hereway.com To: sip:bob@domain.com Call-ID: +a2e3a@pigeon.hereway.com Content-Type: application/sdp Content-Length: +885 c=IN IP4 167.180.112.24 m=audio 38060 RTP/AVP 0 + +The INVITE line includes the SIP version, as does an HTTP request +message. Whenever an SIP message passes through an SIP device (including +the device that originates the message), it attaches a Via header, which +indicates the IP address of the device. (We'll see soon that the typical +INVITE message passes through many SIP devices before reaching the +callee's SIP application.) Similar to an e-mail message, the SIP message +includes a From header line and a To header line. The message includes a +Call-ID, which uniquely identifies the call (similar to the message-ID +in e-mail). It includes a Content-Type header line, which defines the +format used to describe the content contained in the SIP message. It +also includes a Content-Length header line, which provides the length in +bytes of the content in the message. Finally, after a carriage return +and line feed, the message contains the content. In this case, the +content provides information about Alice's IP address and how Alice +wants to receive the audio. Name Translation and User Location In the +example in Figure 9.9, we assumed that Alice's SIP device knew the IP +address where Bob could + + be contacted. But this assumption is quite unrealistic, not only because +IP addresses are often dynamically assigned with DHCP, but also because +Bob may have multiple IP devices (for example, different devices for his +home, work, and car). So now let us suppose that Alice knows only Bob's +e-mail address, bob@domain.com, and that this same address is used for +SIP-based calls. In this case, Alice needs to obtain the IP address of +the device that the user bob@domain.com is currently using. To find this +out, Alice creates an INVITE message that begins with INVITE +bob@domain.com SIP/2.0 and sends this message to an SIP proxy. The proxy +will respond with an SIP reply that might include the IP address of the +device that bob@domain.com is currently using. Alternatively, the reply +might include the IP address of Bob's voicemail box, or it might include +a URL of a Web page (that says "Bob is sleeping. Leave me alone!"). +Also, the result returned by the proxy might depend on the caller: If +the call is from Bob's wife, he might accept the call and supply his IP +address; if the call is from Bob's mother-inlaw, he might respond with +the URL that points to the I-am-sleeping Web page! Now, you are probably +wondering, how can the proxy server determine the current IP address for +bob@domain.com? To answer this question, we need to say a few words +about another SIP device, the SIP registrar. Every SIP user has an +associated registrar. Whenever a user launches an SIP application on a +device, the application sends an SIP register message to the registrar, +informing the registrar of its current IP address. For example, when Bob +launches his SIP application on his PDA, the application would send a +message along the lines of: + +REGISTER sip:domain.com SIP/2.0 Via: SIP/2.0/UDP 193.64.210.89 From: +sip:bob@domain.com To: sip:bob@domain.com Expires: 3600 + +Bob's registrar keeps track of Bob's current IP address. Whenever Bob +switches to a new SIP device, the new device sends a new register +message, indicating the new IP address. Also, if Bob remains at the same +device for an extended period of time, the device will send refresh +register messages, indicating that the most recently sent IP address is +still valid. (In the example above, refresh messages need to be sent +every 3600 seconds to maintain the address at the registrar server.) It +is worth noting that the registrar is analogous to a DNS authoritative +name server: The DNS server translates fixed host names to fixed IP +addresses; the SIP registrar translates fixed human identifiers (for +example, bob@domain.com) to dynamic IP addresses. Often SIP registrars +and SIP proxies are run on the same host. Now let's examine how Alice's +SIP proxy server obtains Bob's current IP address. From the preceding +discussion we see that the proxy server simply needs to forward Alice's +INVITE message to Bob's registrar/proxy. The registrar/proxy could then +forward the message to Bob's current SIP device. Finally, + + Bob, having now received Alice's INVITE message, could send an SIP +response to Alice. As an example, consider Figure 9.10, in which +jim@umass.edu, currently working on 217.123.56.89, wants to initiate a +Voice-over-IP (VoIP) session with keith@upenn.edu, currently working on +197.87.54.21. The following steps are taken: + +Figure 9.10 Session initiation, involving SIP proxies and registrars + +(1) Jim sends an INVITE message to the umass SIP proxy. (2) The proxy + does a DNS lookup on the SIP registrar upenn.edu (not shown in + diagram) and then forwards the message to the registrar server. +(2) Because keith@upenn.edu is no longer registered at the upenn + registrar, the upenn registrar sends a redirect response, indicating + that it should try keith@nyu.edu. (4) The umass proxy sends an + INVITE message to the NYU SIP registrar. (5) The NYU registrar knows + the IP address of keith@upenn.edu and forwards the INVITE message to + the host 197.87.54.21, which is running Keith's SIP client. (6--8) + An SIP response is sent back through registrars/proxies to the SIP + client on 217.123.56.89. (9) Media is sent directly between the two + clients. (There is also an SIP acknowledgment message, which is not + shown.) Our discussion of SIP has focused on call initiation for + voice calls. SIP, being a signaling protocol for initiating and + ending calls in general, can be used for video conference calls as + well as for text-based + + sessions. In fact, SIP has become a fundamental component in many +instant messaging applications. Readers desiring to learn more about SIP +are encouraged to visit Henning Schulzrinne's SIP Web site +\[Schulzrinne-SIP 2016\]. In particular, on this site you will find open +source software for SIP clients and servers \[SIP Software 2016\]. + + 9.5 Network Support for Multimedia In Sections 9.2 through 9.4, we +learned how application-level mechanisms such as client buffering, +prefetching, adapting media quality to available bandwidth, adaptive +playout, and loss mitigation techniques can be used by multimedia +applications to improve a multimedia application's performance. We also +learned how content distribution networks and P2P overlay networks can +be used to provide a system-level approach for delivering multimedia +content. These techniques and approaches are all designed to be used in +today's best-effort Internet. Indeed, they are in use today precisely +because the Internet provides only a single, best-effort class of +service. But as designers of computer networks, we can't help but ask +whether the network (rather than the applications or application-level +infrastructure alone) might provide mechanisms to support multimedia +content delivery. As we'll see shortly, the answer is, of course, "yes"! +But we'll also see that a number of these new network-level mechanisms +have yet to be widely deployed. This may be due to their complexity and +to the fact that application-level techniques together with best-effort +service and properly dimensioned network resources (for example, +bandwidth) can indeed provide a "good-enough" (even if +not-always-perfect) end-to-end multimedia delivery service. Table 9.4 +summarizes three broad approaches towards providing network-level +support for multimedia applications. Making the best of best-effort +service. The application-level mechanisms and infrastructure that we +studied in Sections 9.2 through 9.4 can be successfully used in a +well-dimensioned network where packet loss and excessive end-to-end +delay rarely occur. When demand increases are forecasted, the ISPs +deploy additional bandwidth and switching capacity to continue to ensure +satisfactory delay and packet-loss performance \[Huang 2005\]. We'll +discuss such network dimensioning further in Section 9.5.1. +Differentiated service. Since the early days of the Internet, it's been +envisioned that different types of traffic (for example, as indicated in +the Type-of-Service field in the IP4v packet header) could be provided +with different classes of service, rather than a single +one-size-fits-all best-effort service. With differentiated service, one +type of traffic might be given strict priority over another class of +traffic when both types of traffic are queued at a router. For example, +packets belonging to a realtime conversational application might be +given priority over other packets due to their stringent delay +constraints. Introducing differentiated service into the network will +require new mechanisms for packet marking (indicating a packet's class +of service), packet scheduling, and more. We'll cover differentiated +service, and new network mechanisms needed to implement this service, in +Sections 9.5.2 and 9.5.3. + + Table 9.4 Three network-level approaches to supporting multimedia +applications Approach + +Granularity + +Guarantee + +Mechanisms + +Complexity + +Deployment to date + +Making the + +all traffic + +none, or + +application-layer + +best of best- + +treated + +soft + +support, CDNs, + +effort service + +equally + +minimal + +everywhere + +medium + +some + +light + +little + +overlays, networklevel resource provisioning + +Differentiated + +different + +none, or + +packet marking, + +service + +classes of + +soft + +policing, scheduling + +traffic treated differently Per- + +each + +soft or + +packet marking, + +connection + +source- + +hard, once + +policing, + +Quality-of- + +destination + +flow is + +scheduling; call + +Service (QoS) + +flows treated + +admitted + +admission and + +Guarantees + +differently + +signaling + +Per-connection Quality-of-Service (QoS) Guarantees. With per-connection +QoS guarantees, each instance of an application explicitly reserves +end-to-end bandwidth and thus has a guaranteed end-to-end performance. A +hard guarantee means the application will receive its requested quality +of service (QoS) with certainty. A soft guarantee means the application +will receive its requested quality of service with high probability. For +example, if a user wants to make a VoIP call from Host A to Host B, the +user's VoIP application reserves bandwidth explicitly in each link along +a route between the two hosts. But permitting applications to make +reservations and requiring the network to honor the reservations +requires some big changes. First, we need a protocol that, on behalf of +the applications, reserves link bandwidth on the paths from the senders +to their receivers. Second, we'll need new scheduling policies in the +router queues so that per-connection bandwidth reservations can be +honored. Finally, in order to make a reservation, the applications must +give the network a description of the traffic that they intend to send +into the network and the network will need to police each application's +traffic to make sure that it abides by that description. These +mechanisms, when combined, require new and complex software in hosts and +routers. Because per-connection QoS guaranteed service has not seen +significant deployment, we'll cover these mechanisms only briefly in +Section 9.5.4. + + 9.5.1 Dimensioning Best-Effort Networks Fundamentally, the difficulty in +supporting multimedia applications arises from their stringent +performance requirements---low end-to-end packet delay, delay jitter, +and loss---and the fact that packet delay, delay jitter, and loss occur +whenever the network becomes congested. A first approach to improving +the quality of multimedia applications---an approach that can often be +used to solve just about any problem where resources are +constrained---is simply to "throw money at the problem" and thus simply +avoid resource contention. In the case of networked multimedia, this +means providing enough link capacity throughout the network so that +network congestion, and its consequent packet delay and loss, never (or +only very rarely) occurs. With enough link capacity, packets could zip +through today's Internet without queuing delay or loss. From many +perspectives this is an ideal situation---multimedia applications would +perform perfectly, users would be happy, and this could all be achieved +with no changes to Internet's best-effort architecture. The question, of +course, is how much capacity is "enough" to achieve this nirvana, and +whether the costs of providing "enough" bandwidth are practical from a +business standpoint to the ISPs. The question of how much capacity to +provide at network links in a given topology to achieve a given level of +performance is often known as bandwidth provisioning. The even more +complicated problem of how to design a network topology (where to place +routers, how to interconnect routers with links, and what capacity to +assign to links) to achieve a given level of end-to-end performance is a +network design problem often referred to as network dimensioning. Both +bandwidth provisioning and network dimensioning are complex topics, well +beyond the scope of this textbook. We note here, however, that the +following issues must be addressed in order to predict application-level +performance between two network end points, and thus provision enough +capacity to meet an application's performance requirements. Models of +traffic demand between network end points. Models may need to be +specified at both the call level (for example, users "arriving" to the +network and starting up end-to-end applications) and at the packet level +(for example, packets being generated by ongoing applications). Note +that workload may change over time. Well-defined performance +requirements. For example, a performance requirement for supporting +delay-sensitive traffic, such as a conversational multimedia +application, might be that the probability that the end-to-end delay of +the packet is greater than a maximum tolerable delay be less than some +small value \[Fraleigh 2003\]. Models to predict end-to-end performance +for a given workload model, and techniques to find a minimal cost +bandwidth allocation that will result in all user requirements being +met. Here, researchers are busy developing performance models that can +quantify performance for a given workload, and optimization techniques +to find minimal-cost bandwidth allocations meeting performance +requirements. + + Given that today's best-effort Internet could (from a technology +standpoint) support multimedia traffic at an appropriate performance +level if it were dimensioned to do so, the natural question is why +today's Internet doesn't do so. The answers are primarily economic and +organizational. From an economic standpoint, would users be willing to +pay their ISPs enough for the ISPs to install sufficient bandwidth to +support multimedia applications over a best-effort Internet? The +organizational issues are perhaps even more daunting. Note that an +end-to-end path between two multimedia end points will pass through the +networks of multiple ISPs. From an organizational standpoint, would +these ISPs be willing to cooperate (perhaps with revenue sharing) to +ensure that the end-to-end path is properly dimensioned to support +multimedia applications? For a perspective on these economic and +organizational issues, see \[Davies 2005\]. For a perspective on +provisioning tier-1 backbone networks to support delay-sensitive +traffic, see \[Fraleigh 2003\]. + +9.5.2 Providing Multiple Classes of Service Perhaps the simplest +enhancement to the one-size-fits-all best-effort service in today's +Internet is to divide traffic into classes, and provide different levels +of service to these different classes of traffic. For example, an ISP +might well want to provide a higher class of service to delay-sensitive +Voice-over-IP or teleconferencing traffic (and charge more for this +service!) than to elastic traffic such as e-mail or HTTP. Alternatively, +an ISP may simply want to provide a higher quality of service to +customers willing to pay more for this improved service. A number of +residential wired-access ISPs and cellular wireless-access ISPs have +adopted such tiered levels of service---with platinum-service +subscribers receiving better performance than gold- or silver-service +subscribers. We're all familiar with different classes of service from +our everyday lives---first-class airline passengers get better service +than business-class passengers, who in turn get better service than +those of us who fly economy class; VIPs are provided immediate entry to +events while everyone else waits in line; elders are revered in some +countries and provided seats of honor and the finest food at a table. +It's important to note that such differential service is provided among +aggregates of traffic, that is, among classes of traffic, not among +individual connections. For example, all first-class passengers are +handled the same (with no first-class passenger receiving any better +treatment than any other first-class passenger), just as all VoIP +packets would receive the same treatment within the network, independent +of the particular end-to-end connection to which they belong. As we will +see, by dealing with a small number of traffic aggregates, rather than a +large number of individual connections, the new network mechanisms +required to provide better-than-best service can be kept relatively +simple. The early Internet designers clearly had this notion of multiple +classes of service in mind. Recall the type-of-service (ToS) field in +the IPv4 header discussed in Chapter 4. IEN123 \[ISI 1979\] describes +the ToS field also present in an ancestor of the IPv4 datagram as +follows: "The Type of Service \[field\] + + provides an indication of the abstract parameters of the quality of +service desired. These parameters are to be used to guide the selection +of the actual service parameters when transmitting a datagram through a +particular network. Several networks offer service precedence, which +somehow treats high precedence traffic as more important that other +traffic." More than four decades ago, the vision of providing different +levels of service to different classes of traffic was clear! However, +it's taken us an equally long period of time to realize this vision. +Motivating Scenarios Let's begin our discussion of network mechanisms +for providing multiple classes of service with a few motivating +scenarios. Figure 9.11 shows a simple network scenario in which two +application packet flows originate on Hosts H1 and H2 on one LAN and are +destined for Hosts H3 and H4 on another LAN. The routers on the two LANs +are connected by a 1.5 Mbps link. Let's assume the LAN speeds are +significantly higher than 1.5 Mbps, and focus on the output queue of +router R1; it is here that packet delay and packet loss will occur if +the aggregate sending rate of H1 and H2 exceeds 1.5 Mbps. Let's further +suppose that a 1 Mbps audio application (for example, a CD-quality audio +call) shares the + +Figure 9.11 Competing audio and HTTP applications + +1.5 Mbps link between R1 and R2 with an HTTP Web-browsing application +that is downloading a Web page from H2 to H4. In the best-effort +Internet, the audio and HTTP packets are mixed in the output queue at R1 +and (typically) transmitted in a first-in-first-out (FIFO) order. In +this scenario, a burst of packets from the Web + + server could potentially fill up the queue, causing IP audio packets to +be excessively delayed or lost due to buffer overflow at R1. How should +we solve this potential problem? Given that the HTTP Webbrowsing +application does not have time constraints, our intuition might be to +give strict priority to audio packets at R1. Under a strict priority +scheduling discipline, an audio packet in the R1 output buffer would +always be transmitted before any HTTP packet in the R1 output buffer. +The link from R1 to R2 would look like a dedicated link of 1.5 Mbps to +the audio traffic, with HTTP traffic using the R1-to-R2 link only when +no audio traffic is queued. In order for R1 to distinguish between the +audio and HTTP packets in its queue, each packet must be marked as +belonging to one of these two classes of traffic. This was the original +goal of the type-of-service (ToS) field in IPv4. As obvious as this +might seem, this then is our first insight into mechanisms needed to +provide multiple classes of traffic: Insight 1: Packet marking allows a +router to distinguish among packets belonging to different classes of +traffic. Note that although our example considers a competing multimedia +and elastic flow, the same insight applies to the case that platinum, +gold, and silver classes of service are implemented---a packetmarking +mechanism is still needed to indicate that class of service to which a +packet belongs. Now suppose that the router is configured to give +priority to packets marked as belonging to the 1 Mbps audio application. +Since the outgoing link speed is 1.5 Mbps, even though the HTTP packets +receive lower priority, they can still, on average, receive 0.5 Mbps of +transmission service. But what happens if the audio application starts +sending packets at a rate of 1.5 Mbps or higher (either maliciously or +due to an error in the application)? In this case, the HTTP packets will +starve, that is, they will not receive any service on the R1-to-R2 link. +Similar problems would occur if multiple applications (for example, +multiple audio calls), all with the same class of service as the audio +application, were sharing the link's bandwidth; they too could +collectively starve the FTP session. Ideally, one wants a degree of +isolation among classes of traffic so that one class of traffic can be +protected from the other. This protection could be implemented at +different places in the network---at each and every router, at first +entry to the network, or at inter-domain network boundaries. This then +is our second insight: Insight 2: It is desirable to provide a degree of +traffic isolation among classes so that one class is not adversely +affected by another class of traffic that misbehaves. We'll examine +several specific mechanisms for providing such isolation among traffic +classes. We note here that two broad approaches can be taken. First, it +is possible to perform traffic policing, as shown in Figure 9.12. If a +traffic class or flow must meet certain criteria (for example, that the +audio flow not exceed a peak rate of 1 Mbps), then a policing mechanism +can be put into place to ensure that these criteria are indeed observed. +If the policed application misbehaves, the policing mechanism will take +some action (for example, drop or delay packets that are in violation of +the criteria) so that the traffic actually entering the network conforms +to the criteria. The leaky bucket mechanism that we'll examine + + shortly is perhaps the most widely used policing mechanism. In Figure +9.12, the packet classification and marking mechanism (Insight 1) and +the policing mechanism (Insight 2) are both implemented together at the +network's edge, either in the end system or at an edge router. A +complementary approach for providing isolation among traffic classes is +for the link-level packetscheduling mechanism to explicitly allocate a +fixed amount of link bandwidth to each class. For example, the audio +class could be allocated 1 Mbps at R1, and the HTTP class could be +allocated 0.5 Mbps. In this case, the audio and + +Figure 9.12 Policing (and marking) the audio and HTTP traffic classes + + Figure 9.13 Logical isolation of audio and HTTP traffic classes + +HTTP flows see a logical link with capacity 1.0 and 0.5 Mbps, +respectively, as shown in Figure 9.13. With strict enforcement of the +link-level allocation of bandwidth, a class can use only the amount of +bandwidth that has been allocated; in particular, it cannot utilize +bandwidth that is not currently being used by others. For example, if +the audio flow goes silent (for example, if the speaker pauses and +generates no audio packets), the HTTP flow would still not be able to +transmit more than 0.5 Mbps over the R1-to-R2 link, even though the +audio flow's 1 Mbps bandwidth allocation is not being used at that +moment. Since bandwidth is a "use-it-or-lose-it" resource, there is no +reason to prevent HTTP traffic from using bandwidth not used by the +audio traffic. We'd like to use bandwidth as efficiently as possible, +never wasting it when it could be otherwise used. This gives rise to our +third insight: Insight 3: While providing isolation among classes or +flows, it is desirable to use resources (for example, link bandwidth and +buffers) as efficiently as possible. Recall from our discussion in +Sections 1.3 and 4.2 that packets belonging to various network flows are +multiplexed and queued for transmission at the output buffers associated +with a link. The manner in which queued packets are selected for +transmission on the link is known as the link-scheduling discipline, and +was discussed in detail in Section 4.2. Recall that in Section 4.2 three +link-scheduling disciplines were discussed, namely, FIFO, priority +queuing, and Weighted Fair Queuing (WFQ). We'll see soon see that WFQ +will play a particularly important role for isolating the traffic +classes. The Leaky Bucket One of our earlier insights was that policing, +the regulation of the rate at which a class or flow (we will assume the +unit of policing is a flow in our discussion below) is allowed to inject +packets into the + + network, is an important QoS mechanism. But what aspects of a flow's +packet rate should be policed? We can identify three important policing +criteria, each differing from the other according to the time scale over +which the packet flow is policed: Average rate. The network may wish to +limit the long-term average rate (packets per time interval) at which a +flow's packets can be sent into the network. A crucial issue here is the +interval of time over which the average rate will be policed. A flow +whose average rate is limited to 100 packets per second is more +constrained than a source that is limited to 6,000 packets per minute, +even though both have the same average rate over a long enough interval +of time. For example, the latter constraint would allow a flow to send +1,000 packets in a given second-long interval of time, while the former +constraint would disallow this sending behavior. Peak rate. While the +average-rate constraint limits the amount of traffic that can be sent +into the network over a relatively long period of time, a peak-rate +constraint limits the maximum number of packets that can be sent over a +shorter period of time. Using our example above, the network may police +a flow at an average rate of 6,000 packets per minute, while limiting +the flow's peak rate to 1,500 packets per second. Burst size. The +network may also wish to limit the maximum number of packets (the +"burst" of packets) that can be sent into the network over an extremely +short interval of time. In the limit, as the interval length approaches +zero, the burst size limits the number of packets that can be +instantaneously sent into the network. Even though it is physically +impossible to instantaneously send multiple packets into the network +(after all, every link has a physical transmission rate that cannot be +exceeded!), the abstraction of a maximum burst size is a useful one. The +leaky bucket mechanism is an abstraction that can be used to +characterize these policing limits. As shown in Figure 9.14, a leaky +bucket consists of a bucket that can hold up to b tokens. Tokens are +added to this bucket as follows. New tokens, which may potentially be +added to the bucket, are always being generated at a rate of r tokens +per second. (We assume here for simplicity that the unit of time is a +second.) If the bucket is filled with less than b tokens when a token is +generated, the newly generated token is added to the bucket; otherwise +the newly generated token is ignored, and the token bucket remains full +with b tokens. Let us now consider how the leaky bucket can be used to +police a packet flow. Suppose that before a packet is transmitted into +the network, it must first remove a token from the token bucket. If the +token bucket is empty, the packet must wait for + + Figure 9.14 The leaky bucket policer + +a token. (An alternative is for the packet to be dropped, although we +will not consider that option here.) Let us now consider how this +behavior polices a traffic flow. Because there can be at most b tokens +in the bucket, the maximum burst size for a leaky-bucket-policed flow is +b packets. Furthermore, because the token generation rate is r, the +maximum number of packets that can enter the network of any interval of +time of length t is rt+b. Thus, the token-generation rate, r, serves to +limit the long-term average rate at which packets can enter the network. +It is also possible to use leaky buckets (specifically, two leaky +buckets in series) to police a flow's peak rate in addition to the +long-term average rate; see the homework problems at the end of this +chapter. Leaky Bucket + Weighted Fair Queuing = Provable Maximum Delay +in a Queue Let's close our discussion on policing by showing how the +leaky bucket and WFQ can be combined to provide a bound on the delay +through a router's queue. (Readers who have forgotten about WFQ are +encouraged to review WFQ, which is covered in Section 4.2.) Let's +consider a router's output link that multiplexes n flows, each policed +by a leaky bucket with parameters bi and ri,i=1,...,n, using WFQ +scheduling. We use the term flow here loosely to refer to the set of +packets that are not distinguished from each other by the scheduler. In +practice, a flow might be comprised of traffic from a single end-toend +connection or a collection of many such connections, see Figure 9.15. +Recall from our discussion of WFQ that each flow, i, is guaranteed to +receive a share of the link bandwidth equal to at least R⋅wi/(∑ wj), +where R is the transmission + + Figure 9.15 n multiplexed leaky bucket flows with WFQ scheduling + +rate of the link in packets/sec. What then is the maximum delay that a +packet will experience while waiting for service in the WFQ (that is, +after passing through the leaky bucket)? Let us focus on flow 1. Suppose +that flow 1's token bucket is initially full. A burst of b1 packets then +arrives to the leaky bucket policer for flow 1. These packets remove all +of the tokens (without wait) from the leaky bucket and then join the WFQ +waiting area for flow 1. Since these b1 packets are served at a rate of +at least R⋅wi/(∑ wj) packet/sec, the last of these packets will then +have a maximum delay, dmax, until its transmission is completed, where +dmax=b1R⋅w1/∑ wj The rationale behind this formula is that if there are +b1 packets in the queue and packets are being serviced (removed) from +the queue at a rate of at least R⋅w1/(∑ wj) packets per second, then the +amount of time until the last bit of the last packet is transmitted +cannot be more than b1/(R⋅w1/(∑ wj)). A homework problem asks you to +prove that as long as r1\<R⋅w1/(∑ wj), then dmax is indeed the maximum +delay that any packet in flow 1 will ever experience in the WFQ queue. + +9.5.3 Diffserv Having seen the motivation, insights, and specific +mechanisms for providing multiple classes of service, let's wrap up our +study of approaches toward proving multiple classes of service with an +example---the Internet Diffserv architecture \[RFC 2475; Kilkki 1999\]. +Diffserv provides service differentiation---that is, the ability to +handle different classes of traffic in different ways within the +Internet in a scalable manner. + + The need for scalability arises from the fact that millions of +simultaneous source-destination traffic flows may be present at a +backbone router. We'll see shortly that this need is met by placing only +simple functionality within the network core, with more complex control +operations being implemented at the network's edge. Let's begin with the +simple network shown in Figure 9.16. We'll describe one possible use of +Diffserv here; other variations are possible, as described in RFC 2475. +The Diffserv architecture consists of two sets of functional elements: +Edge functions: Packet classification and traffic conditioning. At the +incoming edge of the network (that is, at either a Diffserv-capable host +that generates traffic or at the first Diffserv-capable router that the +traffic passes through), arriving packets are marked. More specifically, +the differentiated service (DS) field in the IPv4 or IPv6 packet header +is set to some value \[RFC 3260\]. The definition of the DS field is +intended to supersede the earlier definitions of the IPv4 type-ofservice +field and the IPv6 traffic class fields that we discussed in Chapter 4. +For example, in Figure 9.16, packets being sent from H1 to H3 might be +marked at R1, while packets being sent from H2 to H4 might be marked at +R2. The mark that a packet receives identifies the class of traffic to +which it belongs. Different classes of traffic will then receive +different service within the core network. + +Figure 9.16 A simple Diffserv network example + +Core function: Forwarding. When a DS-marked packet arrives at a +Diffserv-capable router, the packet is forwarded onto its next hop +according to the so-called per-hop behavior (PHB) associated with that +packet's class. The per-hop behavior influences how a router's buffers +and link bandwidth are shared among the competing classes of traffic. A +crucial tenet of the Diffserv architecture is that + + a router's per-hop behavior will be based only on packet markings, that +is, the class of traffic to which a packet belongs. Thus, if packets +being sent from H1 to H3 in Figure 9.16 receive the same marking as +packets being sent from H2 to H4, then the network routers treat these +packets as an aggregate, without distinguishing whether the packets +originated at H1 or H2. For example, R3 would not distinguish between +packets from H1 and H2 when forwarding these packets on to R4. Thus, the +Diffserv architecture obviates the need to keep router state for +individual sourcedestination pairs---a critical consideration in making +Diffserv scalable. An analogy might prove useful here. At many +large-scale social events (for example, a large public reception, a +large dance club or discothèque, a concert, or a football game), people +entering the event receive a pass of one type or another: VIP passes for +Very Important People; over-21 passes for people who are 21 years old or +older (for example, if alcoholic drinks are to be served); backstage +passes at concerts; press passes for reporters; even an ordinary pass +for the Ordinary Person. These passes are typically distributed upon +entry to the event, that is, at the edge of the event. It is here at the +edge where computationally intensive operations, such as paying for +entry, checking for the appropriate type of invitation, and matching an +invitation against a piece of identification, are performed. +Furthermore, there may be a limit on the number of people of a given +type that are allowed into an event. If there is such a limit, people +may have to wait before entering the event. Once inside the event, one's +pass allows one to receive differentiated service at many locations +around the event---a VIP is provided with free drinks, a better table, +free food, entry to exclusive rooms, and fawning service. Conversely, an +ordinary person is excluded from certain areas, pays for drinks, and +receives only basic service. In both cases, the service received within +the event depends solely on the type of one's pass. Moreover, all people +within a class are treated alike. Figure 9.17 provides a logical view of +the classification and marking functions within the edge router. Packets +arriving to the edge router are first classified. The classifier selects +packets based on the values of one or more packet header fields (for +example, source address, destination address, source port, destination +port, and protocol ID) and steers the packet to the appropriate marking +function. As noted above, a packet's marking is carried in the DS field +in the packet header. In some cases, an end user may have agreed to +limit its packet-sending rate to conform to a declared traffic profile. +The traffic profile might contain a limit on the peak rate, as well as +the burstiness of the packet flow, as we saw previously with the leaky +bucket mechanism. As long as the user sends packets into the network in +a way that conforms to the negotiated traffic profile, the packets +receive their priority + + Figure 9.17 A simple Diffserv network example + +marking and are forwarded along their route to the destination. On the +other hand, if the traffic profile is violated, out-of-profile packets +might be marked differently, might be shaped (for example, delayed so +that a maximum rate constraint would be observed), or might be dropped +at the network edge. The role of the metering function, shown in Figure +9.17, is to compare the incoming packet flow with the negotiated traffic +profile and to determine whether a packet is within the negotiated +traffic profile. The actual decision about whether to immediately +remark, forward, delay, or drop a packet is a policy issue determined by +the network administrator and is not specified in the Diffserv +architecture. So far, we have focused on the marking and policing +functions in the Diffserv architecture. The second key component of the +Diffserv architecture involves the per-hop behavior (PHB) performed by +Diffservcapable routers. PHB is rather cryptically, but carefully, +defined as "a description of the externally observable forwarding +behavior of a Diffserv node applied to a particular Diffserv behavior +aggregate" \[RFC 2475\]. Digging a little deeper into this definition, +we can see several important considerations embedded within: A PHB can +result in different classes of traffic receiving different performance +(that is, different externally observable forwarding behaviors). While a +PHB defines differences in performance (behavior) among classes, it does +not mandate any particular mechanism for achieving these behaviors. As +long as the externally observable performance criteria are met, any +implementation mechanism and any buffer/bandwidth allocation policy can +be used. For example, a PHB would not require that a particular +packet-queuing discipline (for example, a priority queue versus a WFQ +queue versus a FCFS queue) be used to achieve a particular behavior. The +PHB is the end, to which resource allocation and implementation +mechanisms are the means. Differences in performance must be observable +and hence measurable. + + Two PHBs have been defined: an expedited forwarding (EF) PHB \[RFC +3246\] and an assured forwarding (AF) PHB \[RFC 2597\]. The expedited +forwarding PHB specifies that the departure rate of a class of traffic +from a router must equal or exceed a configured rate. The assured +forwarding PHB divides traffic into four classes, where each AF class is +guaranteed to be provided with some minimum amount of bandwidth and +buffering. Let's close our discussion of Diffserv with a few +observations regarding its service model. First, we have implicitly +assumed that Diffserv is deployed within a single administrative domain, +but typically an endto-end service must be fashioned from multiple ISPs +sitting between communicating end systems. In order to provide +end-to-end Diffserv service, all the ISPs between the end systems must +not only provide this service, but most also cooperate and make +settlements in order to offer end customers true end-to-end service. +Without this kind of cooperation, ISPs directly selling Diffserv service +to customers will find themselves repeatedly saying: "Yes, we know you +paid extra, but we don't have a service agreement with the ISP that +dropped and delayed your traffic. I'm sorry that there were so many gaps +in your VoIP call!" Second, if Diffserv were actually in place and the +network ran at only moderate load, most of the time there would be no +perceived difference between a best-effort service and a Diffserv +service. Indeed, end-to-end delay is usually dominated by access rates +and router hops rather than by queuing delays in the routers. Imagine +the unhappy Diffserv customer who has paid more for premium service but +finds that the best-effort service being provided to others almost +always has the same performance as premium service! + +9.5.4 Per-Connection Quality-of-Service (QoS) Guarantees: Resource +Reservation and Call Admission In the previous section, we have seen +that packet marking and policing, traffic isolation, and link-level +scheduling can provide one class of service with better performance than +another. Under certain scheduling disciplines, such as priority +scheduling, the lower classes of traffic are essentially "invisible" to +the highest-priority class of traffic. With proper network dimensioning, +the highest class of service can indeed achieve extremely low packet +loss and delay---essentially circuit-like performance. But can the +network guarantee that an ongoing flow in a high-priority traffic class +will continue to receive such service throughout the flow's duration +using only the mechanisms that we have described so far? It cannot. In +this section, we'll see why yet additional network mechanisms and +protocols are required when a hard service guarantee is provided to +individual connections. Let's return to our scenario from Section 9.5.2 +and consider two 1 Mbps audio applications transmitting their packets +over the 1.5 Mbps link, as shown in Figure 9.18. The combined data rate +of the two flows (2 Mbps) exceeds the link capacity. Even with +classification and marking, isolation of flows, and sharing of unused +bandwidth (of which there is none), this is clearly a losing +proposition. There is simply not + + enough bandwidth to accommodate the needs of both applications at + +Figure 9.18 Two competing audio applications overloading the R1-to-R2 +link + +the same time. If the two applications equally share the bandwidth, each +application would lose 25 percent of its transmitted packets. This is +such an unacceptably low QoS that both audio applications are completely +unusable; there's no need even to transmit any audio packets in the +first place. Given that the two applications in Figure 9.18 cannot both +be satisfied simultaneously, what should the network do? Allowing both +to proceed with an unusable QoS wastes network resources on application +flows that ultimately provide no utility to the end user. The answer is +hopefully clear---one of the application flows should be blocked (that +is, denied access to the network), while the other should be allowed to +proceed on, using the full 1 Mbps needed by the application. The +telephone network is an example of a network that performs such call +blocking---if the required resources (an end-to-end circuit in the case +of the telephone network) cannot be allocated to the call, the call is +blocked (prevented from entering the network) and a busy signal is +returned to the user. In our example, there is no gain in allowing a +flow into the network if it will not receive a sufficient QoS to be +considered usable. Indeed, there is a cost to admitting a flow that does +not receive its needed QoS, as network resources are being used to +support a flow that provides no utility to the end user. By explicitly +admitting or blocking flows based on their resource requirements, and +the source requirements of already-admitted flows, the network can +guarantee that admitted flows will be able to receive their requested +QoS. Implicit in the need to provide a guaranteed QoS to a flow is the +need for the flow to declare its QoS requirements. This process of +having a flow declare its QoS requirement, and then having the network +either accept the flow (at the required QoS) or block the flow is +referred to as the call admission process. This then is our fourth +insight (in addition to the three earlier insights from Section 9.5.2,) +into the mechanisms needed to provide QoS. + + Insight 4: If sufficient resources will not always be available, and QoS +is to be guaranteed, a call admission process is needed in which flows +declare their QoS requirements and are then either admitted to the +network (at the required QoS) or blocked from the network (if the +required QoS cannot be provided by the network). Our motivating example +in Figure 9.18 highlights the need for several new network mechanisms +and protocols if a call (an end-to-end flow) is to be guaranteed a given +quality of service once it begins: Resource reservation. The only way to +guarantee that a call will have the resources (link bandwidth, buffers) +needed to meet its desired QoS is to explicitly allocate those resources +to the call---a process known in networking parlance as resource +reservation. Once resources are reserved, the call has on-demand access +to these resources throughout its duration, regardless of the demands of +all other calls. If a call reserves and receives a guarantee of x Mbps +of link bandwidth, and never transmits at a rate greater than x, the +call will see loss- and delay-free performance. Call admission. If +resources are to be reserved, then the network must have a mechanism for +calls to request and reserve resources. Since resources are not +infinite, a call making a call admission request will be denied +admission, that is, be blocked, if the requested resources are not +available. Such a call admission is performed by the telephone +network---we request resources when we dial a number. If the circuits +(TDMA slots) needed to complete the call are available, the circuits are +allocated and the call is completed. If the circuits are not available, +then the call is blocked, and we receive a busy signal. A blocked call +can try again to gain admission to the network, but it is not allowed to +send traffic into the network until it has successfully completed the +call admission process. Of course, a router that allocates link +bandwidth should not allocate more than is available at that link. +Typically, a call may reserve only a fraction of the link's bandwidth, +and so a router may allocate link bandwidth to more than one call. +However, the sum of the allocated bandwidth to all calls should be less +than the link capacity if hard quality of service guarantees are to be +provided. Call setup signaling. The call admission process described +above requires that a call be able to reserve sufficient resources at +each and every network router on its source-to-destination path to +ensure that its end-to-end QoS requirement is met. Each router must +determine the local resources required by the session, consider the +amounts of its resources that are already committed to other ongoing +sessions, and determine whether it has sufficient resources to satisfy +the per-hop QoS requirement of the session at this router without +violating local QoS guarantees made to an alreadyadmitted session. A +signaling protocol is needed to coordinate these various +activities---the per-hop allocation of local resources, as well as the +overall end-to-end decision of whether or not the call has been able to +reserve suf + + Figure 9.19 The call setup process + +ficient resources at each and every router on the end-to-end path. This +is the job of the call setup protocol, as shown in Figure 9.19. The RSVP +protocol \[Zhang 1993, RFC 2210\] was proposed for this purpose within +an Internet architecture for providing quality-of-service guarantees. In +ATM networks, the Q2931b protocol \[Black 1995\] carries this +information among the ATM network's switches and end point. Despite a +tremendous amount of research and development, and even products that +provide for perconnection quality of service guarantees, there has been +almost no extended deployment of such services. There are many possible +reasons. First and foremost, it may well be the case that the simple +application-level mechanisms that we studied in Sections 9.2 through +9.4, combined with proper network dimensioning (Section 9.5.1) provide +"good enough" best-effort network service for multimedia applications. +In addition, the added complexity and cost of deploying and managing a +network that provides per-connection quality of service guarantees may +be judged by ISPs to be simply too high given predicted customer +revenues for that service. + + 9.6 Summary Multimedia networking is one of the most exciting +developments in the Internet today. People throughout the world less and +less time in front of their televisions, and are instead use their +smartphones and devices to receive audio and video transmissions, both +live and prerecorded. Moreover, with sites like YouTube, users have +become producers as well as consumers of multimedia Internet content. In +addition to video distribution, the Internet is also being used to +transport phone calls. In fact, over the next 10 years, the Internet, +along with wireless Internet access, may make the traditional +circuitswitched telephone system a thing of the past. VoIP not only +provides phone service inexpensively, but also provides numerous +value-added services, such as video conferencing, online directory +services, voice messaging, and integration into social networks such as +Facebook and WeChat. In Section 9.1, we described the intrinsic +characteristics of video and voice, and then classified multimedia +applications into three categories: (i) streaming stored audio/video, +(ii) conversational voice/video-over-IP, and (iii) streaming live +audio/video. In Section 9.2, we studied streaming stored video in some +depth. For streaming video applications, prerecorded videos are placed +on servers, and users send requests to these servers to view the videos +on demand. We saw that streaming video systems can be classified into +two categories: UDP streaming and HTTP. We observed that the most +important performance measure for streaming video is average throughput. +In Section 9.3, we examined how conversational multimedia applications, +such as VoIP, can be designed to run over a best-effort network. For +conversational multimedia, timing considerations are important because +conversational applications are highly delay-sensitive. On the other +hand, conversational multimedia applications are +loss---tolerant---occasional loss only causes occasional glitches in +audio/video playback, and these losses can often be partially or fully +concealed. We saw how a combination of client buffers, packet sequence +numbers, and timestamps can greatly alleviate the effects of +network-induced jitter. We also surveyed the technology behind Skype, +one of the leading voice- and video-over-IP companies. In Section 9.4, +we examined two of the most important standardized protocols for VoIP, +namely, RTP and SIP. In Section 9.5, we introduced how several network +mechanisms (link-level scheduling disciplines and traffic policing) can +be used to provide differentiated service among several classes of +traffic. + + Homework Problems and Questions + +Chapter 9 Review Questions + +SECTION 9.1 R1. Reconstruct Table 9.1 for when Victor Video is watching +a 4 Mbps video, Facebook Frank is looking at a new 100 Kbyte image every +20 seconds, and Martha Music is listening to 200 kbps audio stream. R2. +There are two types of redundancy in video. Describe them, and discuss +how they can be exploited for efficient compression. R3. Suppose an +analog audio signal is sampled 16,000 times per second, and each sample +is quantized into one of 1024 levels. What would be the resulting bit +rate of the PCM digital audio signal? R4. Multimedia applications can be +classified into three categories. Name and describe each category. + +SECTION 9.2 R5. Streaming video systems can be classified into three +categories. Name and briefly describe each of these categories. R6. List +three disadvantages of UDP streaming. R7. With HTTP streaming, are the +TCP receive buffer and the client's application buffer the same thing? +If not, how do they interact? R8. Consider the simple model for HTTP +streaming. Suppose the server sends bits at a constant rate of 2 Mbps +and playback begins when 8 million bits have been received. What is the +initial buffering delay tp? + +SECTION 9.3 R9. What is the difference between end-to-end delay and +packet jitter? What are the causes of packet jitter? R10. Why is a +packet that is received after its scheduled playout time considered +lost? R11. Section 9.3 describes two FEC schemes. Briefly summarize +them. Both schemes increase the transmission rate of the stream by +adding overhead. Does interleaving also increase the + + transmission rate? + +SECTION 9.4 R12. How are different RTP streams in different sessions +identified by a receiver? How are different streams from within the same +session identified? R13. What is the role of a SIP registrar? How is the +role of an SIP registrar different from that of a home agent in Mobile +IP? + +Problems P1. Consider the figure below. Similar to our discussion of +Figure 9.1 , suppose that video is encoded at a fixed bit rate, and thus +each video block contains video frames that are to be played out over +the same fixed amount of time, Δ. The server transmits the first video +block at t0, the second block at t0+Δ, the third block at t0+2Δ, and so +on. Once the client begins playout, each block should be played out Δ +time units after the previous block. + +a. Suppose that the client begins playout as soon as the first block + arrives at t1. In the figure below, how many blocks of video + (including the first block) will have arrived at the client in time + for their playout? Explain how you arrived at your answer. + +b. Suppose that the client begins playout now at t1+Δ. How many blocks + of video (including the first block) will have arrived at the client + in time for their playout? Explain how you arrived at your answer. + +c. In the same scenario at (b) above, what is the largest number of + blocks that is ever stored in the client buffer, awaiting playout? + Explain how you arrived at your answer. + +d. What is the smallest playout delay at the client, such that every + video block has arrived in time for its playout? Explain how you + arrived at your answer. + + P2. Recall the simple model for HTTP streaming shown in Figure 9.3 . +Recall that B denotes the size of the client's application buffer, and Q +denotes the number of bits that must be buffered before the client +application begins playout. Also r denotes the video consumption rate. +Assume that the server sends bits at a constant rate x whenever the +client buffer is not full. a. Suppose that x\<r. As discussed in the +text, in this case playout will alternate between periods of continuous +playout and periods of freezing. Determine the length of each continuous +playout and freezing period as a function of Q, r, and x. b. Now suppose +that x\>r. At what time t=tf does the client application buffer become +full? P3. Recall the simple model for HTTP streaming shown in Figure 9.3 +. Suppose the buffer size is infinite but the server sends bits at +variable rate x(t). Specifically, suppose x(t) has the following +saw-tooth shape. The rate is initially zero at time t=0 and linearly +climbs to H at time t=T. It then repeats this pattern again and again, +as shown in the figure below. + +a. What is the server's average send rate? + +b. Suppose that Q=0, so that the client starts playback as soon as it + receives a video frame. What will happen? + +c. Now suppose Q\>0 and HT/2≥Q. Determine as a function of Q, H, and T + the time at which playback first begins. + +d. Suppose H\>2r and Q=HT/2. Prove there will be no freezing after the + initial playout delay. + +e. Suppose H\>2r. Find the smallest value of Q such that there will be + no freezing after the initial playback delay. + +f. Now suppose that the buffer size B is finite. Suppose H\>2r. As a + function of Q, B, T, and H, determine the time t=tf when the client + application buffer first becomes full. P4. Recall the simple model + for HTTP streaming shown in Figure 9.3 . Suppose the client + application buffer is infinite, the server sends at the constant + rate x, and the video consumption r\<x. + + rate is r with Also suppose playback begins immediately. Suppose that +the user terminates the video early at time t=E. At the time of +termination, the server stops sending bits (if it hasn't already sent +all the bits in the video). + +a. Suppose the video is infinitely long. How many bits are wasted (that + is, sent but not viewed)? + +b. Suppose the video is T seconds long with T\>E. How many bits are + wasted (that is, sent but not viewed)? P5. Consider a DASH system + (as discussed in Section 2.6 ) for which there are N video versions + (at N different rates and qualities) and N audio versions (at N + different rates and qualities). Suppose we want to allow the player + to choose at any time any of the N video versions and any of the N + audio versions. + +c. If we create files so that the audio is mixed in with the video, so + server sends only one media stream at given time, how many files + will the server need to store (each a different URL)? + +d. If the server instead sends the audio and video streams separately + and has the client synchronize the streams, how many files will the + server need to store? P6. In the VoIP example in Section 9.3 , let h + be the total number of header bytes added to each chunk, including + UDP and IP header. + +e. Assuming an IP datagram is emitted every 20 msecs, find the + transmission rate in bits per second for the datagrams generated by + one side of this application. + +f. What is a typical value of h when RTP is used? P7. Consider the + procedure described in Section 9.3 for estimating average delay di. + Suppose that u=0.1. Let r1−t1 be the most recent sample delay, let + r2−t2 be the next most recent sample delay, and so on. + +g. For a given audio application suppose four packets have arrived at + the receiver with sample delays r4−t4, r3−t3, r2−t2, and r1−t1. + Express the estimate of delay d in terms of the four samples. + +h. Generalize your formula for n sample delays. + +i. For the formula in part (b), let n approach infinity and give the + resulting formula. Comment on why this averaging procedure is called + an exponential moving average. P8. Repeat parts (a) and (b) in + Question P7 for the estimate of average delay deviation. P9. For the + VoIP example in Section 9.3 , we introduced an online procedure + (exponential moving average) for estimating delay. In this problem + we will examine an alternative procedure. Let ti be the timestamp of + the ith packet received; let ri be the time at which the ith packet + is received. Let dn be our estimate of average delay after receiving + the nth packet. After the first packet is received, we set the delay + estimate equal to d1=r1−t1. + + a. Suppose that we would like dn=(r1−t1+r2−t2+⋯+rn−tn)/n for all n. Give +a recursive formula for dn in terms of dn−1, rn, and tn. + +b. Describe why for Internet telephony, the delay estimate described in + Section 9.3 is more appropriate than the delay estimate outlined in + part (a). P10. Compare the procedure described in Section 9.3 for + estimating average delay with the procedure in Section 3.5 for + estimating round-trip time. What do the procedures have in common? + How are they different? P11. Consider the figure below (which is + similar to Figure 9.3 ). A sender begins sending packetized audio + periodically at t=1. The first packet arrives at the receiver at + t=8. + +c. What are the delays (from sender to receiver, ignoring any playout + delays) of packets 2 through 8? Note that each vertical and + horizontal line segment in the figure has a length of 1, 2, or 3 + time units. + +d. If audio playout begins as soon as the first packet arrives at the + receiver at t=8, which of the first eight packets sent will not + arrive in time for playout? + +e. If audio playout begins at t=9, which of the first eight packets + sent will not arrive in time for playout? + +f. What is the minimum playout delay at the receiver that results in + all of the first eight packets arriving in time for their playout? + P12. Consider again the figure in P11, showing packet audio + transmission and reception times. + +g. Compute the estimated delay for packets 2 through 8, using the + formula for di from Section 9.3.2 . Use a value of u=0.1. + + b. Compute the estimated deviation of the delay from the estimated +average for packets 2 through 8, using the formula for vi from Section +9.3.2 . Use a value of u=0.1. P13. Recall the two FEC schemes for VoIP +described in Section 9.3 . Suppose the first scheme generates a +redundant chunk for every four original chunks. Suppose the second +scheme uses a low-bit rate encoding whose transmission rate is 25 +percent of the transmission rate of the nominal stream. + +a. How much additional bandwidth does each scheme require? How much + playback delay does each scheme add? + +b. How do the two schemes perform if the first packet is lost in every + group of five packets? Which scheme will have better audio quality? + +c. How do the two schemes perform if the first packet is lost in every + group of two packets? Which scheme will have better audio quality? + P14. + +d. Consider an audio conference call in Skype with N\>2 participants. + Suppose each participant generates a constant stream of rate r bps. + How many bits per second will the call initiator need to send? How + many bits per second will each of the other N−1 participants need to + send? What is the total send rate, aggregated over all participants? + +e. Repeat part (a) for a Skype video conference call using a central + server. + +f. Repeat part (b), but now for when each peer sends a copy of its + video stream to each of the N−1 other peers. P15. + +g. Suppose we send into the Internet two IP datagrams, each carrying a + different UDP segment. The first datagram has source IP address A1, + destination IP address B, source port P1, and destination port T. + The second datagram has source IP address A2, destination IP address + B, source port P2, and destination port T. Suppose that A1 is + different from A2 and that P1 is different from P2. Assuming that + both datagrams reach their final destination, will the two UDP + datagrams be received by the same socket? Why or why not? + +h. Suppose Alice, Bob, and Claire want to have an audio conference call + using SIP and RTP. For Alice to send and receive RTP packets to and + from Bob and Claire, is only one UDP socket sufficient (in addition + to the socket needed for the SIP messages)? If yes, then how does + Alice's SIP client distinguish between the RTP packets received from + Bob and Claire? P16. True or false: + +i. If stored video is streamed directly from a Web server to a media + player, then the application is using TCP as the underlying + transport protocol. + + b. When using RTP, it is possible for a sender to change encoding in the +middle of a session. + +c. All applications that use RTP must use port 87. + +d. If an RTP session has a separate audio and video stream for each + sender, then the audio and video streams use the same SSRC. + +e. In differentiated services, while per-hop behavior defines + differences in performance among classes, it does not mandate any + particular mechanism for achieving these performances. + +f. Suppose Alice wants to establish an SIP session with Bob. In her + INVITE message she includes the line: m=audio 48753 RTP/AVP 3 (AVP 3 + denotes GSM audio). Alice has therefore indicated in this message + that she wishes to send GSM audio. + +g. Referring to the preceding statement, Alice has indicated in her + INVITE message that she will send audio to port 48753. + +h. SIP messages are typically sent between SIP entities using a default + SIP port number. + +i. In order to maintain registration, SIP clients must periodically + send REGISTER messages. + +j. SIP mandates that all SIP clients support G.711 audio encoding. P17. + Consider the figure below, which shows a leaky bucket policer being + fed by a stream of packets. The token buffer can hold at most two + tokens, and is initially full at t=0. New tokens arrive at a rate of + one token per slot. The output link speed is such that if two + packets obtain tokens at the beginning of a time slot, they can both + go to the output link in the same slot. The timing details of the + system are as follows: + +A. Packets (if any) arrive at the beginning of the slot. Thus in the +figure, packets 1, 2, and 3 arrive in slot 0. If there are already +packets in the queue, then the arriving packets join the end of the +queue. Packets proceed towards the front of the queue in a FIFO manner. + +B. After the arrivals have been added to the queue, if there are any +queued packets, one or two of those packets (depending on the number of +available tokens) will each remove a token from the token buffer and go +to the output link during that slot. Thus, packets 1 and + + 2 each remove a token from the buffer (since there are initially two +tokens) and go to the output link during slot 0. + +C. A new token is added to the token buffer if it is not full, since the +token generation rate is r = 1 token/slot. + +D. Time then advances to the next time slot, and these steps repeat. +Answer the following questions: + +a. For each time slot, identify the packets that are in the queue and + the number of tokens in the bucket, immediately after the arrivals + have been processed (step 1 above) but before any of the packets + have passed through the queue and removed a token. Thus, for the t=0 + time slot in the example above, packets 1, 2, and 3 are in the + queue, and there are two tokens in the buffer. + +b. For each time slot indicate which packets appear on the output after + the token(s) have been removed from the queue. Thus, for the t=0 + time slot in the example above, packets 1 and 2 appear on the output + link from the leaky buffer during slot 0. P18. Repeat P17 but assume + that r=2. Assume again that the bucket is initially full. P19. + Consider P18 and suppose now that r=3 and that b=2 as before. Will + your answer to the question above change? P20. Consider the leaky + bucket policer that polices the average rate and burst size of a + packet flow. We now want to police the peak rate, p, as well. Show + how the output of this leaky bucket policer can be fed into a second + leaky bucket policer so that the two leaky buckets in series police + the average rate, peak rate, and burst size. Be sure to give the + bucket size and token generation rate for the second policer. P21. A + packet flow is said to conform to a leaky bucket specification + (r, b) with burst size b and average rate r if the number of packets + that arrive to the leaky bucket is less than rt+b packets in every + interval of time of length t for all t. Will a packet flow that + conforms to a leaky bucket specification (r, b) ever have to wait at + a leaky bucket policer with parameters r and b? Justify your answer. + P22. Show that as long as r1\<Rw1/(∑ wj), then dmax is indeed the + maximum delay that any packet in flow 1 will ever experience in the + WFQ queue. Programming Assignment In this lab, you will implement a + streaming video server and client. The client will use the real-time + streaming protocol (RTSP) to control the actions of the server. The + server will use the real-time protocol (RTP) to packetize the video + for transport over UDP. You will be given Python code that partially + implements RTSP and RTP at the client and server. Your job will be + to complete both the client and server code. When you are finished, + you will have created a client-server application that does the + following: + + The client sends SETUP, PLAY, PAUSE, and TEARDOWN RTSP commands, and the +server responds to the commands. When the server is in the playing +state, it periodically grabs a stored JPEG frame, packetizes the frame +with RTP, and sends the RTP packet into a UDP socket. The client +receives the RTP packets, removes the JPEG frames, decompresses the +frames, and renders the frames on the client's monitor. The code you +will be given implements the RTSP protocol in the server and the RTP +depacketization in the client. The code also takes care of displaying +the transmitted video. You will need to implement RTSP in the client and +RTP server. This programming assignment will significantly enhance the +student's understanding of RTP, RTSP, and streaming video. It is highly +recommended. The assignment also suggests a number of optional +exercises, including implementing the RTSP DESCRIBE command at both +client and server. You can find full details of the assignment, as well +as an overview of the RTSP protocol, at the Web site +www.pearsonhighered.com/cs-resources. AN INTERVIEW WITH . . . Henning +Schulzrinne Henning Schulzrinne is a professor, chair of the Department +of Computer Science, and head of the Internet Real-Time Laboratory at +Columbia University. He is the co-author of RTP, RTSP, SIP, and +GIST---key protocols for audio and video communications over the +Internet. Henning received his BS in electrical and industrial +engineering at TU Darmstadt in Germany, his MS in electrical and +computer engineering at the University of Cincinnati, and his PhD in +electrical engineering at the University of Massachusetts, Amherst. + +What made you decide to specialize in multimedia networking? This +happened almost by accident. As a PhD student, I got involved with +DARTnet, an experimental network spanning the United States with T1 +lines. DARTnet was used as a proving ground for multicast and Internet +real-time tools. That led me to write my first audio tool, NeVoT. +Through some of the DARTnet participants, I became involved in the IETF, +in the then-nascent + + Audio Video Transport working group. This group later ended up +standardizing RTP. What was your first job in the computer industry? +What did it entail? My first job in the computer industry was soldering +together an Altair computer kit when I was a high school student in +Livermore, California. Back in Germany, I started a little consulting +company that devised an address management program for a travel +agency---storing data on cassette tapes for our TRS-80 and using an IBM +Selectric typewriter with a home-brew hardware interface as a printer. +My first real job was with AT&T Bell Laboratories, developing a network +emulator for constructing experimental networks in a lab environment. +What are the goals of the Internet Real-Time Lab? Our goal is to provide +components and building blocks for the Internet as the single future +communications infrastructure. This includes developing new protocols, +such as GIST (for network-layer signaling) and LoST (for finding +resources by location), or enhancing protocols that we have worked on +earlier, such as SIP, through work on rich presence, peer-to-peer +systems, next-generation emergency calling, and service creation tools. +Recently, we have also looked extensively at wireless systems for VoIP, +as 802.11b and 802.11n networks and maybe WiMax networks are likely to +become important last-mile technologies for telephony. We are also +trying to greatly improve the ability of users to diagnose faults in the +complicated tangle of providers and equipment, using a peer-to-peer +fault diagnosis system called DYSWIS (Do You See What I See). We try to +do practically relevant work, by building prototypes and open source +systems, by measuring performance of real systems, and by contributing +to IETF standards. What is your vision for the future of multimedia +networking? We are now in a transition phase; just a few years shy of +when IP will be the universal platform for multimedia services, from +IPTV to VoIP. We expect radio, telephone, and TV to be available even +during snowstorms and earthquakes, so when the Internet takes over the +role of these dedicated networks, users will expect the same level of +reliability. We will have to learn to design network technologies for an +ecosystem of competing carriers, service and content providers, serving +lots of technically untrained users and defending them against a small, +but destructive, set of malicious and criminal users. Changing protocols +is becoming increasingly hard. They are also becoming more complex, as +they need to take into account competing business interests, security, +privacy, and the lack of transparency of networks caused by firewalls +and network address translators. Since multimedia networking is becoming +the foundation for almost all of consumer + + entertainment, there will be an emphasis on managing very large +networks, at low cost. Users will expect ease of use, such as finding +the same content on all of their devices. Why does SIP have a promising +future? As the current wireless network upgrade to 3G networks proceeds, +there is the hope of a single multimedia signaling mechanism spanning +all types of networks, from cable modems, to corporate telephone +networks and public wireless networks. Together with software radios, +this will make it possible in the future that a single device can be +used on a home network, as a cordless BlueTooth phone, in a corporate +network via 802.11 and in the wide area via 3G networks. Even before we +have such a single universal wireless device, the personal mobility +mechanisms make it possible to hide the differences between networks. +One identifier becomes the universal means of reaching a person, rather +than remembering or passing around half a dozen technology- or +location-specific telephone numbers. SIP also breaks apart the provision +of voice (bit) transport from voice services. It now becomes technically +possible to break apart the local telephone monopoly, where one company +provides neutral bit transport, while others provide IP "dial tone" and +the classical telephone services, such as gateways, call forwarding, and +caller ID. Beyond multimedia signaling, SIP offers a new service that +has been missing in the Internet: event notification. We have +approximated such services with HTTP kludges and e-mail, but this was +never very satisfactory. Since events are a common abstraction for +distributed systems, this may simplify the construction of new services. +Do you have any advice for students entering the networking field? +Networking bridges disciplines. It draws from electrical engineering, +all aspects of computer science, operations research, statistics, +economics, and other disciplines. Thus, networking researchers have to +be familiar with subjects well beyond protocols and routing algorithms. +Given that networks are becoming such an important part of everyday +life, students wanting to make a difference in the field should think of +the new resource constraints in networks: human time and effort, rather +than just bandwidth or storage. Work in networking research can be +immensely satisfying since it is about allowing people to communicate +and exchange ideas, one of the essentials of being human. The Internet +has become the third major global infrastructure, next to the +transportation system and energy distribution. Almost no part of the +economy can work without high-performance networks, so there should be +plenty of opportunities for the foreseeable future. + + References A note on URLs. In the references below, we have provided +URLs for Web pages, Web-only documents, and other material that has not +been published in a conference or journal (when we have been able to +locate a URL for such material). We have not provided URLs for +conference and journal publications, as these documents can usually be +located via a search engine, from the conference Web site (e.g., papers +in all ACM SIGCOMM conferences and workshops can be located via +http://www.acm.org/ sigcomm), or via a digital library subscription. +While all URLs provided below were valid (and tested) in Jan. 2016, URLs +can become out of date. Please consult the online version of this book +(www.pearsonhighered .com/cs-resources) for an up-to-date bibliography. +A note on Internet Request for Comments (RFCs): Copies of Internet RFCs +are available at many sites. The RFC Editor of the Internet Society (the +body that oversees the RFCs) maintains the site, +http://www.rfc-editor.org. This site allows you to search for a specific +RFC by title, number, or authors, and will show updates to any RFCs +listed. Internet RFCs can be updated or obsoleted by later RFCs. Our +favorite site for getting RFCs is the original +source---http://www.rfc-editor.org. \[3GPP 2016\] Third Generation +Partnership Project homepage, http://www.3gpp.org/ + +\[Abramson 1970\] N. Abramson, "The Aloha System---Another Alternative +for Computer Communications," Proc. 1970 Fall Joint Computer Conference, +AFIPS Conference, p. 37, 1970. + +\[Abramson 1985\] N. Abramson, "Development of the Alohanet," IEEE +Transactions on Information Theory, Vol. IT-31, No. 3 (Mar. 1985), +pp. 119--123. + +\[Abramson 2009\] N. Abramson, "The Alohanet---Surfing for Wireless +Data," IEEE Communications Magazine, Vol. 47, No. 12, pp. 21--25. + +\[Adhikari 2011a\] V. K. Adhikari, S. Jain, Y. Chen, Z. L. Zhang, +"Vivisecting YouTube: An Active Measurement Study," Technical Report, +University of Minnesota, 2011. + +\[Adhikari 2012\] V. K. Adhikari, Y. Gao, F. Hao, M. Varvello, V. Hilt, +M. Steiner, Z. L. Zhang, "Unreeling Netflix: Understanding and Improving +Multi-CDN Movie Delivery," Technical Report, University of Minnesota, +2012. + +\[Afanasyev 2010\] A. Afanasyev, N. Tilley, P. Reiher, L. Kleinrock, +"Host-to-Host Congestion Control for TCP," IEEE Communications Surveys & +Tutorials, Vol. 12, No. 3, pp. 304--342. + +\[Agarwal 2009\] S. Agarwal, J. Lorch, "Matchmaking for Online Games and +Other Latency-sensitive P2P Systems," Proc. 2009 ACM SIGCOMM. + +\[Ager 2012\] B. Ager, N. Chatzis, A. Feldmann, N. Sarrar, S. Uhlig, W. +Willinger, "Anatomy of a Large European ISP," Sigcomm, 2012. + + \[Ahn 1995\] J. S. Ahn, P. B. Danzig, Z. Liu, and Y. Yan, "Experience +with TCP Vegas: Emulation and Experiment," Proc. 1995 ACM SIGCOMM +(Boston, MA, Aug. 1995), pp. 185--195. + +\[Akamai 2016\] Akamai homepage, http://www.akamai.com + +\[Akella 2003\] A. Akella, S. Seshan, A. Shaikh, "An Empirical +Evaluation of Wide-Area Internet Bottlenecks," Proc. 2003 ACM Internet +Measurement Conference (Miami, FL, Nov. 2003). + +\[Akhshabi 2011\] S. Akhshabi, A. C. Begen, C. Dovrolis, "An +Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive +Streaming over HTTP," Proc. 2011 ACM Multimedia Systems Conf. + +\[Akyildiz 2010\] I. Akyildiz, D. Gutierrex-Estevez, E. Reyes, "The +Evolution to 4G Cellular Systems, LTE Advanced," Physical Communication, +Elsevier, 3 (2010), 217--244. + +\[Albitz 1993\] P. Albitz and C. Liu, DNS and BIND, O'Reilly & +Associates, Petaluma, CA, 1993. + +\[Al-Fares 2008\] M. Al-Fares, A. Loukissas, A. Vahdat, "A Scalable, +Commodity Data Center Network Architecture," Proc. 2008 ACM SIGCOMM. + +\[Amazon 2014\] J. Hamilton, "AWS: Innovation at Scale, YouTube video, +https://www.youtube.com/watch?v=JIQETrFC_SQ + +\[Anderson 1995\] J. B. Andersen, T. S. Rappaport, S. Yoshida, +"Propagation Measurements and Models for Wireless Communications +Channels," IEEE Communications Magazine, (Jan. 1995), pp. 42--49. + +\[Alizadeh 2010\] M. Alizadeh, A. Greenberg, D. Maltz, J. Padhye, P. +Patel, B. Prabhakar, S. Sengupta, M. Sridharan. "Data center TCP +(DCTCP)," ACM SIGCOMM 2010 Conference, ACM, New York, NY, USA, +pp. 63--74. + +\[Allman 2011\] E. Allman, "The Robustness Principle Reconsidered: +Seeking a Middle Ground," Communications of the ACM, Vol. 54, No. 8 +(Aug. 2011), pp. 40--45. + +\[Appenzeller 2004\] G. Appenzeller, I. Keslassy, N. McKeown, "Sizing +Router Buffers," Proc. 2004 ACM SIGCOMM (Portland, OR, Aug. 2004). + +\[ASO-ICANN 2016\] The Address Supporting Organization homepage, +http://www.aso.icann.org + +\[AT&T 2013\] "AT&T Vision Alignment Challenge Technology Survey," AT&T +Domain 2.0 Vision White Paper, November 13, 2013. + + \[Atheros 2016\] Atheros Communications Inc., "Atheros AR5006 WLAN +Chipset Product Bulletins," +http://www.atheros.com/pt/AR5006Bulletins.htm + +\[Ayanoglu 1995\] E. Ayanoglu, S. Paul, T. F. La Porta, K. K. Sabnani, +R. D. Gitlin, "AIRMAIL: A Link-Layer Protocol for Wireless Networks," +ACM ACM/Baltzer Wireless Networks Journal, 1: 47--60, Feb. 1995. + +\[Bakre 1995\] A. Bakre, B. R. Badrinath, "I-TCP: Indirect TCP for +Mobile Hosts," Proc. 1995 Int. Conf. on Distributed Computing Systems +(ICDCS) (May 1995), pp. 136--143. + +\[Balakrishnan 1997\] H. Balakrishnan, V. Padmanabhan, S. Seshan, R. +Katz, "A Comparison of Mechanisms for Improving TCP Performance Over +Wireless Links," IEEE/ACM Transactions on Networking Vol. 5, No. 6 +(Dec. 1997). + +\[Balakrishnan 2003\] H. Balakrishnan, F. Kaashoek, D. Karger, R. +Morris, I. Stoica, "Looking Up Data in P2P Systems," Communications of +the ACM, Vol. 46, No. 2 (Feb. 2003), pp. 43--48. + +\[Baldauf 2007\] M. Baldauf, S. Dustdar, F. Rosenberg, "A Survey on +Context-Aware Systems," Int. J. Ad Hoc and Ubiquitous Computing, Vol. 2, +No. 4 (2007), pp. 263--277. + +\[Baran 1964\] P. Baran, "On Distributed Communication Networks," IEEE +Transactions on Communication Systems, Mar. 1964. Rand Corporation +Technical report with the same title (Memorandum RM-3420-PR, 1964). +http://www.rand.org/publications/RM/RM3420/ + +\[Bardwell 2004\] J. Bardwell, "You Believe You Understand What You +Think I Said . . . The Truth About 802.11 Signal and Noise Metrics: A +Discussion Clarifying OftenMisused 802.11 WLAN Terminologies," +http://www.connect802.com/download/techpubs/2004/you_believe_D100201.pdf + +\[Barford 2009\] P. Barford, N. Duffield, A. Ron, J. Sommers, "Network +Performance Anomaly Detection and Localization," Proc. 2009 IEEE INFOCOM +(Apr. 2009). + +\[Baronti 2007\] P. Baronti, P. Pillai, V. Chook, S. Chessa, A. Gotta, +Y. Hu, "Wireless Sensor Networks: A Survey on the State of the Art and +the 802.15.4 and ZigBee Standards," Computer Communications, Vol. 30, +No. 7 (2007), pp. 1655--1695. + +\[Baset 2006\] S. A. Basset and H. Schulzrinne, "An Analysis of the +Skype Peer-to-Peer Internet Telephony Protocol," Proc. 2006 IEEE INFOCOM +(Barcelona, Spain, Apr. 2006). + +\[BBC 2001\] BBC news online "A Small Slice of Design," Apr. 2001, +http://news.bbc.co.uk/2/hi/science/nature/1264205.stm + +\[Beheshti 2008\] N. Beheshti, Y. Ganjali, M. Ghobadi, N. McKeown, G. +Salmon, "Experimental Study of Router Buffer Sizing," Proc. ACM Internet +Measurement Conference (Oct. 2008, Vouliagmeni, Greece). + + \[Bender 2000\] P. Bender, P. Black, M. Grob, R. Padovani, N. +Sindhushayana, A. Viterbi, "CDMA/HDR: A Bandwidth-Efficient High-Speed +Wireless Data Service for Nomadic Users," IEEE Commun. Mag., Vol. 38, +No. 7 (July 2000), pp. 70--77. + +\[Berners-Lee 1989\] T. Berners-Lee, CERN, "Information Management: A +Proposal," Mar. 1989, May 1990. http://www.w3.org/History/1989/proposal +.html + +\[Berners-Lee 1994\] T. Berners-Lee, R. Cailliau, A. Luotonen, H. +Frystyk Nielsen, A. Secret, "The World-Wide Web," Communications of the +ACM, Vol. 37, No. 8 (Aug. 1994), pp. 76--82. + +\[Bertsekas 1991\] D. Bertsekas, R. Gallagher, Data Networks, 2nd Ed., +Prentice Hall, Englewood Cliffs, NJ, 1991. + +\[Biersack 1992\] E. W. Biersack, "Performance Evaluation of Forward +Error Correction in ATM Networks," Proc. 1999 ACM SIGCOMM (Baltimore, +MD, Aug. 1992), pp. 248--257. + +\[BIND 2016\] Internet Software Consortium page on BIND, +http://www.isc.org/bind.html + +\[Bisdikian 2001\] C. Bisdikian, "An Overview of the Bluetooth Wireless +Technology," IEEE Communications Magazine, No. 12 (Dec. 2001), +pp. 86--94. + +\[Bishop 2003\] M. Bishop, Computer Security: Art and Science, Boston: +Addison Wesley, Boston MA, 2003. + +\[Black 1995\] U. Black, ATM Volume I: Foundation for Broadband +Networks, Prentice Hall, 1995. + +\[Black 1997\] U. Black, ATM Volume II: Signaling in Broadband Networks, +Prentice Hall, 1997. + +\[Blumenthal 2001\] M. Blumenthal, D. Clark, "Rethinking the Design of +the Internet: The End-to-end Arguments vs. the Brave New World," ACM +Transactions on Internet Technology, Vol. 1, No. 1 (Aug. 2001), +pp. 70--109. + +\[Bochman 1984\] G. V. Bochmann, C. A. Sunshine, "Formal Methods in +Communication Protocol Design," IEEE Transactions on Communications, +Vol. 28, No. 4 (Apr. 1980) pp. 624--631. + +\[Bolot 1996\] J-C. Bolot, A. Vega-Garcia, "Control Mechanisms for +Packet Audio in the Internet," Proc. 1996 IEEE INFOCOM, pp. 232--239. + +\[Bosshart 2013\] P. Bosshart, G. Gibb, H. Kim, G. Varghese, N. McKeown, +M. Izzard, F. Mujica, M. Horowitz, "Forwarding Metamorphosis: Fast +Programmable Match-Action Processing in Hardware for SDN," ACM SIGCOMM +Comput. Commun. Rev. 43, 4 (Aug. 2013), 99--110. + + \[Bosshart 2014\] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, +J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese, D. +Walker, "P4: Programming Protocol-Independent Packet Processors," ACM +SIGCOMM Comput. Commun. Rev. 44, 3 (July 2014), pp. 87--95. + +\[Brakmo 1995\] L. Brakmo, L. Peterson, "TCP Vegas: End to End +Congestion Avoidance on a Global Internet," IEEE Journal of Selected +Areas in Communications, Vol. 13, No. 8 (Oct. 1995), pp. 1465--1480. + +\[Bryant 1988\] B. Bryant, "Designing an Authentication System: A +Dialogue in Four Scenes," http://web.mit.edu/kerberos/www/dialogue.html + +\[Bush 1945\] V. Bush, "As We May Think," The Atlantic Monthly, July +1945. http://www.theatlantic.com/unbound/flashbks/computer/bushf.htm + +\[Byers 1998\] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital +Fountain Approach to Reliable Distribution of Bulk Data," Proc. 1998 ACM +SIGCOMM (Vancouver, Canada, Aug. 1998), pp. 56--67. + +\[Caesar 2005a\] M. Caesar, D. Caldwell, N. Feamster, J. Rexford, A. +Shaikh, J. van der Merwe, "Design and implementation of a Routing +Control Platform," Proc. Networked Systems Design and Implementation +(May 2005). + +\[Caesar 2005b\] M. Caesar, J. Rexford, "BGP Routing Policies in ISP +Networks," IEEE Network Magazine, Vol. 19, No. 6 (Nov. 2005). + +\[Caldwell 2012\] C. Caldwell, "The Prime Pages," +http://www.utm.edu/research/primes/prove + +\[Cardwell 2000\] N. Cardwell, S. Savage, T. Anderson, "Modeling TCP +Latency," Proc. 2000 IEEE INFOCOM (Tel-Aviv, Israel, Mar. 2000). + +\[Casado 2007\] M. Casado, M. Freedman, J. Pettit, J. Luo, N. McKeown, +S. Shenker, "Ethane: Taking Control of the Enterprise," Proc. ACM +SIGCOMM '07, New York, pp. 1--12. See also IEEE/ACM Trans. Networking, +17, 4 (Aug. 2007), pp. 270--1283. + +\[Casado 2009\] M. Casado, M. Freedman, J. Pettit, J. Luo, N. Gude, N. +McKeown, S. Shenker, "Rethinking Enterprise Network Control," IEEE/ACM +Transactions on Networking (ToN), Vol. 17, No. 4 (Aug. 2009), +pp. 1270--1283. + +\[Casado 2014\] M. Casado, N. Foster, A. Guha, "Abstractions for +Software-Defined Networks," Communications of the ACM, Vol. 57 No. 10, +(Oct. 2014), pp. 86--95. + +\[Cerf 1974\] V. Cerf, R. Kahn, "A Protocol for Packet Network +Interconnection," IEEE Transactions on Communications Technology, Vol. +COM-22, No. 5, pp. 627--641. + +\[CERT 2001--09\] CERT, "Advisory 2001--09: Statistical Weaknesses in +TCP/IP Initial Sequence Numbers," +http://www.cert.org/advisories/CA-2001-09.html + + \[CERT 2003--04\] CERT, "CERT Advisory CA-2003-04 MS-SQL Server Worm," +http://www.cert.org/advisories/CA-2003-04.html + +\[CERT 2016\] CERT, http://www.cert.org + +\[CERT Filtering 2012\] CERT, "Packet Filtering for Firewall Systems," +http://www.cert.org/tech_tips/packet_filtering.html + +\[Cert SYN 1996\] CERT, "Advisory CA-96.21: TCP SYN Flooding and IP +Spoofing Attacks," http://www.cert.org/advisories/CA-1998-01.html + +\[Chandra 2007\] T. Chandra, R. Greisemer, J. Redstone, "Paxos Made +Live: an Engineering Perspective," Proc. of 2007 ACM Symposium on +Principles of Distributed Computing (PODC), pp. 398--407. + +\[Chao 2001\] H. J. Chao, C. Lam, E. Oki, Broadband Packet Switching +Technologies---A Practical Guide to ATM Switches and IP Routers, John +Wiley & Sons, 2001. + +\[Chao 2011\] C. Zhang, P. Dunghel, D. Wu, K. W. Ross, "Unraveling the +BitTorrent Ecosystem," IEEE Transactions on Parallel and Distributed +Systems, Vol. 22, No. 7 (July 2011). + +\[Chen 2000\] G. Chen, D. Kotz, "A Survey of Context-Aware Mobile +Computing Research," Technical Report TR2000-381, Dept. of Computer +Science, Dartmouth College, Nov. 2000. +http://www.cs.dartmouth.edu/reports/TR2000-381.pdf + +\[Chen 2006\] K.-T. Chen, C.-Y. Huang, P. Huang, C.-L. Lei, "Quantifying +Skype User Satisfaction," Proc. 2006 ACM SIGCOMM (Pisa, Italy, +Sept. 2006). + +\[Chen 2011\] Y. Chen, S. Jain, V. K. Adhikari, Z. Zhang, +"Characterizing Roles of Front-End Servers in End-to-End Performance of +Dynamic Content Distribution," Proc. 2011 ACM Internet Measurement +Conference (Berlin, Germany, Nov. 2011). + +\[Cheswick 2000\] B. Cheswick, H. Burch, S. Branigan, "Mapping and +Visualizing the Internet," Proc. 2000 Usenix Conference (San Diego, CA, +June 2000). + +\[Chiu 1989\] D. Chiu, R. Jain, "Analysis of the Increase and Decrease +Algorithms for Congestion Avoidance in Computer Networks," Computer +Networks and ISDN Systems, Vol. 17, No. 1, pp. 1--14. +http://www.cs.wustl.edu/\~jain/papers/cong_av.htm + +\[Christiansen 2001\] M. Christiansen, K. Jeffay, D. Ott, F. D. Smith, +"Tuning Red for Web Traffic," IEEE/ACM Transactions on Networking, Vol. +9, No. 3 (June 2001), pp. 249--264. + +\[Chuang 2005\] S. Chuang, S. Iyer, N. McKeown, "Practical Algorithms +for Performance Guarantees in Buffered Crossbars," Proc. 2005 IEEE +INFOCOM. + + \[Cisco 802.11ac 2014\] Cisco Systems, "802.11ac: The Fifth Generation +of Wi-Fi," Technical White Paper, Mar. 2014. + +\[Cisco 7600 2016\] Cisco Systems, "Cisco 7600 Series Solution and +Design Guide," +http://www.cisco.com/en/US/products/hw/routers/ps368/prod_technical\_ +reference09186a0080092246.html + +\[Cisco 8500 2012\] Cisco Systems Inc., "Catalyst 8500 Campus Switch +Router Architecture," +http://www.cisco.com/univercd/cc/td/doc/product/l3sw/8540/rel_12_0/w5_6f/softcnfg/1cfg8500.pdf + +\[Cisco 12000 2016\] Cisco Systems Inc., "Cisco XR 12000 Series and +Cisco 12000 Series Routers," +http://www.cisco.com/en/US/products/ps6342/index.html + +\[Cisco 2012\] Cisco 2012, Data Centers, http://www.cisco.com/go/dce + +\[Cisco 2015\] Cisco Visual Networking Index: Forecast and Methodology, +2014--2019, White Paper, 2015. + +\[Cisco 6500 2016\] Cisco Systems, "Cisco Catalyst 6500 Architecture +White Paper," http://www.cisco.com/c/en/us/products/collateral/switches/ +catalyst-6500-seriesswitches/prod_white_paper0900aecd80673385.html + +\[Cisco NAT 2016\] Cisco Systems Inc., "How NAT Works," +http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094831.shtml + +\[Cisco QoS 2016\] Cisco Systems Inc., "Advanced QoS Services for the +Intelligent Internet," +http://www.cisco.com/warp/public/cc/pd/iosw/ioft/ioqo/tech/qos_wp.htm + +\[Cisco Queue 2016\] Cisco Systems Inc., "Congestion Management +Overview," +http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfconmg.html + +\[Cisco SYN 2016\] Cisco Systems Inc., "Defining Strategies to Protect +Against TCP SYN Denial of Service Attacks," +http://www.cisco.com/en/US/tech/tk828/ +technologies_tech_note09186a00800f67d5.shtml + +\[Cisco TCAM 2014\] Cisco Systems Inc., "CAT 6500 and 7600 Series +Routers and Switches TCAM Allocation Adjustment Procedures," +http://www.cisco.com/c/en/us/ +support/docs/switches/catalyst-6500-series-switches/117712-problemsolution-cat6500-00.html + +\[Cisco VNI 2015\] Cisco Systems Inc., "Visual Networking Index," +http://www.cisco.com/web/solutions/sp/vni/vni_forecast_highlights/index.html + +\[Clark 1988\] D. Clark, "The Design Philosophy of the DARPA Internet +Protocols," Proc. 1988 ACM SIGCOMM (Stanford, CA, Aug. 1988). + + \[Cohen 1977\] D. Cohen, "Issues in Transnet Packetized Voice +Communication," Proc. Fifth Data Communications Symposium (Snowbird, UT, +Sept. 1977), pp. 6--13. + +\[Cookie Central 2016\] Cookie Central homepage, +http://www.cookiecentral.com/ n_cookie_faq.htm + +\[Cormen 2001\] T. H. Cormen, Introduction to Algorithms, 2nd Ed., MIT +Press, Cambridge, MA, 2001. + +\[Crow 1997\] B. Crow, I. Widjaja, J. Kim, P. Sakai, "IEEE 802.11 +Wireless Local Area Networks," IEEE Communications Magazine +(Sept. 1997), pp. 116--126. + +\[Cusumano 1998\] M. A. Cusumano, D. B. Yoffie, Competing on Internet +Time: Lessons from Netscape and Its Battle with Microsoft, Free Press, +New York, NY, 1998. + +\[Czyz 2014\] J. Czyz, M. Allman, J. Zhang, S. Iekel-Johnson, E. +Osterweil, M. Bailey, "Measuring IPv6 Adoption," Proc. ACM SIGCOMM 2014, +ACM, New York, NY, USA, pp. 87--98. + +\[Dahlman 1998\] E. Dahlman, B. Gudmundson, M. Nilsson, J. Sköld, +"UMTS/IMT-2000 Based on Wideband CDMA," IEEE Communications Magazine +(Sept. 1998), pp. 70--80. + +\[Daigle 1991\] J. N. Daigle, Queuing Theory for Telecommunications, +Addison-Wesley, Reading, MA, 1991. + +\[DAM 2016\] Digital Attack Map, http://www.digitalattackmap.com + +\[Davie 2000\] B. Davie and Y. Rekhter, MPLS: Technology and +Applications, Morgan Kaufmann Series in Networking, 2000. + +\[Davies 2005\] G. Davies, F. Kelly, "Network Dimensioning, Service +Costing, and Pricing in a Packet-Switched Environment," +Telecommunications Policy, Vol. 28, No. 4, pp. 391--412. + +\[DEC 1990\] Digital Equipment Corporation, "In Memoriam: J. C. R. +Licklider 1915--1990," SRC Research Report 61, Aug. 1990. +http://www.memex.org/ licklider.pdf + +\[DeClercq 2002\] J. DeClercq, O. Paridaens, "Scalability Implications +of Virtual Private Networks," IEEE Communications Magazine, Vol. 40, +No. 5 (May 2002), pp. 151--157. + +\[Demers 1990\] A. Demers, S. Keshav, S. Shenker, "Analysis and +Simulation of a Fair Queuing Algorithm," Internetworking: Research and +Experience, Vol. 1, No. 1 (1990), pp. 3--26. + + \[dhc 2016\] IETF Dynamic Host Configuration working group homepage, +http://www.ietf.org/html.charters/dhc-charter.html + +\[Dhungel 2012\] P. Dhungel, K. W. Ross, M. Steiner., Y. Tian, X. Hei, +"Xunlei: Peer-Assisted Download Acceleration on a Massive Scale," +Passive and Active Measurement Conference (PAM) 2012, Vienna, 2012. + +\[Diffie 1976\] W. Diffie, M. E. Hellman, "New Directions in +Cryptography," IEEE Transactions on Information Theory, Vol IT-22 +(1976), pp. 644--654. + +\[Diggavi 2004\] S. N. Diggavi, N. Al-Dhahir, A. Stamoulis, R. +Calderbank, "Great Expectations: The Value of Spatial Diversity in +Wireless Networks," Proceedings of the IEEE, Vol. 92, No. 2 (Feb. 2004). + +\[Dilley 2002\] J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, +B. Weihl, "Globally Distributed Content Delivert," IEEE Internet +Computing (Sept.--Oct. 2002). + +\[Diot 2000\] C. Diot, B. N. Levine, B. Lyles, H. Kassem, D. +Balensiefen, "Deployment Issues for the IP Multicast Service and +Architecture," IEEE Network, Vol. 14, No. 1 (Jan./Feb. 2000) pp. 78--88. + +\[Dischinger 2007\] M. Dischinger, A. Haeberlen, K. Gummadi, S. Saroiu, +"Characterizing residential broadband networks," Proc. 2007 ACM Internet +Measurement Conference, pp. 24--26. + +\[Dmitiropoulos 2007\] X. Dmitiropoulos, D. Krioukov, M. Fomenkov, B. +Huffaker, Y. Hyun, K. C. Claffy, G. Riley, "AS Relationships: Inference +and Validation," ACM Computer Communication Review (Jan. 2007). + +\[DOCSIS 2011\] Data-Over-Cable Service Interface Specifications, DOCSIS +3.0: MAC and Upper Layer Protocols Interface Specification, +CM-SP-MULPIv3.0-I16-110623, 2011. + +\[Dodge 2016\] M. Dodge, "An Atlas of Cyberspaces," +http://www.cybergeography.org/atlas/isp_maps.html + +\[Donahoo 2001\] M. Donahoo, K. Calvert, TCP/IP Sockets in C: Practical +Guide for Programmers, Morgan Kaufman, 2001. + +\[DSL 2016\] DSL Forum homepage, http://www.dslforum.org/ + +\[Dhunghel 2008\] P. Dhungel, D. Wu, B. Schonhorst, K.W. Ross, "A +Measurement Study of Attacks on BitTorrent Leechers," 7th International +Workshop on Peer-to-Peer Systems (IPTPS 2008) (Tampa Bay, FL, +Feb. 2008). + +\[Droms 2002\] R. Droms, T. Lemon, The DHCP Handbook (2nd Edition), SAMS +Publishing, 2002. + + \[Edney 2003\] J. Edney and W. A. Arbaugh, Real 802.11 Security: Wi-Fi +Protected Access and 802.11i, Addison-Wesley Professional, 2003. + +\[Edwards 2011\] W. K. Edwards, R. Grinter, R. Mahajan, D. Wetherall, +"Advancing the State of Home Networking," Communications of the ACM, +Vol. 54, No. 6 (June 2011), pp. 62--71. + +\[Ellis 1987\] H. Ellis, "The Story of Non-Secret Encryption," +http://jya.com/ellisdoc.htm + +\[Erickson 2013\] D. Erickson, " The Beacon Openflow Controller," 2nd +ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking +(HotSDN '13). ACM, New York, NY, USA, pp. 13--18. + +\[Ericsson 2012\] Ericsson, "The Evolution of Edge," +http://www.ericsson.com/technology/whitepapers/broadband/evolution_of_EDGE.shtml + +\[Facebook 2014\] A. Andreyev, "Introducing Data Center Fabric, the +Next-Generation Facebook Data Center Network," +https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network + +\[Faloutsos 1999\] C. Faloutsos, M. Faloutsos, P. Faloutsos, "What Does +the Internet Look Like? Empirical Laws of the Internet Topology," Proc. +1999 ACM SIGCOMM (Boston, MA, Aug. 1999). + +\[Farrington 2010\] N. Farrington, G. Porter, S. Radhakrishnan, H. +Bazzaz, V. Subramanya, Y. Fainman, G. Papen, A. Vahdat, "Helios: A +Hybrid Electrical/Optical Switch Architecture for Modular Data Centers," +Proc. 2010 ACM SIGCOMM. + +\[Feamster 2004\] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, +K. van der Merwe, "The Case for Separating Routing from Routers," ACM +SIGCOMM Workshop on Future Directions in Network Architecture, +Sept. 2004. + +\[Feamster 2004\] N. Feamster, J. Winick, J. Rexford, "A Model for BGP +Routing for Network Engineering," Proc. 2004 ACM SIGMETRICS (New York, +NY, June 2004). + +\[Feamster 2005\] N. Feamster, H. Balakrishnan, "Detecting BGP +Configuration Faults with Static Analysis," NSDI (May 2005). + +\[Feamster 2013\] N. Feamster, J. Rexford, E. Zegura, "The Road to SDN," +ACM Queue, Volume 11, Issue 12, (Dec. 2013). + +\[Feldmeier 1995\] D. Feldmeier, "Fast Software Implementation of Error +Detection Codes," IEEE/ACM Transactions on Networking, Vol. 3, No. 6 +(Dec. 1995), pp. 640--652. + + \[Ferguson 2013\] A. Ferguson, A. Guha, C. Liang, R. Fonseca, S. +Krishnamurthi, "Participatory Networking: An API for Application Control +of SDNs," Proceedings ACM SIGCOMM 2013, pp. 327--338. + +\[Fielding 2000\] R. Fielding, "Architectural Styles and the Design of +Network-based Software Architectures," 2000. PhD Thesis, UC Irvine, +2000. + +\[FIPS 1995\] Federal Information Processing Standard, "Secure Hash +Standard," FIPS Publication 180-1. +http://www.itl.nist.gov/fipspubs/fip180-1.htm + +\[Floyd 1999\] S. Floyd, K. Fall, "Promoting the Use of End-to-End +Congestion Control in the Internet," IEEE/ACM Transactions on +Networking, Vol. 6, No. 5 (Oct. 1998), pp. 458--472. + +\[Floyd 2000\] S. Floyd, M. Handley, J. Padhye, J. Widmer, +"Equation-Based Congestion Control for Unicast Applications," Proc. 2000 +ACM SIGCOMM (Stockholm, Sweden, Aug. 2000). + +\[Floyd 2001\] S. Floyd, "A Report on Some Recent Developments in TCP +Congestion Control," IEEE Communications Magazine (Apr. 2001). + +\[Floyd 2016\] S. Floyd, "References on RED (Random Early Detection) +Queue Management," http://www.icir.org/floyd/red.html + +\[Floyd Synchronization 1994\] S. Floyd, V. Jacobson, "Synchronization +of Periodic Routing Messages," IEEE/ACM Transactions on Networking, Vol. +2, No. 2 (Apr. 1997) pp. 122--136. + +\[Floyd TCP 1994\] S. Floyd, "TCP and Explicit Congestion Notification," +ACM SIGCOMM Computer Communications Review, Vol. 24, No. 5 (Oct. 1994), +pp. 10--23. + +\[Fluhrer 2001\] S. Fluhrer, I. Mantin, A. Shamir, "Weaknesses in the +Key Scheduling Algorithm of RC4," Eighth Annual Workshop on Selected +Areas in Cryptography (Toronto, Canada, Aug. 2002). + +\[Fortz 2000\] B. Fortz, M. Thorup, "Internet Traffic Engineering by +Optimizing OSPF Weights," Proc. 2000 IEEE INFOCOM (Tel Aviv, Israel, +Apr. 2000). + +\[Fortz 2002\] B. Fortz, J. Rexford, M. Thorup, "Traffic Engineering +with Traditional IP Routing Protocols," IEEE Communication Magazine +(Oct. 2002). + +\[Fraleigh 2003\] C. Fraleigh, F. Tobagi, C. Diot, "Provisioning IP +Backbone Networks to Support Latency Sensitive Traffic," Proc. 2003 IEEE +INFOCOM (San Francisco, CA, Mar. 2003). + +\[Frost 1994\] J. Frost, "BSD Sockets: A Quick and Dirty Primer," +http://world.std .com/\~jimf/papers/sockets/sockets.html + + \[FTC 2015\] Internet of Things: Privacy and Security in a Connected +World, Federal Trade Commission, 2015, +https://www.ftc.gov/system/files/documents/reports/ +federal-trade-commission-staff-report-november-2013-workshop-entitled-internet-things-privacy/150127iotrpt.pdf + +\[FTTH 2016\] Fiber to the Home Council, http://www.ftthcouncil.org/ + +\[Gao 2001\] L. Gao, J. Rexford, "Stable Internet Routing Without Global +Coordination," IEEE/ACM Transactions on Networking, Vol. 9, No. 6 +(Dec. 2001), pp. 681--692. + +\[Gartner 2014\] Gartner report on Internet of Things, +http://www.gartner.com/ technology/research/internet-of-things + +\[Gauthier 1999\] L. Gauthier, C. Diot, and J. Kurose, "End-to-End +Transmission Control Mechanisms for Multiparty Interactive Applications +on the Internet," Proc. 1999 IEEE INFOCOM (New York, NY, Apr. 1999). + +\[Gember-Jacobson 2014\] A. Gember-Jacobson, R. Viswanathan, C. Prakash, +R. Grandl, J. Khalid, S. Das, A. Akella, "OpenNF: Enabling Innovation in +Network Function Control," Proc. ACM SIGCOMM 2014, pp. 163--174. + +\[Goodman 1997\] David J. Goodman, Wireless Personal Communications +Systems, Prentice-Hall, 1997. + +\[Google IPv6 2015\] Google Inc. "IPv6 Statistics," +https://www.google.com/intl/en/ipv6/statistics.html + +\[Google Locations 2016\] Google data centers. +http://www.google.com/corporate/datacenter/locations.html + +\[Goralski 1999\] W. Goralski, Frame Relay for High-Speed Networks, John +Wiley, New York, 1999. + +\[Greenberg 2009a\] A. Greenberg, J. Hamilton, D. Maltz, P. Patel, "The +Cost of a Cloud: Research Problems in Data Center Networks," ACM +Computer Communications Review (Jan. 2009). + +\[Greenberg 2009b\] A. Greenberg, N. Jain, S. Kandula, C. Kim, P. +Lahiri, D. Maltz, P. Patel, S. Sengupta, "VL2: A Scalable and Flexible +Data Center Network," Proc. 2009 ACM SIGCOMM. + +\[Greenberg 2011\] A. Greenberg, J. Hamilton, N. Jain, S. Kandula, C. +Kim, P. Lahiri, D. Maltz, P. Patel, S. Sengupta, "VL2: A Scalable and +Flexible Data Center Network," Communications of the ACM, Vol. 54, No. 3 +(Mar. 2011), pp. 95--104. + +\[Greenberg 2015\] A. Greenberg, "SDN for the Cloud," Sigcomm 2015 +Keynote Address, +http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/keynote.pdf + + \[Griffin 2012\] T. Griffin, "Interdomain Routing Links," +http://www.cl.cam.ac.uk/\~tgg22/interdomain/ + +\[Gude 2008\] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. +McKeown, and S. Shenker, "NOX: Towards an Operating System for +Networks," ACM SIGCOMM Computer Communication Review, July 2008. + +\[Guha 2006\] S. Guha, N. Daswani, R. Jain, "An Experimental Study of +the Skype Peer-to-Peer VoIP System," Proc. Fifth Int. Workshop on P2P +Systems (Santa Barbara, CA, 2006). + +\[Guo 2005\] L. Guo, S. Chen, Z. Xiao, E. Tan, X. Ding, X. Zhang, +"Measurement, Analysis, and Modeling of BitTorrent-Like Systems," Proc. +2005 ACM Internet Measurement Conference. + +\[Guo 2009\] C. Guo, G. Lu, D. Li, H. Wu, X. Zhang, Y. Shi, C. Tian, Y. +Zhang, S. Lu, "BCube: A High Performance, Server-centric Network +Architecture for Modular Data Centers," Proc. 2009 ACM SIGCOMM. + +\[Gupta 2001\] P. Gupta, N. McKeown, "Algorithms for Packet +Classification," IEEE Network Magazine, Vol. 15, No. 2 (Mar./Apr. 2001), +pp. 24--32. + +\[Gupta 2014\] A. Gupta, L. Vanbever, M. Shahbaz, S. Donovan, B. +Schlinker, N. Feamster, J. Rexford, S. Shenker, R. Clark, E. +Katz-Bassett, "SDX: A Software Defined Internet Exchange, " Proc. ACM +SIGCOMM 2014 (Aug. 2014), pp. 551--562. + +\[Ha 2008\] S. Ha, I. Rhee, L. Xu, "CUBIC: A New TCP-Friendly High-Speed +TCP Variant," ACM SIGOPS Operating System Review, 2008. + +\[Halabi 2000\] S. Halabi, Internet Routing Architectures, 2nd Ed., +Cisco Press, 2000. + +\[Hanabali 2005\] A. A. Hanbali, E. Altman, P. Nain, "A Survey of TCP +over Ad Hoc Networks," IEEE Commun. Surveys and Tutorials, Vol. 7, No. 3 +(2005), pp. 22--36. + +\[Hei 2007\] X. Hei, C. Liang, J. Liang, Y. Liu, K. W. Ross, "A +Measurement Study of a Large-scale P2P IPTV System," IEEE Trans. on +Multimedia (Dec. 2007). + +\[Heidemann 1997\] J. Heidemann, K. Obraczka, J. Touch, "Modeling the +Performance of HTTP over Several Transport Protocols," IEEE/ACM +Transactions on Networking, Vol. 5, No. 5 (Oct. 1997), pp. 616--630. + +\[Held 2001\] G. Held, Data Over Wireless Networks: Bluetooth, WAP, and +Wireless LANs, McGraw-Hill, 2001. + +\[Holland 2001\] G. Holland, N. Vaidya, V. Bahl, "A Rate-Adaptive MAC +Protocol for Multi-Hop Wireless Networks," Proc. 2001 ACM Int. +Conference of Mobile Computing and + + Networking (Mobicom01) (Rome, Italy, July 2001). + +\[Hollot 2002\] C.V. Hollot, V. Misra, D. Towsley, W. Gong, "Analysis +and Design of Controllers for AQM Routers Supporting TCP Flows," IEEE +Transactions on Automatic Control, Vol. 47, No. 6 (June 2002), +pp. 945--959. + +\[Hong 2013\] C. Hong, S, Kandula, R. Mahajan, M.Zhang, V. Gill, M. +Nanduri, R. Wattenhofer, "Achieving High Utilization with +Software-driven WAN," ACM SIGCOMM Conference (Aug. 2013), pp.15--26. + +\[Huang 2002\] C. Haung, V. Sharma, K. Owens, V. Makam, "Building +Reliable MPLS Networks Using a Path Protection Mechanism," IEEE +Communications Magazine, Vol. 40, No. 3 (Mar. 2002), pp. 156--162. + +\[Huang 2005\] Y. Huang, R. Guerin, "Does Over-Provisioning Become More +or Less Efficient as Networks Grow Larger?," Proc. IEEE Int. Conf. +Network Protocols (ICNP) (Boston MA, Nov. 2005). + +\[Huang 2008\] C. Huang, J. Li, A. Wang, K. W. Ross, "Understanding +Hybrid CDN-P2P: Why Limelight Needs Its Own Red Swoosh," Proc. 2008 +NOSSDAV, Braunschweig, Germany. + +\[Huitema 1998\] C. Huitema, IPv6: The New Internet Protocol, 2nd Ed., +Prentice Hall, Englewood Cliffs, NJ, 1998. + +\[Huston 1999a\] G. Huston, "Interconnection, Peering, and +Settlements---Part I," The Internet Protocol Journal, Vol. 2, No. 1 +(Mar. 1999). + +\[Huston 2004\] G. Huston, "NAT Anatomy: A Look Inside Network Address +Translators," The Internet Protocol Journal, Vol. 7, No. 3 (Sept. 2004). + +\[Huston 2008a\] G. Huston, "Confronting IPv4 Address Exhaustion," +http://www.potaroo.net/ispcol/2008-10/v4depletion.html + +\[Huston 2008b\] G. Huston, G. Michaelson, "IPv6 Deployment: Just where +are we?" http://www.potaroo.net/ispcol/2008-04/ipv6.html + +\[Huston 2011a\] G. Huston, "A Rough Guide to Address Exhaustion," The +Internet Protocol Journal, Vol. 14, No. 1 (Mar. 2011). + +\[Huston 2011b\] G. Huston, "Transitioning Protocols," The Internet +Protocol Journal, Vol. 14, No. 1 (Mar. 2011). + +\[IAB 2016\] Internet Architecture Board homepage, http://www.iab.org/ + + \[IANA Protocol Numbers 2016\] Internet Assigned Numbers Authority, +Protocol Numbers, +http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml + +\[IBM 1997\] IBM Corp., IBM Inside APPN - The Essential Guide to the +Next-Generation SNA, SG24-3669-03, June 1997. + +\[ICANN 2016\] The Internet Corporation for Assigned Names and Numbers +homepage, http://www.icann.org + +\[IEEE 802 2016\] IEEE 802 LAN/MAN Standards Committee homepage, +http://www.ieee802.org/ + +\[IEEE 802.11 1999\] IEEE 802.11, "1999 Edition (ISO/IEC 8802-11: 1999) +IEEE Standards for Information Technology---Telecommunications and +Information Exchange Between Systems---Local and Metropolitan Area +Network---Specific Requirements---Part 11: Wireless LAN Medium Access +Control (MAC) and Physical Layer (PHY) Specification," +http://standards.ieee.org/getieee802/download/802.11-1999.pdf + +\[IEEE 802.11ac 2013\] IEEE, "802.11ac-2013---IEEE Standard for +Information technology---Telecommunications and Information Exchange +Between Systems---Local and Metropolitan Area Networks---Specific +Requirements---Part 11: Wireless LAN Medium Access Control (MAC) and +Physical Layer (PHY) Specifications---Amendment 4: Enhancements for Very +High Throughput for Operation in Bands Below 6 GHz." + +\[IEEE 802.11n 2012\] IEEE, "IEEE P802.11---Task Group N---Meeting +Update: Status of 802.11n," +http://grouper.ieee.org/groups/802/11/Reports/tgn_update .htm + +\[IEEE 802.15 2012\] IEEE 802.15 Working Group for WPAN homepage, +http://grouper.ieee.org/groups/802/15/. + +\[IEEE 802.15.4 2012\] IEEE 802.15 WPAN Task Group 4, +http://www.ieee802.org/15/pub/TG4.html + +\[IEEE 802.16d 2004\] IEEE, "IEEE Standard for Local and Metropolitan +Area Networks, Part 16: Air Interface for Fixed Broadband Wireless +Access Systems," http:// +standards.ieee.org/getieee802/download/802.16-2004.pdf + +\[IEEE 802.16e 2005\] IEEE, "IEEE Standard for Local and Metropolitan +Area Networks, Part 16: Air Interface for Fixed and Mobile Broadband +Wireless Access Systems, Amendment 2: Physical and Medium Access Control +Layers for Combined Fixed and Mobile Operation in Licensed Bands and +Corrigendum 1," http:// +standards.ieee.org/getieee802/download/802.16e-2005.pdf + +\[IEEE 802.1q 2005\] IEEE, "IEEE Standard for Local and Metropolitan +Area Networks: Virtual Bridged Local Area Networks," +http://standards.ieee.org/ getieee802/ download/802.1Q-2005.pdf + +\[IEEE 802.1X\] IEEE Std 802.1X-2001 Port-Based Network Access Control, +http://standards.ieee.org/reading/ieee/std_public/description/lanman/ +802.1x-2001_desc.html + + \[IEEE 802.3 2012\] IEEE, "IEEE 802.3 CSMA/CD (Ethernet)," +http://grouper.ieee.org/groups/802/3/ + +\[IEEE 802.5 2012\] IEEE, IEEE 802.5 homepage, http://www.ieee802.org/5/ +www8025org/ + +\[IETF 2016\] Internet Engineering Task Force homepage, +http://www.ietf.org + +\[Ihm 2011\] S. Ihm, V. S. Pai, "Towards Understanding Modern Web +Traffic," Proc. 2011 ACM Internet Measurement Conference (Berlin). + +\[IMAP 2012\] The IMAP Connection, http://www.imap.org/ + +\[Intel 2016\] Intel Corp., "Intel 710 Ethernet Adapter," +http://www.intel.com/ +content/www/us/en/ethernet-products/converged-network-adapters/ethernet-xl710 +.html + +\[Internet2 Multicast 2012\] Internet2 Multicast Working Group homepage, +http://www.internet2.edu/multicast/ + +\[ISC 2016\] Internet Systems Consortium homepage, http://www.isc.org + +\[ISI 1979\] Information Sciences Institute, "DoD Standard Internet +Protocol," Internet Engineering Note 123 (Dec. 1979), +http://www.isi.edu/in-notes/ien/ ien123.txt + +\[ISO 2016\] International Organization for Standardization homepage, +International Organization for Standardization, http://www.iso.org/ + +\[ISO X.680 2002\] International Organization for Standardization, +"X.680: ITU-T Recommendation X.680 (2002) Information +Technology---Abstract Syntax Notation One (ASN.1): Specification of +Basic Notation," +http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf + +\[ITU 1999\] Asymmetric Digital Subscriber Line (ADSL) Transceivers. +ITU-T G.992.1, 1999. + +\[ITU 2003\] Asymmetric Digital Subscriber Line (ADSL) +Transceivers---Extended Bandwidth ADSL2 (ADSL2Plus). ITU-T G.992.5, +2003. + +\[ITU 2005a\] International Telecommunication Union, "ITU-T X.509, The +Directory: Public-key and attribute certificate frameworks" (Aug. 2005). + +\[ITU 2006\] ITU, "G.993.1: Very High Speed Digital Subscriber Line +Transceivers (VDSL)," https://www.itu.int/rec/T-REC-G.993.1-200406-I/en, +2006. + +\[ITU 2015\] "Measuring the Information Society Report," 2015, +http://www.itu.int/en/ITU-D/Statistics/Pages/publications/mis2015.aspx + + \[ITU 2012\] The ITU homepage, http://www.itu.int/ + +\[ITU-T Q.2931 1995\] International Telecommunication Union, +"Recommendation Q.2931 (02/95)---Broadband Integrated Services Digital +Network (B-ISDN)--- Digital Subscriber Signalling System No. 2 (DSS +2)---User-Network Interface (UNI)---Layer 3 Specification for Basic +Call/Connection Control." + +\[IXP List 2016\] List of IXPs, Wikipedia, +https://en.wikipedia.org/wiki/List_of\_ Internet_exchange_points + +\[Iyengar 2015\] J. Iyengar, I. Swett, "QUIC: A UDP-Based Secure and +Reliable Transport for HTTP/2," Internet Draft +draft-tsvwg-quic-protocol-00, June 2015. + +\[Iyer 2008\] S. Iyer, R. R. Kompella, N. McKeown, "Designing Packet +Buffers for Router Line Cards," IEEE Transactions on Networking, Vol. +16, No. 3 (June 2008), pp. 705--717. + +\[Jacobson 1988\] V. Jacobson, "Congestion Avoidance and Control," Proc. +1988 ACM SIGCOMM (Stanford, CA, Aug. 1988), pp. 314--329. + +\[Jain 1986\] R. Jain, "A Timeout-Based Congestion Control Scheme for +Window Flow-Controlled Networks," IEEE Journal on Selected Areas in +Communications SAC-4, 7 (Oct. 1986). + +\[Jain 1989\] R. Jain, "A Delay-Based Approach for Congestion Avoidance +in Interconnected Heterogeneous Computer Networks," ACM SIGCOMM Computer +Communications Review, Vol. 19, No. 5 (1989), pp. 56--71. + +\[Jain 1994\] R. Jain, FDDI Handbook: High-Speed Networking Using Fiber +and Other Media, Addison-Wesley, Reading, MA, 1994. + +\[Jain 1996\] R. Jain. S. Kalyanaraman, S. Fahmy, R. Goyal, S. Kim, +"Tutorial Paper on ABR Source Behavior," ATM Forum/96-1270, Oct. 1996. +http://www.cse.wustl.edu/ \~jain/atmf/ftp/atm96-1270.pdf + +\[Jain 2013\] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. +Singh, S.Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. Hölzle, S. +Stuart, A, Vahdat, "B4: Experience with a Globally Deployed Software +Defined Wan," ACM SIGCOMM 2013, pp. 3--14. + +\[Jaiswal 2003\] S. Jaiswal, G. Iannaccone, C. Diot, J. Kurose, D. +Towsley, "Measurement and Classification of Out-of-Sequence Packets in a +Tier-1 IP backbone," Proc. 2003 IEEE INFOCOM. + +\[Ji 2003\] P. Ji, Z. Ge, J. Kurose, D. Towsley, "A Comparison of +Hard-State and Soft-State Signaling Protocols," Proc. 2003 ACM SIGCOMM +(Karlsruhe, Germany, Aug. 2003). + + \[Jimenez 1997\] D. Jimenez, "Outside Hackers Infiltrate MIT Network, +Compromise Security," The Tech, Vol. 117, No 49 (Oct. 1997), p. 1, +http://www-tech.mit.edu/V117/ N49/hackers.49n.html + +\[Jin 2004\] C. Jin, D. X. We, S. Low, "FAST TCP: Motivation, +Architecture, Algorithms, Performance," Proc. 2004 IEEE INFOCOM (Hong +Kong, Mar. 2004). + +\[Juniper Contrail 2016\] Juniper Networks, "Contrail," +http://www.juniper.net/us/en/products-services/sdn/contrail/ + +\[Juniper MX2020 2015\] Juniper Networks, "MX2020 and MX2010 3D +Universal Edge Routers," +www.juniper.net/us/en/local/pdf/.../1000417-en.pdf + +\[Kaaranen 2001\] H. Kaaranen, S. Naghian, L. Laitinen, A. Ahtiainen, V. +Niemi, Networks: Architecture, Mobility and Services, New York: John +Wiley & Sons, 2001. + +\[Kahn 1967\] D. Kahn, The Codebreakers: The Story of Secret Writing, +The Macmillan Company, 1967. + +\[Kahn 1978\] R. E. Kahn, S. Gronemeyer, J. Burchfiel, R. Kunzelman, +"Advances in Packet Radio Technology," Proc. 1978 IEEE INFOCOM, 66, 11 +(Nov. 1978). + +\[Kamerman 1997\] A. Kamerman, L. Monteban, "WaveLAN-II: A High-- +Performance Wireless LAN for the Unlicensed Band," Bell Labs Technical +Journal (Summer 1997), pp. 118--133. + +\[Kar 2000\] K. Kar, M. Kodialam, T. V. Lakshman, "Minimum Interference +Routing of Bandwidth Guaranteed Tunnels with MPLS Traffic Engineering +Applications," IEEE J. Selected Areas in Communications (Dec. 2000). + +\[Karn 1987\] P. Karn, C. Partridge, "Improving Round-Trip Time +Estimates in Reliable Transport Protocols," Proc. 1987 ACM SIGCOMM. + +\[Karol 1987\] M. Karol, M. Hluchyj, A. Morgan, "Input Versus Output +Queuing on a Space-Division Packet Switch," IEEE Transactions on +Communications, Vol. 35, No. 12 (Dec.1987), pp. 1347--1356. + +\[Kaufman 1995\] C. Kaufman, R. Perlman, M. Speciner, Network Security, +Private Communication in a Public World, Prentice Hall, Englewood +Cliffs, NJ, 1995. + +\[Kelly 1998\] F. P. Kelly, A. Maulloo, D. Tan, "Rate Control for +Communication Networks: Shadow Prices, Proportional Fairness and +Stability," J. Operations Res. Soc., Vol. 49, No. 3 (Mar. 1998), +pp. 237--252. + +\[Kelly 2003\] T. Kelly, "Scalable TCP: Improving Performance in High +Speed Wide Area Networks," ACM SIGCOMM Computer Communications Review, +Volume 33, No. 2 (Apr. 2003), pp.83--91. + + \[Kilkki 1999\] K. Kilkki, Differentiated Services for the Internet, +Macmillan Technical Publishing, Indianapolis, IN, 1999. + +\[Kim 2005\] H. Kim, S. Rixner, V. Pai, "Network Interface Data +Caching," IEEE Transactions on Computers, Vol. 54, No. 11 (Nov. 2005), +pp. 1394--1408. + +\[Kim 2008\] C. Kim, M. Caesar, J. Rexford, "Floodless in SEATTLE: A +Scalable Ethernet Architecture for Large Enterprises," Proc. 2008 ACM +SIGCOMM (Seattle, WA, Aug. 2008). + +\[Kleinrock 1961\] L. Kleinrock, "Information Flow in Large +Communication Networks," RLE Quarterly Progress Report, July 1961. + +\[Kleinrock 1964\] L. Kleinrock, 1964 Communication Nets: Stochastic +Message Flow and Delay, McGraw-Hill, New York, NY, 1964. + +\[Kleinrock 1975\] L. Kleinrock, Queuing Systems, Vol. 1, John Wiley, +New York, 1975. + +\[Kleinrock 1975b\] L. Kleinrock, F. A. Tobagi, "Packet Switching in +Radio Channels: Part I---Carrier Sense Multiple-Access Modes and Their +Throughput-Delay Characteristics," IEEE Transactions on Communications, +Vol. 23, No. 12 (Dec. 1975), pp. 1400--1416. + +\[Kleinrock 1976\] L. Kleinrock, Queuing Systems, Vol. 2, John Wiley, +New York, 1976. + +\[Kleinrock 2004\] L. Kleinrock, "The Birth of the Internet," +http://www.lk.cs.ucla.edu/LK/Inet/birth.html + +\[Kohler 2006\] E. Kohler, M. Handley, S. Floyd, "DDCP: Designing DCCP: +Congestion Control Without Reliability," Proc. 2006 ACM SIGCOMM (Pisa, +Italy, Sept. 2006). + +\[Kolding 2003\] T. Kolding, K. Pedersen, J. Wigard, F. Frederiksen, P. +Mogensen, "High Speed Downlink Packet Access: WCDMA Evolution," IEEE +Vehicular Technology Society News (Feb. 2003), pp. 4--10. + +\[Koponen 2010\] T. Koponen, M. Casado, N. Gude, J. Stribling, L. +Poutievski, M. Zhu, R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, S. +Shenker, "Onix: A Distributed Control Platform for Large-Scale +Production Networks," 9th USENIX conference on Operating systems design +and implementation (OSDI'10), pp. 1--6. + +\[Koponen 2011\] T. Koponen, S. Shenker, H. Balakrishnan, N. Feamster, +I. Ganichev, A. Ghodsi, P. B. Godfrey, N. McKeown, G. Parulkar, B. +Raghavan, J. Rexford, S. Arianfar, D. Kuptsov, "Architecting for +Innovation," ACM Computer Communications Review, 2011. + +\[Korhonen 2003\] J. Korhonen, Introduction to 3G Mobile Communications, +2nd ed., Artech House, 2003. + + \[Koziol 2003\] J. Koziol, Intrusion Detection with Snort, Sams +Publishing, 2003. + +\[Kreutz 2015\] D. Kreutz, F.M.V. Ramos, P. Esteves Verissimo, C. +Rothenberg, S. Azodolmolky, S. Uhlig, "Software-Defined Networking: A +Comprehensive Survey," Proceedings of the IEEE, Vol. 103, No. 1 +(Jan. 2015), pp. 14-76. This paper is also being updated at +https://github.com/SDN-Survey/latex/wiki + +\[Krishnamurthy 2001\] B. Krishnamurthy, J. Rexford, Web Protocols and +Practice: HTTP/ 1.1, Networking Protocols, and Traffic Measurement, +Addison-Wesley, Boston, MA, 2001. + +\[Kulkarni 2005\] S. Kulkarni, C. Rosenberg, "Opportunistic Scheduling: +Generalizations to Include Multiple Constraints, Multiple Interfaces, +and Short Term Fairness," Wireless Networks, 11 (2005), 557--569. + +\[Kumar 2006\] R. Kumar, K.W. Ross, "Optimal Peer-Assisted File +Distribution: Single and Multi-Class Problems," IEEE Workshop on Hot +Topics in Web Systems and Technologies (Boston, MA, 2006). + +\[Labovitz 1997\] C. Labovitz, G. R. Malan, F. Jahanian, "Internet +Routing Instability," Proc. 1997 ACM SIGCOMM (Cannes, France, +Sept. 1997), pp. 115--126. + +\[Labovitz 2010\] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. +Oberheide, F. Jahanian, "Internet Inter-Domain Traffic," Proc. 2010 ACM +SIGCOMM. + +\[Labrador 1999\] M. Labrador, S. Banerjee, "Packet Dropping Policies +for ATM and IP Networks," IEEE Communications Surveys, Vol. 2, No. 3 +(Third Quarter 1999), pp. 2--14. + +\[Lacage 2004\] M. Lacage, M.H. Manshaei, T. Turletti, "IEEE 802.11 Rate +Adaptation: A Practical Approach," ACM Int. Symposium on Modeling, +Analysis, and Simulation of Wireless and Mobile Systems (MSWiM) (Venice, +Italy, Oct. 2004). + +\[Lakhina 2004\] A. Lakhina, M. Crovella, C. Diot, "Diagnosing +Network-Wide Traffic Anomalies," Proc. 2004 ACM SIGCOMM. + +\[Lakhina 2005\] A. Lakhina, M. Crovella, C. Diot, "Mining Anomalies +Using Traffic Feature Distributions," Proc. 2005 ACM SIGCOMM. + +\[Lakshman 1997\] T. V. Lakshman, U. Madhow, "The Performance of TCP/IP +for Networks with High Bandwidth-Delay Products and Random Loss," +IEEE/ACM Transactions on Networking, Vol. 5, No. 3 (1997), pp. 336--350. + +\[Lakshman 2004\] T. V. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, +T. Woo, "The SoftRouter Architecture," Proc. 3nd ACM Workshop on Hot +Topics in Networks (Hotnets-III), Nov. 2004. + + \[Lam 1980\] S. Lam, "A Carrier Sense Multiple Access Protocol for Local +Networks," Computer Networks, Vol. 4 (1980), pp. 21--32. + +\[Lamport 1989\] L. Lamport, "The Part-Time Parliament," Technical +Report 49, Systems Research Center, Digital Equipment Corp., Palo Alto, +Sept. 1989. + +\[Lampson 1983\] Lampson, Butler W. "Hints for computer system design," +ACM SIGOPS Operating Systems Review, Vol. 17, No. 5, 1983. + +\[Lampson 1996\] B. Lampson, "How to Build a Highly Available System +Using Consensus," Proc. 10th International Workshop on Distributed +Algorithms (WDAG '96), Özalp Babaoglu and Keith Marzullo (Eds.), +Springer-Verlag, pp. 1--17. + +\[Lawton 2001\] G. Lawton, "Is IPv6 Finally Gaining Ground?" IEEE +Computer Magazine (Aug. 2001), pp. 11--15. + +\[LeBlond 2011\] S. Le Blond, C. Zhang, A. Legout, K. Ross, W. Dabbous. +2011, "I know where you are and what you are sharing: exploiting P2P +communications to invade users' privacy." 2011 ACM Internet Measurement +Conference, ACM, New York, NY, USA, pp. 45--60. + +\[Leighton 2009\] T. Leighton, "Improving Performance on the Internet," +Communications of the ACM, Vol. 52, No. 2 (Feb. 2009), pp. 44--51. + +\[Leiner 1998\] B. Leiner, V. Cerf, D. Clark, R. Kahn, L. Kleinrock, D. +Lynch, J. Postel, L. Roberts, S. Woolf, "A Brief History of the +Internet," http://www.isoc.org/internet/history/brief.html + +\[Leung 2006\] K. Leung, V. O.K. Li, "TCP in Wireless Networks: Issues, +Approaches, and Challenges," IEEE Commun. Surveys and Tutorials, Vol. 8, +No. 4 (2006), pp. 64--79. + +\[Levin 2012\] D. Levin, A. Wundsam, B. Heller, N. Handigol, A. +Feldmann, "Logically Centralized?: State Distribution Trade-offs in +Software Defined Networks," Proc. First Workshop on Hot Topics in +Software Defined Networks (Aug. 2012), pp. 1--6. + +\[Li 2004\] L. Li, D. Alderson, W. Willinger, J. Doyle, "A +First-Principles Approach to Understanding the Internet's Router-Level +Topology," Proc. 2004 ACM SIGCOMM (Portland, OR, Aug. 2004). + +\[Li 2007\] J. Li, M. Guidero, Z. Wu, E. Purpus, T. Ehrenkranz, "BGP +Routing Dynamics Revisited." ACM Computer Communication Review +(Apr. 2007). + +\[Li 2015\] S.Q. Li, "Building Softcom Ecosystem Foundation," Open +Networking Summit, 2015. + +\[Lin 2001\] Y. Lin, I. Chlamtac, Wireless and Mobile Network +Architectures, John Wiley and Sons, New York, NY, 2001. + + \[Liogkas 2006\] N. Liogkas, R. Nelson, E. Kohler, L. Zhang, "Exploiting +BitTorrent for Fun (but Not Profit)," 6th International Workshop on +Peer-to-Peer Systems (IPTPS 2006). + +\[Liu 2003\] J. Liu, I. Matta, M. Crovella, "End-to-End Inference of +Loss Nature in a Hybrid Wired/Wireless Environment," Proc. WiOpt'03: +Modeling and Optimization in Mobile, Ad Hoc and Wireless Networks. + +\[Locher 2006\] T. Locher, P. Moor, S. Schmid, R. Wattenhofer, "Free +Riding in BitTorrent is Cheap," Proc. ACM HotNets 2006 (Irvine CA, +Nov. 2006). + +\[Lui 2004\] J. Lui, V. Misra, D. Rubenstein, "On the Robustness of Soft +State Protocols," Proc. IEEE Int. Conference on Network Protocols (ICNP +'04), pp. 50--60. + +\[Mahdavi 1997\] J. Mahdavi, S. Floyd, "TCP-Friendly Unicast Rate-Based +Flow Control," unpublished note (Jan. 1997). + +\[MaxMind 2016\] http://www.maxmind.com/app/ip-location + +\[Maymounkov 2002\] P. Maymounkov, D. Mazières. "Kademlia: A +Peer-to-Peer Information System Based on the XOR Metric." Proceedings of +the 1st International Workshop on Peerto-Peer Systems (IPTPS '02) +(Mar. 2002), pp. 53--65. + +\[McKeown 1997a\] N. McKeown, M. Izzard, A. Mekkittikul, W. Ellersick, +M. Horowitz, "The Tiny Tera: A Packet Switch Core," IEEE Micro Magazine +(Jan.--Feb. 1997). + +\[McKeown 1997b\] N. McKeown, "A Fast Switched Backplane for a Gigabit +Switched Router," Business Communications Review, Vol. 27, No. 12. +http://tinytera.stanford.edu/\~nickm/papers/cisco_fasts_wp.pdf + +\[McKeown 2008\] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, +L. Peterson, J. Rexford, S. Shenker, J. Turner. 2008. OpenFlow: Enabling +Innovation in Campus Networks. SIGCOMM Comput. Commun. Rev. 38, 2 +(Mar. 2008), pp. 69--74. + +\[McQuillan 1980\] J. McQuillan, I. Richer, E. Rosen, "The New Routing +Algorithm for the Arpanet," IEEE Transactions on Communications, Vol. +28, No. 5 (May 1980), pp. 711--719. + +\[Metcalfe 1976\] R. M. Metcalfe, D. R. Boggs. "Ethernet: Distributed +Packet Switching for Local Computer Networks," Communications of the +Association for Computing Machinery, Vol. 19, No. 7 (July 1976), +pp. 395--404. + +\[Meyers 2004\] A. Myers, T. Ng, H. Zhang, "Rethinking the Service +Model: Scaling Ethernet to a Million Nodes," ACM Hotnets Conference, +2004. + + \[MFA Forum 2016\] IP/MPLS Forum homepage, http://www.ipmplsforum.org/ + +\[Mockapetris 1988\] P. V. Mockapetris, K. J. Dunlap, "Development of +the Domain Name System," Proc. 1988 ACM SIGCOMM (Stanford, CA, +Aug. 1988). + +\[Mockapetris 2005\] P. Mockapetris, Sigcomm Award Lecture, video +available at http://www.postel.org/sigcomm + +\[Molinero-Fernandez 2002\] P. Molinaro-Fernandez, N. McKeown, H. Zhang, +"Is IP Going to Take Over the World (of Communications)?" Proc. 2002 ACM +Hotnets. + +\[Molle 1987\] M. L. Molle, K. Sohraby, A. N. Venetsanopoulos, +"Space-Time Models of Asynchronous CSMA Protocols for Local Area +Networks," IEEE Journal on Selected Areas in Communications, Vol. 5, +No. 6 (1987), pp. 956--968. + +\[Moore 2001\] D. Moore, G. Voelker, S. Savage, "Inferring Internet +Denial of Service Activity," Proc. 2001 USENIX Security Symposium +(Washington, DC, Aug. 2001). + +\[Motorola 2007\] Motorola, "Long Term Evolution (LTE): A Technical +Overview," +http://www.motorola.com/staticfiles/Business/Solutions/Industry%20Solutions/Service%20Providers/Wireless%20Operators/LTE/\_Document/Static%20Files/6834_MotDoc_New.pdf + +\[Mouly 1992\] M. Mouly, M. Pautet, The GSM System for Mobile +Communications, Cell and Sys, Palaiseau, France, 1992. + +\[Moy 1998\] J. Moy, OSPF: Anatomy of An Internet Routing Protocol, +Addison-Wesley, Reading, MA, 1998. + +\[Mukherjee 1997\] B. Mukherjee, Optical Communication Networks, +McGraw-Hill, 1997. + +\[Mukherjee 2006\] B. Mukherjee, Optical WDM Networks, Springer, 2006. + +\[Mysore 2009\] R. N. Mysore, A. Pamboris, N. Farrington, N. Huang, P. +Miri, S. Radhakrishnan, V. Subramanya, A. Vahdat, "PortLand: A Scalable +Fault-Tolerant Layer 2 Data Center Network Fabric," Proc. 2009 ACM +SIGCOMM. + +\[Nahum 2002\] E. Nahum, T. Barzilai, D. Kandlur, "Performance Issues in +WWW Servers," IEEE/ACM Transactions on Networking, Vol 10, No. 1 +(Feb. 2002). + +\[Netflix Open Connect 2016\] Netflix Open Connect CDN, 2016, https:// +openconnect.netflix.com/ + +\[Netflix Video 1\] Designing Netflix's Content Delivery System, D. +Fulllager, 2014, https://www.youtube.com/watch?v=LkLLpYdDINA + + \[Netflix Video 2\] Scaling the Netflix Global CDN, D. Temkin, 2015, +https://www .youtube.com/watch?v=tbqcsHg-Q_o + +\[Neumann 1997\] R. Neumann, "Internet Routing Black Hole," The Risks +Digest: Forum on Risks to the Public in Computers and Related Systems, +Vol. 19, No. 12 (May 1997). +http://catless.ncl.ac.uk/Risks/19.12.html#subj1.1 + +\[Neville-Neil 2009\] G. Neville-Neil, "Whither Sockets?" Communications +of the ACM, Vol. 52, No. 6 (June 2009), pp. 51--55. + +\[Nicholson 2006\] A Nicholson, Y. Chawathe, M. Chen, B. Noble, D. +Wetherall, "Improved Access Point Selection," Proc. 2006 ACM Mobisys +Conference (Uppsala Sweden, 2006). + +\[Nielsen 1997\] H. F. Nielsen, J. Gettys, A. Baird-Smith, E. +Prud'hommeaux, H. W. Lie, C. Lilley, "Network Performance Effects of +HTTP/1.1, CSS1, and PNG," W3C Document, 1997 (also appears in Proc. 1997 +ACM SIGCOM (Cannes, France, Sept 1997), pp. 155--166. + +\[NIST 2001\] National Institute of Standards and Technology, "Advanced +Encryption Standard (AES)," Federal Information Processing Standards +197, Nov. 2001, http:// +csrc.nist.gov/publications/fips/fips197/fips-197.pdf + +\[NIST IPv6 2015\] US National Institute of Standards and Technology, +"Estimating IPv6 & DNSSEC Deployment SnapShots," +http://fedv6-deployment.antd.nist.gov/snapall.html + +\[Nmap 2012\] Nmap homepage, http://www.insecure.com/nmap + +\[Nonnenmacher 1998\] J. Nonnenmacher, E. Biersak, D. Towsley, +"Parity-Based Loss Recovery for Reliable Multicast Transmission," +IEEE/ACM Transactions on Networking, Vol. 6, No. 4 (Aug. 1998), +pp. 349--361. + +\[Nygren 2010\] Erik Nygren, Ramesh K. Sitaraman, and Jennifer Sun, "The +Akamai Network: A Platform for High-performance Internet Applications," +SIGOPS Oper. Syst. Rev. 44, 3 (Aug. 2010), 2--19. + +\[ONF 2016\] Open Networking Foundation, Technical Library, +https://www.opennetworking.org/sdn-resources/technical-library + +\[ONOS 2016\] Open Network Operating System (ONOS), "Architecture +Guide," https://wiki.onosproject.org/display/ONOS/Architecture+Guide, +2016. + +\[OpenFlow 2009\] Open Network Foundation, "OpenFlow Switch +Specification 1.0.0, TS-001," +https://www.opennetworking.org/images/stories/downloads/sdnresources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf + + \[OpenDaylight Lithium 2016\] OpenDaylight, "Lithium," +https://www.opendaylight.org/lithium + +\[OSI 2012\] International Organization for Standardization homepage, +http://www.iso.org/iso/en/ISOOnline.frontpage + +\[Osterweil 2012\] E. Osterweil, D. McPherson, S. DiBenedetto, C. +Papadopoulos, D. Massey, "Behavior of DNS Top Talkers," Passive and +Active Measurement Conference, 2012. + +\[Padhye 2000\] J. Padhye, V. Firoiu, D. Towsley, J. Kurose, "Modeling +TCP Reno Performance: A Simple Model and Its Empirical Validation," +IEEE/ACM Transactions on Networking, Vol. 8 No. 2 (Apr. 2000), +pp. 133--145. + +\[Padhye 2001\] J. Padhye, S. Floyd, "On Inferring TCP Behavior," Proc. +2001 ACM SIGCOMM (San Diego, CA, Aug. 2001). + +\[Palat 2009\] S. Palat, P. Godin, "The LTE Network Architecture: A +Comprehensive Tutorial," in LTE---The UMTS Long Term Evolution: From +Theory to Practice. Also available as a standalone Alcatel white paper. + +\[Panda 2013\] A. Panda, C. Scott, A. Ghodsi, T. Koponen, S. Shenker, +"CAP for Networks," Proc. ACM HotSDN '13, pp. 91--96. + +\[Parekh 1993\] A. Parekh, R. Gallagher, "A Generalized Processor +Sharing Approach to Flow Control in Integrated Services Networks: The +Single-Node Case," IEEE/ACM Transactions on Networking, Vol. 1, No. 3 +(June 1993), pp. 344--357. + +\[Partridge 1992\] C. Partridge, S. Pink, "An Implementation of the +Revised Internet Stream Protocol (ST-2)," Journal of Internetworking: +Research and Experience, Vol. 3, No. 1 (Mar. 1992). + +\[Partridge 1998\] C. Partridge, et al. "A Fifty Gigabit per second IP +Router," IEEE/ACM Transactions on Networking, Vol. 6, No. 3 (Jun. 1998), +pp. 237--248. + +\[Pathak 2010\] A. Pathak, Y. A. Wang, C. Huang, A. Greenberg, Y. C. Hu, +J. Li, K. W. Ross, "Measuring and Evaluating TCP Splitting for Cloud +Services," Passive and Active Measurement (PAM) Conference (Zurich, +2010). + +\[Perkins 1994\] A. Perkins, "Networking with Bob Metcalfe," The Red +Herring Magazine (Nov. 1994). + +\[Perkins 1998\] C. Perkins, O. Hodson, V. Hardman, "A Survey of Packet +Loss Recovery Techniques for Streaming Audio," IEEE Network Magazine +(Sept./Oct. 1998), pp. 40--47. + + \[Perkins 1998b\] C. Perkins, Mobile IP: Design Principles and Practice, +Addison-Wesley, Reading, MA, 1998. + +\[Perkins 2000\] C. Perkins, Ad Hoc Networking, Addison-Wesley, Reading, +MA, 2000. + +\[Perlman 1999\] R. Perlman, Interconnections: Bridges, Routers, +Switches, and Internetworking Protocols, 2nd ed., Addison-Wesley +Professional Computing Series, Reading, MA, 1999. + +\[PGPI 2016\] The International PGP homepage, http://www.pgpi.org + +\[Phifer 2000\] L. Phifer, "The Trouble with NAT," The Internet Protocol +Journal, Vol. 3, No. 4 (Dec. 2000), +http://www.cisco.com/warp/public/759/ipj_3-4/ipj\_ 3-4_nat.html + +\[Piatek 2007\] M. Piatek, T. Isdal, T. Anderson, A. Krishnamurthy, A. +Venkataramani, "Do Incentives Build Robustness in Bittorrent?," Proc. +NSDI (2007). + +\[Piatek 2008\] M. Piatek, T. Isdal, A. Krishnamurthy, T. Anderson, "One +Hop Reputations for Peer-to-peer File Sharing Workloads," Proc. NSDI +(2008). + +\[Pickholtz 1982\] R. Pickholtz, D. Schilling, L. Milstein, "Theory of +Spread Spectrum Communication---a Tutorial," IEEE Transactions on +Communications, Vol. 30, No. 5 (May 1982), pp. 855--884. + +\[PingPlotter 2016\] PingPlotter homepage, http://www.pingplotter.com + +\[Piscatello 1993\] D. Piscatello, A. Lyman Chapin, Open Systems +Networking, Addison-Wesley, Reading, MA, 1993. + +\[Pomeranz 2010\] H. Pomeranz, "Practical, Visual, Three-Dimensional +Pedagogy for Internet Protocol Packet Header Control Fields," +https://righteousit.wordpress.com/ +2010/06/27/practical-visual-three-dimensional-pedagogy-for-internet-protocol-packet-header-control-fields/, +June 2010. + +\[Potaroo 2016\] "Growth of the BGP Table--1994 to Present," +http://bgp.potaroo.net/ + +\[PPLive 2012\] PPLive homepage, http://www.pplive.com + +\[Qazi 2013\] Z. Qazi, C. Tu, L. Chiang, R. Miao, V. Sekar, M. Yu, +"SIMPLE-fying Middlebox Policy Enforcement Using SDN," ACM SIGCOMM +Conference (Aug. 2013), pp. 27--38. + +\[Quagga 2012\] Quagga, "Quagga Routing Suite," http://www.quagga.net/ + + \[Quittner 1998\] J. Quittner, M. Slatalla, Speeding the Net: The Inside +Story of Netscape and How It Challenged Microsoft, Atlantic Monthly +Press, 1998. + +\[Quova 2016\] www.quova.com + +\[Ramakrishnan 1990\] K. K. Ramakrishnan, R. Jain, "A Binary Feedback +Scheme for Congestion Avoidance in Computer Networks," ACM Transactions +on Computer Systems, Vol. 8, No. 2 (May 1990), pp. 158--181. + +\[Raman 1999\] S. Raman, S. McCanne, "A Model, Analysis, and Protocol +Framework for Soft State-based Communication," Proc. 1999 ACM SIGCOMM +(Boston, MA, Aug. 1999). + +\[Raman 2007\] B. Raman, K. Chebrolu, "Experiences in Using WiFi for +Rural Internet in India," IEEE Communications Magazine, Special Issue on +New Directions in Networking Technologies in Emerging Economies +(Jan. 2007). + +\[Ramaswami 2010\] R. Ramaswami, K. Sivarajan, G. Sasaki, Optical +Networks: A Practical Perspective, Morgan Kaufman Publishers, 2010. + +\[Ramjee 1994\] R. Ramjee, J. Kurose, D. Towsley, H. Schulzrinne, +"Adaptive Playout Mechanisms for Packetized Audio Applications in +Wide-Area Networks," Proc. 1994 IEEE INFOCOM. + +\[Rao 2011\] A. S. Rao, Y. S. Lim, C. Barakat, A. Legout, D. Towsley, W. +Dabbous, "Network Characteristics of Video Streaming Traffic," Proc. +2011 ACM CoNEXT (Tokyo). + +\[Ren 2006\] S. Ren, L. Guo, X. Zhang, "ASAP: An AS-Aware Peer-Relay +Protocol for High Quality VoIP," Proc. 2006 IEEE ICDCS (Lisboa, +Portugal, July 2006). + +\[Rescorla 2001\] E. Rescorla, SSL and TLS: Designing and Building +Secure Systems, Addison-Wesley, Boston, 2001. + +\[RFC 001\] S. Crocker, "Host Software," RFC 001 (the very first RFC!). + +\[RFC 768\] J. Postel, "User Datagram Protocol," RFC 768, Aug. 1980. + +\[RFC 791\] J. Postel, "Internet Protocol: DARPA Internet Program +Protocol Specification," RFC 791, Sept. 1981. + +\[RFC 792\] J. Postel, "Internet Control Message Protocol," RFC 792, +Sept. 1981. + + \[RFC 793\] J. Postel, "Transmission Control Protocol," RFC 793, +Sept. 1981. + +\[RFC 801\] J. Postel, "NCP/TCP Transition Plan," RFC 801, Nov. 1981. + +\[RFC 826\] D. C. Plummer, "An Ethernet Address Resolution +Protocol---or--- Converting Network Protocol Addresses to 48-bit +Ethernet Address for Transmission on Ethernet Hardware," RFC 826, +Nov. 1982. + +\[RFC 829\] V. Cerf, "Packet Satellite Technology Reference Sources," +RFC 829, Nov. 1982. + +\[RFC 854\] J. Postel, J. Reynolds, "TELNET Protocol Specification," RFC +854, May 1993. + +\[RFC 950\] J. Mogul, J. Postel, "Internet Standard Subnetting +Procedure," RFC 950, Aug. 1985. + +\[RFC 959\] J. Postel and J. Reynolds, "File Transfer Protocol (FTP)," +RFC 959, Oct. 1985. + +\[RFC 1034\] P. V. Mockapetris, "Domain Names---Concepts and +Facilities," RFC 1034, Nov. 1987. + +\[RFC 1035\] P. Mockapetris, "Domain Names---Implementation and +Specification," RFC 1035, Nov. 1987. + +\[RFC 1058\] C. L. Hendrick, "Routing Information Protocol," RFC 1058, +June 1988. + +\[RFC 1071\] R. Braden, D. Borman, and C. Partridge, "Computing the +Internet Checksum," RFC 1071, Sept. 1988. + +\[RFC 1122\] R. Braden, "Requirements for Internet Hosts---Communication +Layers," RFC 1122, Oct. 1989. + +\[RFC 1123\] R. Braden, ed., "Requirements for Internet +Hosts---Application and Support," RFC-1123, Oct. 1989. + +\[RFC 1142\] D. Oran, "OSI IS-IS Intra-Domain Routing Protocol," RFC +1142, Feb. 1990. + +\[RFC 1190\] C. Topolcic, "Experimental Internet Stream Protocol: +Version 2 (ST-II)," RFC 1190, Oct. 1990. + +\[RFC 1256\] S. Deering, "ICMP Router Discovery Messages," RFC 1256, +Sept. 1991. + + \[RFC 1320\] R. Rivest, "The MD4 Message-Digest Algorithm," RFC 1320, +Apr. 1992. + +\[RFC 1321\] R. Rivest, "The MD5 Message-Digest Algorithm," RFC 1321, +Apr. 1992. + +\[RFC 1323\] V. Jacobson, S. Braden, D. Borman, "TCP Extensions for High +Performance," RFC 1323, May 1992. + +\[RFC 1422\] S. Kent, "Privacy Enhancement for Internet Electronic Mail: +Part II: Certificate-Based Key Management," RFC 1422. + +\[RFC 1546\] C. Partridge, T. Mendez, W. Milliken, "Host Anycasting +Service," RFC 1546, 1993. + +\[RFC 1584\] J. Moy, "Multicast Extensions to OSPF," RFC 1584, +Mar. 1994. + +\[RFC 1633\] R. Braden, D. Clark, S. Shenker, "Integrated Services in +the Internet Architecture: an Overview," RFC 1633, June 1994. + +\[RFC 1636\] R. Braden, D. Clark, S. Crocker, C. Huitema, "Report of IAB +Workshop on Security in the Internet Architecture," RFC 1636, Nov. 1994. + +\[RFC 1700\] J. Reynolds, J. Postel, "Assigned Numbers," RFC 1700, +Oct. 1994. + +\[RFC 1752\] S. Bradner, A. Mankin, "The Recommendations for the IP Next +Generation Protocol," RFC 1752, Jan. 1995. + +\[RFC 1918\] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. +Lear, "Address Allocation for Private Internets," RFC 1918, Feb. 1996. + +\[RFC 1930\] J. Hawkinson, T. Bates, "Guidelines for Creation, +Selection, and Registration of an Autonomous System (AS)," RFC 1930, +Mar. 1996. + +\[RFC 1939\] J. Myers, M. Rose, "Post Office Protocol---Version 3," RFC +1939, May 1996. + +\[RFC 1945\] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext +Transfer Protocol---HTTP/1.0," RFC 1945, May 1996. + +\[RFC 2003\] C. Perkins, "IP Encapsulation Within IP," RFC 2003, +Oct. 1996. + +\[RFC 2004\] C. Perkins, "Minimal Encapsulation Within IP," RFC 2004, +Oct. 1996. + + \[RFC 2018\] M. Mathis, J. Mahdavi, S. Floyd, A. Romanow, "TCP Selective +Acknowledgment Options," RFC 2018, Oct. 1996. + +\[RFC 2131\] R. Droms, "Dynamic Host Configuration Protocol," RFC 2131, +Mar. 1997. + +\[RFC 2136\] P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic +Updates in the Domain Name System," RFC 2136, Apr. 1997. + +\[RFC 2205\] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, +"Resource ReSerVation Protocol (RSVP)---Version 1 Functional +Specification," RFC 2205, Sept. 1997. + +\[RFC 2210\] J. Wroclawski, "The Use of RSVP with IETF Integrated +Services," RFC 2210, Sept. 1997. + +\[RFC 2211\] J. Wroclawski, "Specification of the Controlled-Load +Network Element Service," RFC 2211, Sept. 1997. + +\[RFC 2215\] S. Shenker, J. Wroclawski, "General Characterization +Parameters for Integrated Service Network Elements," RFC 2215, +Sept. 1997. + +\[RFC 2326\] H. Schulzrinne, A. Rao, R. Lanphier, "Real Time Streaming +Protocol (RTSP)," RFC 2326, Apr. 1998. + +\[RFC 2328\] J. Moy, "OSPF Version 2," RFC 2328, Apr. 1998. + +\[RFC 2420\] H. Kummert, "The PPP Triple-DES Encryption Protocol +(3DESE)," RFC 2420, Sept. 1998. + +\[RFC 2453\] G. Malkin, "RIP Version 2," RFC 2453, Nov. 1998. + +\[RFC 2460\] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) +Specification," RFC 2460, Dec. 1998. + +\[RFC 2475\] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. +Weiss, "An Architecture for Differentiated Services," RFC 2475, +Dec. 1998. + +\[RFC 2578\] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure of +Management Information Version 2 (SMIv2)," RFC 2578, Apr. 1999. + +\[RFC 2579\] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Textual +Conventions for SMIv2," RFC 2579, Apr. 1999. + +\[RFC 2580\] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conformance +Statements for SMIv2," RFC 2580, Apr. 1999. + + \[RFC 2597\] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured +Forwarding PHB Group," RFC 2597, June 1999. + +\[RFC 2616\] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, +P. Leach, T. Berners-Lee, R. Fielding, "Hypertext Transfer +Protocol---HTTP/1.1," RFC 2616, June 1999. + +\[RFC 2663\] P. Srisuresh, M. Holdrege, "IP Network Address Translator +(NAT) Terminology and Considerations," RFC 2663. + +\[RFC 2702\] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, +"Requirements for Traffic Engineering Over MPLS," RFC 2702, Sept. 1999. + +\[RFC 2827\] P. Ferguson, D. Senie, "Network Ingress Filtering: +Defeating Denial of Service Attacks which Employ IP Source Address +Spoofing," RFC 2827, May 2000. + +\[RFC 2865\] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote +Authentication Dial In User Service (RADIUS)," RFC 2865, June 2000. + +\[RFC 3007\] B. Wellington, "Secure Domain Name System (DNS) Dynamic +Update," RFC 3007, Nov. 2000. + +\[RFC 3022\] P. Srisuresh, K. Egevang, "Traditional IP Network Address +Translator (Traditional NAT)," RFC 3022, Jan. 2001. + +\[RFC 3022\] P. Srisuresh, K. Egevang, "Traditional IP Network Address +Translator (Traditional NAT)," RFC 3022, Jan. 2001. + +\[RFC 3031\] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label +Switching Architecture," RFC 3031, Jan. 2001. + +\[RFC 3032\] E. Rosen, D. Tappan, G. Fedorkow, Y. Rekhter, D. Farinacci, +T. Li, A. Conta, "MPLS Label Stack Encoding," RFC 3032, Jan. 2001. + +\[RFC 3168\] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of +Explicit Congestion Notification (ECN) to IP," RFC 3168, Sept. 2001. + +\[RFC 3209\] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. +Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, +Dec. 2001. + +\[RFC 3221\] G. Huston, "Commentary on Inter-Domain Routing in the +Internet," RFC 3221, Dec. 2001. + +\[RFC 3232\] J. Reynolds, "Assigned Numbers: RFC 1700 Is Replaced by an +On-line Database," RFC 3232, Jan. 2002. + +\[RFC 3234\] B. Carpenter, S. Brim, "Middleboxes: Taxonomy and Issues," +RFC 3234, Feb. 2002. + + \[RFC 3246\] B. Davie, A. Charny, J.C.R. Bennet, K. Benson, J.Y. Le +Boudec, W. Courtney, S. Davari, V. Firoiu, D. Stiliadis, "An Expedited +Forwarding PHB (Per-Hop Behavior)," RFC 3246, Mar. 2002. + +\[RFC 3260\] D. Grossman, "New Terminology and Clarifications for +Diffserv," RFC 3260, Apr. 2002. + +\[RFC 3261\] J. Rosenberg, H. Schulzrinne, G. Carmarillo, A. Johnston, +J. Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session +Initiation Protocol," RFC 3261, July 2002. + +\[RFC 3272\] J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. +Christian, W. S. Lai, "Overview and Principles of Internet Traffic +Engineering," RFC 3272, May 2002. + +\[RFC 3286\] L. Ong, J. Yoakum, "An Introduction to the Stream Control +Transmission Protocol (SCTP)," RFC 3286, May 2002. + +\[RFC 3346\] J. Boyle, V. Gill, A. Hannan, D. Cooper, D. Awduche, B. +Christian, W. S. Lai, "Applicability Statement for Traffic Engineering +with MPLS," RFC 3346, Aug. 2002. + +\[RFC 3390\] M. Allman, S. Floyd, C. Partridge, "Increasing TCP's +Initial Window," RFC 3390, Oct. 2002. + +\[RFC 3410\] J. Case, R. Mundy, D. Partain, "Introduction and +Applicability Statements for Internet Standard Management Framework," +RFC 3410, Dec. 2002. + +\[RFC 3414\] U. Blumenthal and B. Wijnen, "User-based Security Model +(USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)," +RFC 3414, Dec. 2002. + +\[RFC 3416\] R. Presuhn, J. Case, K. McCloghrie, M. Rose, S. Waldbusser, +"Version 2 of the Protocol Operations for the Simple Network Management +Protocol (SNMP)," Dec. 2002. + +\[RFC 3439\] R. Bush, D. Meyer, "Some Internet Architectural Guidelines +and Philosophy," RFC 3439, Dec. 2003. + +\[RFC 3447\] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards +(PKCS) #1: RSA Cryptography Specifications Version 2.1," RFC 3447, +Feb. 2003. + +\[RFC 3468\] L. Andersson, G. Swallow, "The Multiprotocol Label +Switching (MPLS) Working Group Decision on MPLS Signaling Protocols," +RFC 3468, Feb. 2003. + +\[RFC 3469\] V. Sharma, Ed., F. Hellstrand, Ed, "Framework for +Multi-Protocol Label Switching (MPLS)-based Recovery," RFC 3469, +Feb. 2003. ftp://ftp.rfc-editor.org/innotes/rfc3469.txt + +\[RFC 3501\] M. Crispin, "Internet Message Access Protocol---Version +4rev1," RFC 3501, Mar. 2003. + + \[RFC 3550\] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: +A Transport Protocol for Real-Time Applications," RFC 3550, July 2003. + +\[RFC 3588\] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. Arkko, +"Diameter Base Protocol," RFC 3588, Sept. 2003. + +\[RFC 3649\] S. Floyd, "HighSpeed TCP for Large Congestion Windows," RFC +3649, Dec. 2003. + +\[RFC 3746\] L. Yang, R. Dantu, T. Anderson, R. Gopal, "Forwarding and +Control Element Separation (ForCES) Framework," Internet, RFC 3746, +Apr. 2004. + +\[RFC 3748\] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. +Levkowetz, Ed., "Extensible Authentication Protocol (EAP)," RFC 3748, +June 2004. + +\[RFC 3782\] S. Floyd, T. Henderson, A. Gurtov, "The NewReno +Modification to TCP's Fast Recovery Algorithm," RFC 3782, Apr. 2004. + +\[RFC 4213\] E. Nordmark, R. Gilligan, "Basic Transition Mechanisms for +IPv6 Hosts and Routers," RFC 4213, Oct. 2005. + +\[RFC 4271\] Y. Rekhter, T. Li, S. Hares, Ed., "A Border Gateway +Protocol 4 (BGP-4)," RFC 4271, Jan. 2006. + +\[RFC 4272\] S. Murphy, "BGP Security Vulnerabilities Analysis," RFC +4274, Jan. 2006. + +\[RFC 4291\] R. Hinden, S. Deering, "IP Version 6 Addressing +Architecture," RFC 4291, Feb. 2006. + +\[RFC 4340\] E. Kohler, M. Handley, S. Floyd, "Datagram Congestion +Control Protocol (DCCP)," RFC 4340, Mar. 2006. + +\[RFC 4443\] A. Conta, S. Deering, M. Gupta, Ed., "Internet Control +Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) +Specification," RFC 4443, Mar. 2006. + +\[RFC 4346\] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS) +Protocol Version 1.1," RFC 4346, Apr. 2006. + +\[RFC 4514\] K. Zeilenga, Ed., "Lightweight Directory Access Protocol +(LDAP): String Representation of Distinguished Names," RFC 4514, June +2006. + +\[RFC 4601\] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol +Independent Multicast---Sparse Mode (PIM-SM): Protocol Specification +(Revised)," RFC 4601, Aug. 2006. + + \[RFC 4632\] V. Fuller, T. Li, "Classless Inter-domain Routing (CIDR): +The Internet Address Assignment and Aggregation Plan," RFC 4632, +Aug. 2006. + +\[RFC 4960\] R. Stewart, ed., "Stream Control Transmission Protocol," +RFC 4960, Sept. 2007. + +\[RFC 4987\] W. Eddy, "TCP SYN Flooding Attacks and Common Mitigations," +RFC 4987, Aug. 2007. + +\[RFC 5000\] RFC editor, "Internet Official Protocol Standards," RFC +5000, May 2008. + +\[RFC 5109\] A. Li (ed.), "RTP Payload Format for Generic Forward Error +Correction," RFC 5109, Dec. 2007. + +\[RFC 5216\] D. Simon, B. Aboba, R. Hurst, "The EAP-TLS Authentication +Protocol," RFC 5216, Mar. 2008. + +\[RFC 5218\] D. Thaler, B. Aboba, "What Makes for a Successful +Protocol?," RFC 5218, July 2008. + +\[RFC 5321\] J. Klensin, "Simple Mail Transfer Protocol," RFC 5321, +Oct. 2008. + +\[RFC 5322\] P. Resnick, Ed., "Internet Message Format," RFC 5322, +Oct. 2008. + +\[RFC 5348\] S. Floyd, M. Handley, J. Padhye, J. Widmer, "TCP Friendly +Rate Control (TFRC): Protocol Specification," RFC 5348, Sept. 2008. + +\[RFC 5389\] J. Rosenberg, R. Mahy, P. Matthews, D. Wing, "Session +Traversal Utilities for NAT (STUN)," RFC 5389, Oct. 2008. + +\[RFC 5411\] J Rosenberg, "A Hitchhiker's Guide to the Session +Initiation Protocol (SIP)," RFC 5411, Feb. 2009. + +\[RFC 5681\] M. Allman, V. Paxson, E. Blanton, "TCP Congestion Control," +RFC 5681, Sept. 2009. + +\[RFC 5944\] C. Perkins, Ed., "IP Mobility Support for IPv4, Revised," +RFC 5944, Nov. 2010. + +\[RFC 6265\] A Barth, "HTTP State Management Mechanism," RFC 6265, +Apr. 2011. + +\[RFC 6298\] V. Paxson, M. Allman, J. Chu, M. Sargent, "Computing TCP's +Retransmission Timer," RFC 6298, June 2011. + + \[RFC 7020\] R. Housley, J. Curran, G. Huston, D. Conrad, "The Internet +Numbers Registry System," RFC 7020, Aug. 2013. + +\[RFC 7094\] D. McPherson, D. Oran, D. Thaler, E. Osterweil, +"Architectural Considerations of IP Anycast," RFC 7094, Jan. 2014. + +\[RFC 7323\] D. Borman, R. Braden, V. Jacobson, R. Scheffenegger (ed.), +"TCP Extensions for High Performance," RFC 7323, Sept. 2014. + +\[RFC 7540\] M. Belshe, R. Peon, M. Thomson (Eds), "Hypertext Transfer +Protocol Version 2 (HTTP/2)," RFC 7540, May 2015. + +\[Richter 2015\] P. Richter, M. Allman, R. Bush, V. Paxson, "A Primer on +IPv4 Scarcity," ACM SIGCOMM Computer Communication Review, Vol. 45, +No. 2 (Apr. 2015), pp. 21--32. + +\[Roberts 1967\] L. Roberts, T. Merril, "Toward a Cooperative Network of +Time-Shared Computers," AFIPS Fall Conference (Oct. 1966). + +\[Rodriguez 2010\] R. Rodrigues, P. Druschel, "Peer-to-Peer Systems," +Communications of the ACM, Vol. 53, No. 10 (Oct. 2010), pp. 72--82. + +\[Rohde 2008\] Rohde, Schwarz, "UMTS Long Term Evolution (LTE) +Technology Introduction," Application Note 1MA111. + +\[Rom 1990\] R. Rom, M. Sidi, Multiple Access Protocols: Performance and +Analysis, Springer-Verlag, New York, 1990. + +\[Root Servers 2016\] Root Servers home page, +http://www.root-servers.org/ + +\[RSA 1978\] R. Rivest, A. Shamir, L. Adelman, "A Method for Obtaining +Digital Signatures and Public-key Cryptosystems," Communications of the +ACM, Vol. 21, No. 2 (Feb. 1978), pp. 120--126. + +\[RSA Fast 2012\] RSA Laboratories, "How Fast Is RSA?" +http://www.rsa.com/rsalabs/node.asp?id=2215 + +\[RSA Key 2012\] RSA Laboratories, "How Large a Key Should Be Used in +the RSA Crypto System?" http://www.rsa.com/rsalabs/node.asp?id=2218 + +\[Rubenstein 1998\] D. Rubenstein, J. Kurose, D. Towsley, "Real-Time +Reliable Multicast Using Proactive Forward Error Correction," +Proceedings of NOSSDAV '98 (Cambridge, UK, July 1998). + +\[Ruiz-Sanchez 2001\] M. Ruiz-Sánchez, E. Biersack, W. Dabbous, "Survey +and Taxonomy of IP Address Lookup Algorithms," IEEE Network Magazine, +Vol. 15, No. 2 (Mar./Apr. 2001), pp. 8--23. + + \[Saltzer 1984\] J. Saltzer, D. Reed, D. Clark, "End-to-End Arguments in +System Design," ACM Transactions on Computer Systems (TOCS), Vol. 2, +No. 4 (Nov. 1984). + +\[Sandvine 2015\] "Global Internet Phenomena Report, Spring 2011," +http://www.sandvine.com/news/globalbroadbandtrends.asp, 2011. + +\[Sardar 2006\] B. Sardar, D. Saha, "A Survey of TCP Enhancements for +Last-Hop Wireless Networks," IEEE Commun. Surveys and Tutorials, Vol. 8, +No. 3 (2006), pp. 20--34. + +\[Saroiu 2002\] S. Saroiu, P. K. Gummadi, S. D. Gribble, "A Measurement +Study of Peer-to-Peer File Sharing Systems," Proc. of Multimedia +Computing and Networking (MMCN) (2002). + +\[Sauter 2014\] M. Sauter, From GSM to LTE-Advanced, John Wiley and +Sons, 2014. + +\[Savage 2015\] D. Savage, J. Ng, S. Moore, D. Slice, P. Paluch, R. +White, "Enhanced Interior Gateway Routing Protocol," Internet Draft, +draft-savage-eigrp-04.txt, Aug. 2015. + +\[Saydam 1996\] T. Saydam, T. Magedanz, "From Networks and Network +Management into Service and Service Management," Journal of Networks and +System Management, Vol. 4, No. 4 (Dec. 1996), pp. 345--348. + +\[Schiller 2003\] J. Schiller, Mobile Communications 2nd edition, +Addison Wesley, 2003. + +\[Schneier 1995\] B. Schneier, Applied Cryptography: Protocols, +Algorithms, and Source Code in C, John Wiley and Sons, 1995. + +\[Schulzrinne-RTP 2012\] Henning Schulzrinne's RTP site, +http://www.cs.columbia .edu/\~hgs/rtp + +\[Schulzrinne-SIP 2016\] Henning Schulzrinne's SIP site, +http://www.cs.columbia.edu/\~hgs/sip + +\[Schwartz 1977\] M. Schwartz, Computer-Communication Network Design and +Analysis, Prentice-Hall, Englewood Cliffs, NJ, 1997. + +\[Schwartz 1980\] M. Schwartz, Information, Transmission, Modulation, +and Noise, McGraw Hill, New York, NY 1980. + +\[Schwartz 1982\] M. Schwartz, "Performance Analysis of the SNA Virtual +Route Pacing Control," IEEE Transactions on Communications, Vol. 30, +No. 1 (Jan. 1982), pp. 172--184. + + \[Scourias 2012\] J. Scourias, "Overview of the Global System for Mobile +Communications: GSM." http://www.privateline.com/PCS/GSM0.html + +\[SDNHub 2016\] SDNHub, "App Development Tutorials," http://sdnhub.org/ +tutorials/ + +\[Segaller 1998\] S. Segaller, Nerds 2.0.1, A Brief History of the +Internet, TV Books, New York, 1998. + +\[Sekar 2011\] V. Sekar, S. Ratnasamy, M. Reiter, N. Egi, G. Shi, " The +Middlebox Manifesto: Enabling Innovation in Middlebox Deployment," Proc. +10th ACM Workshop on Hot Topics in Networks (HotNets), Article 21, 6 +pages. + +\[Serpanos 2011\] D. Serpanos, T. Wolf, Architecture of Network Systems, +Morgan Kaufmann Publishers, 2011. + +\[Shacham 1990\] N. Shacham, P. McKenney, "Packet Recovery in High-Speed +Networks Using Coding and Buffer Management," Proc. 1990 IEEE INFOCOM +(San Francisco, CA, Apr. 1990), pp. 124--131. + +\[Shaikh 2001\] A. Shaikh, R. Tewari, M. Agrawal, "On the Effectiveness +of DNS-based Server Selection," Proc. 2001 IEEE INFOCOM. + +\[Singh 1999\] S. Singh, The Code Book: The Evolution of Secrecy from +Mary, Queen of Scotsto Quantum Cryptography, Doubleday Press, 1999. + +\[Singh 2015\] A. Singh, J. Ong,. Agarwal, G. Anderson, A. Armistead, R. +Banno, S. Boving, G. Desai, B. Felderman, P. Germano, A. Kanagala, J. +Provost, J. Simmons, E. Tanda, J. Wanderer, U. Hölzle, S. Stuart, A. +Vahdat, "Jupiter Rising: A Decade of Clos Topologies and Centralized +Control in Google's Datacenter Network," Sigcomm, 2015. + +\[SIP Software 2016\] H. Schulzrinne Software Package site, +http://www.cs.columbia.edu/IRT/software + +\[Skoudis 2004\] E. Skoudis, L. Zeltser, Malware: Fighting Malicious +Code, Prentice Hall, 2004. + +\[Skoudis 2006\] E. Skoudis, T. Liston, Counter Hack Reloaded: A +Step-by-Step Guide to Computer Attacks and Effective Defenses (2nd +Edition), Prentice Hall, 2006. + +\[Smith 2009\] J. Smith, "Fighting Physics: A Tough Battle," +Communications of the ACM, Vol. 52, No. 7 (July 2009), pp. 60--65. + +\[Snort 2012\] Sourcefire Inc., Snort homepage, +http://http://www.snort.org/ + +\[Solensky 1996\] F. Solensky, "IPv4 Address Lifetime Expectations," in +IPng: Internet Protocol Next Generation (S. Bradner, A. Mankin, ed.), +Addison-Wesley, Reading, MA, + + 1996. + +\[Spragins 1991\] J. D. Spragins, Telecommunications Protocols and +Design, Addison-Wesley, Reading, MA, 1991. + +\[Srikant 2004\] R. Srikant, The Mathematics of Internet Congestion +Control, Birkhauser, 2004 + +\[Steinder 2002\] M. Steinder, A. Sethi, "Increasing Robustness of Fault +Localization Through Analysis of Lost, Spurious, and Positive Symptoms," +Proc. 2002 IEEE INFOCOM. + +\[Stevens 1990\] W. R. Stevens, Unix Network Programming, Prentice-Hall, +Englewood Cliffs, NJ. + +\[Stevens 1994\] W. R. Stevens, TCP/IP Illustrated, Vol. 1: The +Protocols, Addison-Wesley, Reading, MA, 1994. + +\[Stevens 1997\] W.R. Stevens, Unix Network Programming, Volume 1: +Networking APIs-Sockets and XTI, 2nd edition, Prentice-Hall, Englewood +Cliffs, NJ, 1997. + +\[Stewart 1999\] J. Stewart, BGP4: Interdomain Routing in the Internet, +Addison-Wesley, 1999. + +\[Stone 1998\] J. Stone, M. Greenwald, C. Partridge, J. Hughes, +"Performance of Checksums and CRC's Over Real Data," IEEE/ACM +Transactions on Networking, Vol. 6, No. 5 (Oct. 1998), pp. 529--543. + +\[Stone 2000\] J. Stone, C. Partridge, "When Reality and the Checksum +Disagree," Proc. 2000 ACM SIGCOMM (Stockholm, Sweden, Aug. 2000). + +\[Strayer 1992\] W. T. Strayer, B. Dempsey, A. Weaver, XTP: The Xpress +Transfer Protocol, Addison-Wesley, Reading, MA, 1992. + +\[Stubblefield 2002\] A. Stubblefield, J. Ioannidis, A. Rubin, "Using +the Fluhrer, Mantin, and Shamir Attack to Break WEP," Proceedings of +2002 Network and Distributed Systems Security Symposium (2002), +pp. 17--22. + +\[Subramanian 2000\] M. Subramanian, Network Management: Principles and +Practice, Addison-Wesley, Reading, MA, 2000. + +\[Subramanian 2002\] L. Subramanian, S. Agarwal, J. Rexford, R. Katz, +"Characterizing the Internet Hierarchy from Multiple Vantage Points," +Proc. 2002 IEEE INFOCOM. + +\[Sundaresan 2006\] K.Sundaresan, K. Papagiannaki, "The Need for +Cross-layer Information in Access Point Selection," Proc. 2006 ACM +Internet Measurement Conference (Rio De Janeiro, Oct. 2006). + + \[Suh 2006\] K. Suh, D. R. Figueiredo, J. Kurose and D. Towsley, +"Characterizing and Detecting Relayed Traffic: A Case Study Using +Skype," Proc. 2006 IEEE INFOCOM (Barcelona, Spain, Apr. 2006). + +\[Sunshine 1978\] C. Sunshine, Y. Dalal, "Connection Management in +Transport Protocols," Computer Networks, North-Holland, Amsterdam, 1978. + +\[Tariq 2008\] M. Tariq, A. Zeitoun, V. Valancius, N. Feamster, M. +Ammar, "Answering What-If Deployment and Configuration Questions with +WISE," Proc. 2008 ACM SIGCOMM (Aug. 2008). + +\[TechnOnLine 2012\] TechOnLine, "Protected Wireless Networks," online +webcast tutorial, +http://www.techonline.com/community/tech_topic/internet/21752 + +\[Teixeira 2006\] R. Teixeira, J. Rexford, "Managing Routing Disruptions +in Internet Service Provider Networks," IEEE Communications Magazine +(Mar. 2006). + +\[Think 2012\] Technical History of Network Protocols, "Cyclades," +http://www.cs.utexas.edu/users/chris/think/Cyclades/index.shtml + +\[Tian 2012\] Y. Tian, R. Dey, Y. Liu, K. W. Ross, "China's Internet: +Topology Mapping and Geolocating," IEEE INFOCOM Mini-Conference 2012 +(Orlando, FL, 2012). + +\[TLD list 2016\] TLD list maintained by Wikipedia, +https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains + +\[Tobagi 1990\] F. Tobagi, "Fast Packet Switch Architectures for +Broadband Integrated Networks," Proc. 1990 IEEE INFOCOM, Vol. 78, No. 1 +(Jan. 1990), pp. 133--167. + +\[TOR 2016\] Tor: Anonymity Online, http://www.torproject.org + +\[Torres 2011\] R. Torres, A. Finamore, J. R. Kim, M. M. Munafo, S. Rao, +"Dissecting Video Server Selection Strategies in the YouTube CDN," Proc. +2011 Int. Conf. on Distributed Computing Systems. + +\[Tourrilhes 2014\] J. Tourrilhes, P. Sharma, S. Banerjee, J. Petit, +"SDN and Openflow Evolution: A Standards Perspective," IEEE Computer +Magazine, Nov. 2014, pp. 22--29. + +\[Turner 1988\] J. S. Turner, "Design of a Broadcast packet switching +network," IEEE Transactions on Communications, Vol. 36, No. 6 (June +1988), pp. 734--743. + +\[Turner 2012\] B. Turner, "2G, 3G, 4G Wireless Tutorial," +http://blogs.nmscommunications.com/communications/2008/10/2g-3g-4g-wireless-tutorial.html + + \[UPnP Forum 2016\] UPnP Forum homepage, http://www.upnp.org/ + +\[van der Berg 2008\] R. van der Berg, "How the 'Net Works: An +Introduction to Peering and Transit," +http://arstechnica.com/guides/other/peering-and-transit.ars + +\[van der Merwe 1998\] J. van der Merwe, S. Rooney, I. Leslie, S. +Crosby, "The Tempest: A Practical Framework for Network +Programmability," IEEE Network, Vol. 12, No. 3 (May 1998), pp. 20--28. + +\[Varghese 1997\] G. Varghese, A. Lauck, "Hashed and Hierarchical Timing +Wheels: Efficient Data Structures for Implementing a Timer Facility," +IEEE/ACM Transactions on Networking, Vol. 5, No. 6 (Dec. 1997), +pp. 824--834. + +\[Vasudevan 2012\] S. Vasudevan, C. Diot, J. Kurose, D. Towsley, +"Facilitating Access Point Selection in IEEE 802.11 Wireless Networks," +Proc. 2005 ACM Internet Measurement Conference, (San Francisco CA, +Oct. 2005). + +\[Villamizar 1994\] C. Villamizar, C. Song. "High Performance tcp in +ansnet," ACM SIGCOMM Computer Communications Review, Vol. 24, No. 5 +(1994), pp. 45--60. + +\[Viterbi 1995\] A. Viterbi, CDMA: Principles of Spread Spectrum +Communication, Addison-Wesley, Reading, MA, 1995. + +\[Vixie 2009\] P. Vixie, "What DNS Is Not," Communications of the ACM, +Vol. 52, No. 12 (Dec. 2009), pp. 43--47. + +\[Wakeman 1992\] I. Wakeman, J. Crowcroft, Z. Wang, D. Sirovica, +"Layering Considered Harmful," IEEE Network (Jan. 1992), pp. 20--24. + +\[Waldrop 2007\] M. Waldrop, "Data Center in a Box," Scientific American +(July 2007). + +\[Wang 2004\] B. Wang, J. Kurose, P. Shenoy, D. Towsley, "Multimedia +Streaming via TCP: An Analytic Performance Study," Proc. 2004 ACM +Multimedia Conference (New York, NY, Oct. 2004). + +\[Wang 2008\] B. Wang, J. Kurose, P. Shenoy, D. Towsley, "Multimedia +Streaming via TCP: An Analytic Performance Study," ACM Transactions on +Multimedia Computing Communications and Applications (TOMCCAP), Vol. 4, +No. 2 (Apr. 2008), p. 16. 1--22. + +\[Wang 2010\] G. Wang, D. G. Andersen, M. Kaminsky, K. Papagiannaki, T. +S. E. Ng, M. Kozuch, M. Ryan, "c-Through: Part-time Optics in Data +Centers," Proc. 2010 ACM SIGCOMM. + +\[Wei 2006\] W. Wei, C. Zhang, H. Zang, J. Kurose, D. Towsley, +"Inference and Evaluation of Split-Connection Approaches in Cellular +Data Networks," Proc. Active and Passive Measurement Workshop (Adelaide, +Australia, Mar. 2006). + + \[Wei 2007\] D. X. Wei, C. Jin, S. H. Low, S. Hegde, "FAST TCP: +Motivation, Architecture, Algorithms, Performance," IEEE/ACM +Transactions on Networking (2007). + +\[Weiser 1991\] M. Weiser, "The Computer for the Twenty-First Century," +Scientific American (Sept. 1991): 94--10. +http://www.ubiq.com/hypertext/weiser/ SciAmDraft3.html + +\[White 2011\] A. White, K. Snow, A. Matthews, F. Monrose, "Hookt on +fon-iks: Phonotactic Reconstruction of Encrypted VoIP Conversations," +IEEE Symposium on Security and Privacy, Oakland, CA, 2011. + +\[Wigle.net 2016\] Wireless Geographic Logging Engine, +http://www.wigle.net + +\[Wiki Satellite 2016\] Satellite Internet access, +https://en.wikipedia.org/wiki/Satellite_Internet_access + +\[Wireshark 2016\] Wireshark homepage, http://www.wireshark.org + +\[Wischik 2005\] D. Wischik, N. McKeown, "Part I: Buffer Sizes for Core +Routers," ACM SIGCOMM Computer Communications Review, Vol. 35, No. 3 +(July 2005). + +\[Woo 1994\] T. Woo, R. Bindignavle, S. Su, S. Lam, "SNP: an interface +for secure network programming," Proc. 1994 Summer USENIX (Boston, MA, +June 1994), pp. 45--58. + +\[Wright 2015\] J. Wright, J. Wireless Security Secrets & Solutions, 3e, +"Hacking Exposed Wireless," McGraw-Hill Education, 2015. + +\[Wu 2005\] J. Wu, Z. M. Mao, J. Rexford, J. Wang, "Finding a Needle in +a Haystack: Pinpointing Significant BGP Routing Changes in an IP +Network," Proc. USENIX NSDI (2005). + +\[Xanadu 2012\] Xanadu Project homepage, http://www.xanadu.com/ + +\[Xiao 2000\] X. Xiao, A. Hannan, B. Bailey, L. Ni, "Traffic Engineering +with MPLS in the Internet," IEEE Network (Mar./Apr. 2000). + +\[Xu 2004\] L. Xu, K Harfoush, I. Rhee, "Binary Increase Congestion +Control (BIC) for Fast Long-Distance Networks," IEEE INFOCOM 2004, +pp. 2514--2524. + +\[Yavatkar 1994\] R. Yavatkar, N. Bhagwat, "Improving End-to-End +Performance of TCP over Mobile Internetworks," Proc. Mobile 94 Workshop +on Mobile Computing Systems and Applications (Dec. 1994). + + \[YouTube 2009\] YouTube 2009, Google container data center tour, 2009. + +\[YouTube 2016\] YouTube Statistics, 2016, +https://www.youtube.com/yt/press/ statistics.html + +\[Yu 2004\] Yu, Fang, H. Katz, Tirunellai V. Lakshman. "Gigabit Rate +Packet Pattern-Matching Using TCAM," Proc. 2004 Int. Conf. Network +Protocols, pp. 174--183. + +\[Yu 2011\] M. Yu, J. Rexford, X. Sun, S. Rao, N. Feamster, "A Survey of +VLAN Usage in Campus Networks," IEEE Communications Magazine, July 2011. + +\[Zegura 1997\] E. Zegura, K. Calvert, M. Donahoo, "A Quantitative +Comparison of Graph-based Models for Internet Topology," IEEE/ACM +Transactions on Networking, Vol. 5, No. 6, (Dec. 1997). See also +http://www.cc.gatech.edu/projects/gtim for a software package that +generates networks with a transit-stub structure. + +\[Zhang 1993\] L. Zhang, S. Deering, D. Estrin, S. Shenker, D. Zappala, +"RSVP: A New Resource Reservation Protocol," IEEE Network Magazine, Vol. +7, No. 9 (Sept. 1993), pp. 8--18. + +\[Zhang 2007\] L. Zhang, "A Retrospective View of NAT," The IETF +Journal, Vol. 3, Issue 2 (Oct. 2007). + +\[Zhang 2015\] G. Zhang, W. Liu, X. Hei, W. Cheng, "Unreeling Xunlei +Kankan: Understanding Hybrid CDN-P2P Video-on-Demand Streaming," IEEE +Transactions on Multimedia, Vol. 17, No. 2, Feb. 2015. + +\[Zhang X 2102\] X. Zhang, Y. Xu, Y. Liu, Z. Guo, Y. Wang, "Profiling +Skype Video Calls: Rate Control and Video Quality," IEEE INFOCOM +(Mar. 2012). + +\[Zink 2009\] M. Zink, K. Suh, Y. Gu, J. Kurose, "Characteristics of +YouTube Network Traffic at a Campus Network---Measurements, Models, and +Implications," Computer Networks, Vol. 53, No. 4, pp. 501--514, 2009. + + Index + + |