Ebook Computer networks: A systems approach (5th edition) – Part 1

Ebook Computer networks: A systems approach (5th edition) – Part 1 presents the following content: Chapter 1 foundation, chapter 2 getting connected, chapter 3 internetworking, chapter 4 advanced internetworking, chapter 5 end-to-end protocols. Please refer to the documentation for more details.

EDELKAMP 19-ch15-671-700-9780123725127 2011/5/28 14:50 Page 672 #2 This page intentionally left blank PETERSON-AND-DAVIE 01-pra-i-ii-9780123850591 2011/3/5 0:50 Page i #1 In Praise of Computer Networks: A Systems Approach Fifth Edition I have known and used this book for years and I always found it very valuable as a textbook for teaching computer networks as well as a reference book for networking professionals This Fifth Edition maintains the core value of former editions and brings the clarity of explanation of network protocols in the introduction of the most up-to-date techniques, technologies and requirements of networking Beyond describing the details of past and current networks, this book successfully motivates the curiosity, and hopefully new research, for the networks of the future Stefano Basagni Northeastern University Peterson and Davie have written an outstanding book for the computer networking world It is a well-organized book that features a very helpful “big picture” systems approach This book is a must have! Yonshik Choi Illinois Institute of Technology The Fifth Edition of Computer Networks: A Systems Approach is wellsuited for the serious student of computer networks, though it remains accessible to the more casual reader as well The authors’ enthusiasm for their subject is evident throughout; they have a thorough and current grasp of the interesting problems of the field They explain not only how various protocols work, but also why they work the way they do, and even why certain protocols are the important and interesting ones The book is also filled with little touches of historical background, from the main text to the “Where Are They Now” sidebars to the papers described in each chapter’s “Further Reading” section—these give the reader a perspective on how things came to be the way they are All in all, this book provides a lucid and literate introduction to networking Peter Dordal Loyola University Chicago I have used Computer Networks: A Systems Approach for over five years in an introductory course on communications networks aimed at upper-level undergraduates and first-year Masters students I have gone through several editions and over the years the book has kept what from the beginning PETERSON-AND-DAVIE 01-pra-i-ii-9780123850591 2011/3/5 0:50 Page ii #2 had been its main strength, namely, that it not only describes the ‘how,’ but also the ‘why’ and equally important, the ‘why not’ of things It is a book that builds engineering intuition, and in this day and age of fast-paced technology changes, this is critical to develop a student’s ability to make informed decisions on how to design or select the next generation systems Roch Guerin University of Pennsylvania This book is an outstanding introduction to computer networks that is clear, comprehensive, and chock-full of examples Peterson and Davie have a gift for boiling networking down to simple and manageable concepts without compromising technical rigor Computer Networks: A Systems Approach strikes an excellent balance between the principles underlying network architecture design and the applications built on top It should prove invaluable to students and teachers of advanced undergraduate and graduate networking courses Arvind Krishnamurthy University of Washington Computer Networks: A Systems Approach has always been one of the best resources available to gain an in-depth understanding of computer networks The latest edition covers recent developments in the field Starting with an overview in Chapter 1, the authors systematically explain the basic building blocks of networks Both hardware and software concepts are presented The material is capped with a final chapter on applications, which brings all the concepts together Optional advanced topics are placed in a separate chapter The textbook also contains a set of exercises of varying difficulty at the end of each chapter which ensure that the students have mastered the material presented Karkal Prabhu Drexel University Peterson and Davie provide a detailed yet clear description of the Internet protocols at all layers Students will find many study aids that will help them gain a full understanding of the technology that is transforming our society The book gets better with each edition Jean Walrand University of California at Berkeley PETERSON-AND-DAVIE 02-fm-iii-vi-9780123850591 2011/3/5 0:52 Page #1 Fifth Edition Computer Networks a systems approach PETERSON-AND-DAVIE 02-fm-iii-vi-9780123850591 2011/2/27 15:21 Page iv Recommended Reading List For students interested in furthering their understanding of Computer Networking, the content in the following books supplements this textbook: Network Analysis, Architecture, and Design, 3rd Edition By James D McCabe ISBN: 9780123704801 The Illustrated Network How TCP/IP Works in a Modern Network By Walter Goralski ISBN: 9780123745415 Interconnecting Smart Objects with IP The Next Internet By Jean-Philippe Vasseur and Adam Dunkels ISBN: 9780123751652 Network Quality of Service Know It All Edited by Adrian Farrel ISBN: 9780123745972 Optical Networks, 3rd Edition A Practical Perspective By Rajiv Ramaswami, Kumar Sivarajan and Galen Sasaki ISBN: 9780123740922 Broadband Cable Access Networks The HFC Plant By David Large and James Farmer ISBN: 9780123744012 Deploying QoS for Cisco IP and Next Generation Networks The Definitive Guide By Vinod Joseph and Brett Chapman ISBN: 9780123744616 mkp.com #2 PETERSON-AND-DAVIE 02-fm-iii-vi-9780123850591 2011/2/27 15:21 Page v #3 Fifth Edition Computer Networks a systems approach Larry L Peterson and Bruce S Davie AMSTERDAM • BOSTON • HEIDELBERG • LONDON NEW YORK • OXFORD • PARIS • SAN DIEGO SAN FRANCISCO • SINGAPORE • SYDNEY • TOKYO Morgan Kaufmann Publishers is an imprint of Elsevier PETERSON-AND-DAVIE 02-fm-iii-vi-9780123850591 2011/2/27 15:21 Page vi #4 Acquiring Editor: Rick Adams Development Editor: Nate McFadden Project Manager: Paul Gottehrer Designer: Dennis Schaefer Morgan Kaufmann is an imprint of Elsevier 30 Corporate Drive, Suite 400, Burlington, MA 01803, USA © 2012 Elsevier, Inc All rights reserved No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or any information storage and retrieval system, without permission in writing from the publisher Details on how to seek permission, further information about the Publisher’s permissions policies and our arrangements with organizations such as the Copyright Clearance Center and the Copyright Licensing Agency, can be found at our website: www.elsevier.com/permissions This book and the individual contributions contained in it are protected under copyright by the Publisher (other than as may be noted herein) Notices Knowledge and best practice in this field are constantly changing As new research and experience broaden our understanding, changes in research methods or professional practices, may become necessary Practitioners and researchers must always rely on their own experience and knowledge in evaluating and using any information or methods described herein In using such information or methods they should be mindful of their own safety and the safety of others, including parties for whom they have a professional responsibility To the fullest extent of the law, neither the Publisher nor the authors, contributors, or editors, assume any liability for any injury and/or damage to persons or property as a matter of products liability, negligence or otherwise, or from any use or operation of any methods, products, instructions, or ideas contained in the material herein Library of Congress Cataloging-in-Publication Data Peterson, Larry L Computer networks : a systems approach / Larry L Peterson and Bruce S Davie – 5th ed p cm – (The Morgan Kaufmann series in networking) Includes bibliographical references ISBN 978-0-12-385059-1 (hardback) Computer networks I Davie, Bruce S II Title TK5105.5.P479 2011 004.6–dc22 2011000786 British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library ISBN: 978-0-12-385059-1 For information on all Morgan Kaufmann publications visit our website at www.mkp.com Typeset by: diacriTech, India Printed in the United States of America 11 12 13 14 15 16 10 PETERSON-AND-DAVIE 03-ded-vii-viii-9780123850591 2011/3/5 To Lee Peterson and Robert Davie 0:55 Page vii #1 EDELKAMP 19-ch15-671-700-9780123725127 2011/5/28 14:50 Page 672 #2 This page intentionally left blank PETERSON-AND-DAVIE 04-fore-ix-xii-9780123850591 2011/2/25 15:10 Page ix #1 Foreword O nce again, this now-classic textbook has been revised to keep it up-to-date with our evolving field While the Internet and its protocols now dominate networking everywhere, we see continued evolution in the technology used to support the Internet, with switching at “layer 2” providing rich functionality and powerful tools for network management The previous edition dealt with switching and routing in two chapters, but a presentation based on layers is not always the best way to convey the essentials of the material, since what we call switching and routing actually play similar and complementary roles This edition of the book looks at these topics in an integrated way, which brings out their functional similarities and differences More advanced topics in routing have been moved to a second chapter that can be skipped, depending on the emphasis and level of the class I have never been a fan of teaching networking based on a purely layered approach, as my foreword to the first edition indicated (we’ve reprinted it in this edition just for fun.) Some key issues in networking, including security and performance, cannot be solved by assigning them to one layer—there cannot be a “performance” layer These sorts of topics are both critical and cross-cutting, and the organization of this book continues to treat topics, as well as layers The organization of this book reflects a great deal of experience using it as a classroom textbook, and as well a preference for an approach that brings out fundamentals as well as current practice Some moribund technologies are now missing or minimized, including token ring (one of my old favorites, but clearly it was time to go) and ATM This edition recognizes that we need to pay more attention to application design, and not just packet forwarding Wireless and mobility gets more attention as well The authors, once again, have worked hard to produce a revision that conveys the essentials of the field in a way that is pedagogically effective I am pleased to say that I think it is better than ever David Clark November, 2010 ix PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 464 Page 464 #75 CHAPTER End-to-end protocols send back an ICMP Port Unreachable message to A Like all ICMP messages, this is addressed to A as a whole, not to port P on A (a) Give an example of when an application might want to receive such ICMP messages (b) Find out what an application has to do, on the operating system of your choice, to receive such messages (c) Why might it not be a good idea to send such messages directly back to the originating port P on A? Consider a simple UDP-based protocol for requesting files (based somewhat loosely on the Trivial File Transport Protocol, or TFTP) The client sends an initial file request, and the server answers (if the file can be sent) with the first data packet Client and server then continue with a stop-and-wait transmission mechanism (a) Describe a scenario by which a client might request one file but get another; you may allow the client application to exit abruptly and be restarted with the same port (b) Propose a change in the protocol that will make this situation much less likely Design a simple UDP-based protocol for retrieving files from a server No authentication is to be provided Stop-and-wait transmission of the data may be used Your protocol should address the following issues: (a) Duplication of the first packet should not duplicate the “connection.” (b) Loss of the final ACK should not necessarily leave the server in doubt as to whether the transfer succeeded (c) A late-arriving packet from a past connection shouldn’t be interpretable as part of a current connection This chapter explains three sequences of state transitions during TCP connection teardown There is a fourth possible sequence, which traverses an additional arc (not shown in Figure 5.7) from FIN WAIT to TIME WAIT and labelled FIN + ACK/ACK Explain the circumstances that result in this fourth teardown sequence When closing a TCP connection, why is the two-segment-lifetime timeout not necessary on the transition from LAST ACK to CLOSED? PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 465 #76 Exercises A sender on a TCP connection that receives a advertised window periodically probes the receiver to discover when the window becomes nonzero Why would the receiver need an extra timer if it were responsible for reporting that its advertised window had become nonzero (i.e., if the sender did not probe)? Read the man page (or Windows equivalent) for the Unix/ Windows utility netstat Use netstat to see the state of the local TCP connections Find out how long closing connections spend in TIME WAIT The sequence number field in the TCP header is 32 bits long, which is big enough to cover over billion bytes of data Even if this many bytes were never transferred over a single connection, why might the sequence number still wrap around from 232 − to 0? You are hired to design a reliable byte-stream protocol that uses a sliding window (like TCP) This protocol will run over a 1-Gbps network The RTT of the network is 100 ms, and the maximum segment lifetime is 30 seconds (a) How many bits would you include in the AdvertisedWindow and SequenceNum fields of your protocol header? (b) How would you determine the numbers given above, and which values might be less certain? 10 You are hired to design a reliable byte-stream protocol that uses a sliding window (like TCP) This protocol will run over a 1-Gbps network The RTT of the network is 140 ms, and the maximum segment lifetime is 60 seconds How many bits would you include in the AdvertisedWindow and SequenceNum fields of your protocol header? 11 Suppose a host wants to establish the reliability of a link by sending packets and measuring the percentage that is received; routers, for example, this Explain the difficulty doing this over a TCP connection 12 Suppose TCP operates over a 1-Gbps link (a) Assuming TCP could utilize the full bandwidth continuously, how long would it take the sequence numbers to wrap around completely? 465 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 466 Page 466 #77 CHAPTER End-to-end protocols (b) Suppose an added 32-bit timestamp field increments 1000 times during the wraparound time you found above How long would it take for the timestamp to wrap around? 13 Suppose TCP operates over a 40-Gbps STS-768 link (a) Assuming TCP could utilize the full bandwidth continuously, how long would it take the sequence numbers to wrap around completely? (b) Suppose an added 32-bit timestamp field which increments 1000 times during the wraparound time you found above How long would it take for the timestamp to wrap around? 14 If host A receives two SYN packets from the same port from remote host B, the second may be either a retransmission of the original or, if B has crashed and rebooted, an entirely new connection request (a) Describe the difference as seen by host A between these two cases (b) Give an algorithmic description of what the TCP layer needs to upon receiving a SYN packet Consider the duplicate/ new cases above and the possibility that nothing is listening to the destination port 15 Suppose x and y are two TCP sequence numbers Write a function to determine whether x comes before y (in the notation of Request for Comments 793, “x =< y”) or after y; your solution should work even when sequence numbers wrap around 16 Suppose an idle TCP connection exists between sockets A and B A third party has eavesdropped and knows the current sequence number at both ends (a) Suppose the third party sends A a forged packet ostensibly from B and with 100 bytes of new data What happens? (Hint: Look up in Request for Comments 793 what TCP does when it receives an ACK that is not an “acceptable ACK.”) (b) Suppose the third party sends each end such a forged 100-byte data packet ostensibly from the other end What happens now? What would happen if A later sent 200 bytes of data to B? 17 Suppose party A connects to the Internet via a wireless network using DHCP to assign IP addresses A opens several Telnet PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 467 #78 Exercises connections (using TCP) and is then disconnected from the wireless network Party B then connects and is assigned the same IP address that A had had Assuming B were able to guess to what host(s) A had been connected, describe a sequence of probes that could enable B to obtain sufficient state information to continue with A’s connections 18 Diagnostic programs are commonly available that record the first 100 bytes, say, of every TCP connection to a certain host, port Outline what must be done with each received TCP packet, P, in order to determine if it contains data that belongs to the first 100 bytes of a connection to host HOST, port PORT Assume the IP header is P.IPHEAD, the TCP header is P.TCPHEAD, and header fields are as named in Figures 3.16 and 5.4 (Hint: To get initial sequence numbers (ISNs) you will have to examine every packet with the SYN bit set Ignore the fact that sequence numbers will eventually be reused.) 19 If a packet arrives at host A with B’s source address, it could just as easily have been forged by any third host C If, however, A accepts a TCP connection from B, then during the three-way handshake A sent ISNA to B’s address and received an acknowledgment of it If C is not located so as to be able to eavesdrop on ISNA , then it might seem that C could not have forged B’s response However, the algorithm for choosing ISNA does give other unrelated hosts a fair chance of guessing it Specifically, A selects ISNA based on a clock value at the time of connection Request for Comments 793 specifies that this clock value be incremented every µs; common Berkeley implementations once simplified this to incrementing by 250,000 (or 256,000) once per second (a) Given this simplified increment-once-per-second implementation, explain how an arbitrary host C could masquerade as B in at least the opening of a TCP connection You may assume that B does not respond to SYN + ACK packets A is tricked into sending to it (b) Assuming real RTTs can be estimated to within 40 ms, about how many tries would you expect it to take to implement the strategy of part (a) with the unsimplified “increment every µs” TCP implementation? 467 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 468 Page 468 #79 CHAPTER End-to-end protocols 20 The Nagle algorithm, built into most TCP implementations, requires the sender to hold a partial segment’s worth of data (even if PUSHed) until either a full segment accumulates or the most recent outstanding ACK arrives (a) Suppose the letters abcdefghi are sent, one per second, over a TCP connection with an RTT of 4.1 seconds Draw a timeline indicating when each packet is sent and what it contains (b) If the above were typed over a full-duplex Telnet connection, what would the user see? (c) Suppose that mouse position changes are being sent over the connection Assuming that multiple position changes are sent each RTT, how would a user perceive the mouse motion with and without the Nagle algorithm? 21 Suppose a client C repeatedly connects via TCP to a given port on a server S, and that each time it is C that initiates the close (a) How many TCP connections a second can C make here before it ties up all its available ports in TIME WAIT state? Assume client ephemeral ports are in the range of 1024 to 5119, and that TIME WAIT lasts 60 seconds (b) Berkeley-derived TCP implementations typically allow a socket in TIME WAIT state to be reopened before TIME WAIT expires, if the highest sequence number used by the old incarnation of the connection is less than the ISN used by the new incarnation This solves the problem of old data being accepted as new; however, TIME WAIT also serves the purpose of handling late final FINs What would such an implementation have to to address this and still achieve strict compliance with the TCP requirement that a FIN sent anytime before or during a connection’s TIME WAIT receive the same response? 22 Explain why TIME WAIT is a somewhat more serious problem if the server initiates the close than if the client does Describe a situation in which this might reasonably happen 23 What is the justification for the exponential increase in timeout value proposed by Karn and Partridge? Why, specifically, might a linear (or slower) increase be less desirable? PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 469 #80 Exercises 24 The Jacobson/Karels algorithm sets TimeOut to be mean deviations above the mean Assume that individual packet round-trip times follow a statistical normal distribution, for which mean deviations are π standard deviations Using statistical tables, for example, what is the probability that a packet will take more than TimeOut time to arrive? 25 Suppose a TCP connection, with window size 1, loses every other packet Those that arrive have RTT = second What happens? What happens to TimeOut? Do this for two cases: (a) After a packet is eventually received, we pick up where we left off, resuming with EstimatedRTT initialized to its pre-timeout value, and TimeOut double that (b) After a packet is eventually received, we resume with TimeOut initialized to the last exponentially backed-off value used for the timeout interval In the following four exercises, the calculations involved are straightforward with a spreadsheet 26 Suppose, in TCP’s adaptive retransmission mechanism, that EstimatedRTT is 4.0 seconds at some point and subsequent measured RTT’s all are 1.0 second How long does it take before the TimeOut value, as calculated by the Jacobson/Karels algorithm, falls below 4.0 seconds? Assume a plausible initial value of Deviation; how sensitive is your answer to this choice? Use δ = 1/8 27 Suppose, in TCP’s adaptive retransmission mechanism, that EstimatedRTT is 90 at some point and subsequent measured RTTs are all 200 How long does it take before the TimeOut value, as calculated by the Jacobson/Karels algorithm, falls below 300? Assume initial Deviation value of 25; use δ = 1/8 28 Suppose TCP’s measured RTT is 1.0 second except that every N th RTT is 4.0 seconds What is the largest N , approximately, that doesn’t result in timeouts in the steady state (i.e., for which the Jacobson/Karels TimeOut remains greater than 4.0 seconds)? Use δ = 1/8 29 Suppose that TCP is measuring RTTs of 1.0 second, with a mean deviation of 0.1 second Suddenly the RTT jumps to 5.0 seconds, 469 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 470 Page 470 #81 CHAPTER End-to-end protocols with no deviation Compare the behaviors of the original and Jacobson/Karels algorithms for computing TimeOut Specifically, how many timeouts are encountered with each algorithm? What is the largest TimeOut calculated? Use δ = 1/8 30 Suppose that, when a TCP segment is sent more than once, we take SampleRTT to be the time between the original transmission and the ACK, as in Figure 5.10(a) Show that if a connection with a 1-packet window loses every other packet (i.e., each packet is transmitted twice), then EstimatedRTT increases to infinity Assume TimeOut = EstimatedRTT; both algorithms presented in the text always set TimeOut even larger (Hint: EstimatedRTT = EstimatedRTT + β × (SampleRTT − EstimatedRTT).) 31 Suppose that, when a TCP segment is sent more than once, we take SampleRTT to be the time between the most recent transmission and the ACK, as in Figure 5.10(b) Assume, for definiteness, that TimeOut = × EstimatedRTT Sketch a scenario in which no packets are lost but EstimatedRTT converges to a third of the true RTT, and give a diagram illustrating the final steady state (Hint: Begin with a sudden jump in the true RTT to just over the established TimeOut.) 32 Consult Request for Comments 793 to find out how TCP is supposed to respond if a FIN or an RST arrives with a sequence number other than NextByteExpected Consider both when the sequence number is within the receive window and when it is not 33 One of the purposes of TIME WAIT is to handle the case of a data packet from a first incarnation of a connection arriving very late and being accepted as data for the second incarnation (a) Explain why, for this to happen (in the absence of TIME WAIT), the hosts involved would have to exchange several packets in sequence after the delayed packet was sent but before it was delivered (b) Propose a network scenario that might account for such a late delivery 34 Propose an extension to TCP by which one end of a connection can hand off its end to a third host; that is, if A were connected to B, and A handed off its connection to C, then afterwards C would be connected to B and A would not Specify the new states and PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 471 #82 Exercises transitions needed in the TCP state-transition diagram and any new packet types involved You may assume all parties will understand this new option What state should A go into immediately after the handoff? 35 TCP’s simultaneous open feature is seldom used (a) Propose a change to TCP in which this is disallowed Indicate what changes would be made in the state diagram (and if necessary in the undiagrammed event responses) (b) Could TCP reasonably disallow simultaneous close? (c) Propose a change to TCP in which simultaneous SYNs exchanged by two hosts lead to two separate connections Indicate what state diagram changes this entails and what header changes become necessary Note that this now means that more than one connection can exist over a given pair of host, port s (You might also look up the first “Discussion” item on page 87 of Request for Comments 1122.) 36 TCP is a very symmetric protocol, but the client/server model is not Consider an asymmetric TCP-like protocol in which only the server side is assigned a port number visible to the application layers Client-side sockets would simply be abstractions that can be connected to server ports (a) Propose header data and connection semantics to support this What will you use to replace the client port number? (b) What form does TIME WAIT now take? How would this be seen through the programming interface? Assume that a client socket could now be reconnected arbitrarily many times to a given server port, resources permitting (c) Look up the rsh/rlogin protocol How would the above break this? 37 The following exercise is concerned with the TCP state FIN WAIT (see Figure 5.7) (a) Describe how a client might leave a suitable server in state FIN WAIT indefinitely What feature of the server’s protocol is necessary here for this scenario? (b) Try this with some appropriate existing server Either write a stub client or use an existing Telnet client capable of connecting to an arbitrary port Use the netstat utility to verify that the server is in FIN WAIT state 471 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 472 Page 472 #83 CHAPTER End-to-end protocols 38 Request for Comments 1122 states (of TCP): A host MAY implement a “half-duplex” TCP close sequence, so that an application that has called CLOSE cannot continue to read data from the connection If such a host issues a CLOSE call while received data is still pending in TCP, or if new data is received after CLOSE is called, its TCP SHOULD send an RST to show that data was lost Sketch a scenario involving the above in which data sent by (not to!) the closing host is lost You may assume that the remote host, upon receiving an RST, discards all received data still unread in buffers 39 When TCP sends a SYN, SequenceNum = x or FIN, SequenceNum = x , the consequent ACK has Acknowledgment = x + 1; that is, SYNs and FINs each take up one unit in sequence number space Is this necessary? If so, give an example of an ambiguity that would arise if the corresponding Acknowledgment were x instead of x + 1; if not, explain why 40 Find out the generic format for TCP header options from Request for Comments 793 (a) Outline a strategy that would expand the space available for options beyond the current limit of 44 bytes (b) Suggest an extension to TCP allowing the sender of an option a way of specifying what the receiver should if the option is not understood List several such receiver actions that might be useful, and try to give an example application of each 41 The TCP header does not have a boot ID field Why isn’t there a problem with one end of a TCP connection crashing and rebooting, then sending a message with an ID it had previously used? 42 Suppose we were to implement remote file system mounting using an unreliable RPC protocol that offers zero-or-more semantics If a message reply is received, this improves to at-least-once semantics We define read(n) to return the specified nth block, rather than the next block in sequence; this way, reading once is the same as reading twice and at-least-once semantics is thus the same as exactly once PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 473 #84 Exercises (a) For what other file system operations is there no difference between at-least-once and exactly once semantics? Consider open, create, write, seek, opendir, readdir, mkdir, delete (aka unlink), and rmdir (b) For the remaining operations, which can have their semantics altered to achieve equivalence of at-least-once and exactly once? What file system operations are irreconcilable with at-least-once semantics? (c) Suppose the semantics of the rmdir system call are now that the given directory is removed if it exists, and nothing is done otherwise How could you write a program to delete directories that distinguishes between these two cases? 43 The RPC-based NFS remote file system is sometimes considered to have slower than expected write performance In NFS, a server’s RPC reply to a client write request means that the data is physically written to the server’s disk, not just placed in a queue (a) Explain the bottleneck we might expect, even with infinite bandwidth, if the client sends all its write requests through a single logical channel, and explain why using a pool of channels could help Hint: You will need to know a little about disk controllers (b) Suppose the server’s reply means only that the data has been placed in the disk queue Explain how this could lead to data loss that wouldn’t occur with a local disk Note that a system crash immediately after data was enqueued doesn’t count, because that would cause data loss on a local disk as well (c) An alternative would be for the server to respond immediately to acknowledge the write request and to send its own separate request later to confirm the physical write Propose different RPC semantics to achieve the same effect, but with a single logical request and reply 44 Consider a client and server using an RPC mechanism that includes a channel abstraction and boot IDs (a) Give a scenario involving server reboot in which an RPC request is sent twice by the client and is executed twice by the server, with only a single ACK (b) How might the client become aware this had happened? Would the client be sure it had happened? 473 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 474 Page 474 #85 CHAPTER End-to-end protocols 45 Suppose an RPC request is of the form: “Increment the value of field X of disk block N by 10%.” Specify a mechanism to be used by the executing server to guarantee that an arriving request is executed exactly once, even if the server crashes while in the middle of the operation Assume that individual disk block writes are either complete or else the block is unchanged You may also assume that some designated “undo log” blocks are available Your mechanism should include how the RPC server is to behave at restart 46 Consider a SunRPC client sending a request to a server (a) Under what circumstances can the client be sure its request has executed exactly once? (b) Suppose we wished to add at-most-once semantics to SunRPC What changes would have to be made? Explain why adding one or more fields to the existing headers would not be sufficient 47 Suppose TCP were to be used as the underlying transport in an RPC protocol; each TCP connection is to carry a sequential stream of requests and replies What analog, if any, would TCP have for: (a) Channel ID (b) Message ID (c) Boot ID (d) A message type for requests (e) A message type for replies (f ) A message type for acknowledgments (g) A message type for are-you-alive? messages Which of these would the overlying RPC protocol have to provide? Would some analog of implicit acknowledgments exist? 48 Write a test program that uses the socket interface to send messages between a pair of Unix workstations connected by some LAN (e.g., Ethernet, 802.11) Use this test program to perform the following experiments: (a) Measure the round-trip latency of TCP and UDP for different message sizes (e.g., byte, 100 bytes, 200 bytes , , 1000 bytes) PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 Page 475 #86 Exercises (b) Measure the throughput of TCP and UDP for 1-KB, 2-KB, 3-KB, , 32-KB messages Plot the measured throughput as a function of message size (c) Measure the throughput of TCP by sending MB of data from one host to another Do this in a loop that sends a message of some size—for example, 1024 iterations of a loop that sends 1-KB messages Repeat the experiment with different message sizes and plot the results 49 Try to find situations where an RTP application might reasonably the following: ■ Send multiple packets at essentially the same time that need different timestamps ■ Send packets at different times that need the same timestamp Argue, in consequence, that RTP timestamps must, in at least some cases, be provided (at least indirectly) by the application (Hint: Think of cases where the sending rate and playback rate might not match.) 50 Having the RTP timestamp clock count time in units of one frame time or one voice sample time would be the minimum resolution to ensure accurate playback, but the time unit is usually considerably smaller; what is the purpose of this? 51 Suppose we want returning RTCP reports from receivers to amount to no more than 5% of the outgoing primary RTP stream If each report is 84 bytes, the RTP traffic is 320 kbps, and there are 1000 recipients, how often individual receivers get to report? What if there are 10,000 recipients? 52 RFC 3550 specifies that the time interval between receiver RTCP reports include a randomization factor to avoid having all the receivers sending at the same time If all the receivers sent in the same 5% subinterval of their reply time interval, the arriving upstream RTCP traffic would rival the downstream RTP traffic (a) Video receivers might reasonably wait to send their reports until the higher-priority task of processing and displaying one frame is completed; this might mean their RTCP transmissions were synchronized on frame boundaries Is this likely to be a serious concern? 475 PETERSON-AND-DAVIE 11-ch05-390-477-9780123850591 2011/11/1 18:02 476 Page 476 #87 CHAPTER End-to-end protocols (b) With 10 receivers, what is the probability of their all sending in one particular 5% subinterval? (c) With 10 receivers, what is the probability half will send in one particular 5% subinterval? Multiply this by 20 for an estimate of the probability half will all send in the same arbitrary 5% subinterval (Hint: How many ways can we choose receivers out of 10?) 53 What might a server actually with the packet-loss-rate data and jitter data in receiver reports? 54 Propose a mechanism for deciding when to report an RTP packet as lost How does your mechanism compare with the TCP adaptive retransmission mechanisms of Section 5.2.6? EDELKAMP 19-ch15-671-700-9780123725127 2011/5/28 14:50 Page 672 #2 This page intentionally left blank PETERSON-AND-DAVIE 12-ch06-478-577-9780123850591 2011/11/1 21:50 Page 478 #1 ... Edition A Practical Perspective By Rajiv Ramaswami, Kumar Sivarajan and Galen Sasaki ISBN: 978 012 3740922 Broadband Cable Access Networks The HFC Plant By David Large and James Farmer ISBN: 978 012 3744 012 ... 07-ch 01- 000-069-978 012 38505 91 2 011 /11 /1 9:29 Page #1 PETERSON-AND-DAVIE 07-ch 01- 000-069-978 012 38505 91 2 011 /11 /1 9:29 Page #2 Foundation I must Create a System, or be enslav’d by another Man’s; I will not Reason and... classes of applications PETERSON-AND-DAVIE 07-ch 01- 000-069-978 012 38505 91 2 011 /11 /1 9:29 Page #6 1. 1 Applications A subtly different application class is real-time audio and video These applications