remove outdated material

1 files changed, 0 insertions, 31112 deletions

diff --git a/generated/textbook.md b/generated/textbook.md
deleted file mode 100644
index cfb43cd..0000000
--- a/generated/textbook.md
+++ /dev/null
@@ -1,31112 +0,0 @@
-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. Fig­ure
-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 Fig­ure 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
-
-