Computer Networks An Open Source Approach 1st Edition Ying-Dar Lin

Visit https://ebookultra.com to download the full version and
explore more ebooks
Computer Networks An Open Source Approach 1st
Edition Ying-Dar Lin
_____ Click the link below to download _____
https://ebookultra.com/download/computer-networks-an-
open-source-approach-1st-edition-ying-dar-lin/
Explore and download more ebooks at ebookultra.com

Here are some suggested products you might be interested in.
Click the link to download
Open source SOA 1st Edition Jeff Davis
https://ebookultra.com/download/open-source-soa-1st-edition-jeff-
davis/
Data Communication and Computer Networks A Business User s
Approach Ninth Edition West
https://ebookultra.com/download/data-communication-and-computer-
networks-a-business-user-s-approach-ninth-edition-west/
Open Source ESBs in Action 1st Edition Tijs Rademakers
https://ebookultra.com/download/open-source-esbs-in-action-1st-
edition-tijs-rademakers/
Open by design the transformation of the cloud through
open source and open governance First Edition Davis
https://ebookultra.com/download/open-by-design-the-transformation-of-
the-cloud-through-open-source-and-open-governance-first-edition-davis/

Open Source Software Implementation and Management 1st
Edition Paul Kavanagh
https://ebookultra.com/download/open-source-software-implementation-
and-management-1st-edition-paul-kavanagh/
Open Source Development with CVS 3rd Edition Moshe Bar
https://ebookultra.com/download/open-source-development-with-cvs-3rd-
edition-moshe-bar/
Open Source Intelligence in a Networked World 1st Edition
Anthony Olcott
https://ebookultra.com/download/open-source-intelligence-in-a-
networked-world-1st-edition-anthony-olcott/
Kansei Engineering and Soft Computing Theory and Practice
Premier Reference Source 1st Edition Ying Dai
https://ebookultra.com/download/kansei-engineering-and-soft-computing-
theory-and-practice-premier-reference-source-1st-edition-ying-dai/
Inter Firm Collaboration Learning and Networks An
Integrated Approach 1st Edition Bart Nooteboom
https://ebookultra.com/download/inter-firm-collaboration-learning-and-
networks-an-integrated-approach-1st-edition-bart-nooteboom/

Computer Networks An Open Source Approach 1st
Edition Ying-Dar Lin Digital Instant Download
Author(s): Ying-Dar Lin, Ren-Hung Hwang, Fred Baker
ISBN(s): 9780073376240, 0073376248
Edition: 1
File Details: PDF, 18.06 MB
Year: 2011
Language: english

This page intentionally left blank

Computer Networks: An
Open Source Approach
lin76248_FM_i-xiv.indd i
lin76248_FM_i-xiv.indd i 24/12/10 6:14 PM
24/12/10 6:14 PM

Computer Networks: An
Open Source Approach
Ying-Dar Lin
National Chiao Tung University
Ren-Hung Hwang
National Chung Cheng University
Fred Baker
Cisco Systems, Inc.
lin76248_FM_i-xiv.indd iii
lin76248_FM_i-xiv.indd iii 24/12/10 6:14 PM
24/12/10 6:14 PM

COMPUTER NETWORKS: AN OPEN SOURCE APPROACH
Published by McGraw-Hill, a business unit of The McGraw-Hill Companies, Inc., 1221 Avenue of the
Americas, New York, NY 10020. Copyright © 2012 by The McGraw-Hill Companies, Inc. All rights
reserved. No part of this publication may be reproduced or distributed in any form or by any means,
or stored in a database or retrieval system, without the prior written consent of The McGraw-Hill
Companies, Inc., including, but not limited to, in any network or other electronic storage or
transmission, or broadcast for distance learning.
Some ancillaries, including electronic and print components, may not be available to customers outside
the United States.
This book is printed on acid-free paper.
1 2 3 4 5 6 7 8 9 0 DOC/DOC 1 0 9 8 7 6 5 4 3 2 1
ISBN 978-0-07-337624-0
MHID 0-07-337624-8
Vice President & Editor-in-Chief: Marty Lange
Vice President EDP/Central Publishing Services: Kimberly Meriwether David
Global Publisher: Raghothaman Srinivasan
Senior Marketing Manager: Curt Reynolds
Development Editor: Lorraine K. Buczek
Senior Project Manager: Jane Mohr
Design Coordinator: Brenda A. Rolwes
Cover Designer: Studio Montage, St. Louis, Missouri
Cover Image: The illustration “Packet Factory” was drafted by Ying-Dar Lin and then drawn by his
12-year-old daughter, Melissa Hou-Yun Lin. It mimics routing and forwarding at the control plane (up
to the 3rd floor) and the data plane (up to the 2nd floor), respectively.
Buyer: Susan K. Culbertson
Media Project Manager: Balaji Sundararaman
Compositor: Glyph International
Typeface: 10/12 Times LT Std
Printer: R. R. Donnelley
All credits appearing on page or at the end of the book are considered to be an extension of the
copyright page.
Library of Congress Cataloging-in-Publication Data
Lin, Ying–Dar.
Computer networks : an open source approach / Ying-Dar Lin, Ren-Hung
Hwang, Fred Baker.
p. cm.
Includes bibliographical references and index.
ISBN-13: 978-0-07-337624-0 (alk. paper)
ISBN-10: 0-07-337624-8 (alk. paper)
1. Computer networks—Management. 2. Computer networks—Computer programs. 3. Open
source software. I. Hwang, Ren-Hung. II. Baker, Fred,
1952- III. Title.
TK5105.5.L55 2011
004.6—dc22
2010047921
www.mhhe.com
lin76248_FM_i-xiv.indd iv
lin76248_FM_i-xiv.indd iv 24/12/10 6:14 PM
24/12/10 6:14 PM

Dedication
Dedicated to Our Sweet Families .... 3 wives and 8 children.
lin76248_FM_i-xiv.indd v
lin76248_FM_i-xiv.indd v 24/12/10 6:14 PM
24/12/10 6:14 PM

About the Authors
Ying-Dar Lin is Professor of Computer Science at National Chiao Tung Univer-
sity (NCTU) in Taiwan. He received his Ph.D. in Computer Science from UCLA
in 1993. He spent his sabbatical year as a visiting scholar at Cisco Systems in San
Jose in 2007–2008. Since 2002, he has been the founder and director of Network
Benchmarking Lab (NBL, www.nbl.org.tw), which reviews network products with
real traffic. He also cofounded L7 Networks Inc. in 2002, which was later acquired
by D-Link Corp. His research interests include design, analysis, implementation,
and benchmarking of network protocols and algorithms, quality of services, network
security, deep packet inspection, P2P networking, and embedded hardware/software
co-design. His work on “multi-hop cellular” has been cited over 500 times. He is
currently on the editorial boards of IEEE Communications Magazine, IEEE Com-
munications Surveys and Tutorials, IEEE Communications Letters, Computer Com-
munications, and Computer Networks.
Ren-Hung Hwang is Research Distinguished Professor of Computer Science as
well as director of Ching-Jiang Learning Center at National Chung Cheng University
in Taiwan. He received his Ph.D. in Computer Science from the University of
Massachusetts, Amherst, in 1993. He has published more than 150 international jour-
nal and conference papers in the computer networking area. His research interests
include ubiquitous computing, P2P networking, next-generation wireless networks,
and e-Learning. He was the program chair of the 10th
International Symposium on
Pervasive Systems, Algorithms, and Networks (I-SPAN) held in KaoHsiung, Taiwan,
2009. He is currently on the editorial board of the Journal of Information Science
and Engineering. He received the Outstanding TeachingAward from National Chung
Cheng University in 2002 and several Outstanding Communication and Network
Courseware Design Awards from the Ministry of Education, Taiwan from 1998
to 2001. He currently also serves as a committee member of the IP Committee of
TWNIC and the Criteria and Procedures Committee of the Institute of Engineering
Education Taiwan (IEET).
Fred Baker has been active in the networking and communications industry since
the late 1970s, working successively for CDC, Vitalink, and ACC. He is currently
a Fellow at Cisco Systems. He was IETF chair from 1996 to 2001. He has chaired
a number of IETF working groups, including Bridge MIB, DS1/DS3 MIB, ISDN
MIB, PPP Extensions, IEPREP, and IPv6 Operations, and served on the Internet
Architecture Board from 1996 to 2002. He has coauthored or edited around 40 RFCs
and contributed to others. The subjects covered include network management,
OSPF and RIPv2 routing, quality of service (using both the Integrated Services and
vi
lin76248_FM_i-xiv.indd vi
lin76248_FM_i-xiv.indd vi 24/12/10 6:14 PM
24/12/10 6:14 PM

About the Authors vii
Differentiated Services models), lawful interception, precedence-based services
on the Internet, and others. In addition, he has served as a member of the Board of
Trustees of the Internet Society 2002–2008, having served as its chair from 2002
through 2006. He is also a former member of the Technical Advisory Council of the
Federal Communications Commission. He currently co-chairs the IPv6 Operations
Working Group in the IETF, and is a member of the Internet Engineering Task Force
Administrative Oversight Committee.
lin76248_FM_i-xiv.indd vii
lin76248_FM_i-xiv.indd vii 24/12/10 6:14 PM
24/12/10 6:14 PM

Brief Contents
Preface xvi
1 Fundamentals 1
2 Physical Layer 54
3 Link Layer 125
4 Internet Protocol Layer 223
5 Transport Layer 339
6 Application Layer 417
7 Internet QoS 546
8 Network Security 590
Appendices:
A Who’s Who 654
B Linux Kernel Overview 669
C Development Tools 683
D Network Utilities 707
Index 723
viii
lin76248_FM_i-xiv.indd viii
lin76248_FM_i-xiv.indd viii 24/12/10 6:14 PM
24/12/10 6:14 PM

ix
Contents
Preface xvii
Chapter 1
Fundamentals 1
1.1 Requirements for Computer Networking 2
1.1.1 Connectivity: Node, Link, Path 2
Historical Evolution: Link Standards 4
Historical Evolution: ATM Faded 6
1.1.2 Scalability: Number of Nodes 6
1.1.3 Resource Sharing 7
Principle in Action: Datacom vs. Telecom 10
1.2 Underlying Principles 10
1.2.1 Performance Measures 10
Principle in Action: Little’s Result 13
1.2.2 Operations at Control Plane 14
1.2.3 Operations at Data Plane 16
1.2.4 Interoperability 20
1.3 The Internet Architecture 21
1.3.1 Solutions to Connectivity 22
Principle in Action: Constantly Challenged
Statelessness 23
1.3.2 Solutions to Scalability 25
1.3.3 Solutions to Resource Sharing 27
1.3.4 Control-Plane and Data-Plane
Operations 29
Principle in Action: Flavors of the Internet
Architecture 31
1.4 Open Source Implementations 32
1.4.1 Open vs. Closed 32
1.4.2 Software Architecture in Linux
Systems 33
1.4.3 Linux Kernel 36
1.4.4 Clients and Daemon Servers 36
1.4.5 Interface Drivers 37
1.4.6 Device Controllers 38
1.5 Book Roadmap: A Packet’s Life 39
1.5.1 Packet Data Structure: sk_buff 39
1.5.2 A Packet’s Life in a Web Server 40
1.5.3 A Packet’s Life in a Gateway 41
Performance Matters: From Socket to Driver
within a Server 42
Performance Matters: From Input Port to
Output Port within a Router 44
Principle in Action: A Packet’s Life in the
Internet 45
1.6 Summary 46
Common Pitfalls 47
Further Readings 48
Frequently Asked Questions 50
Exercises 51
Chapter 2
Physical Layer 54
2.1 General Issues 55
2.1.1 Data and Signal: Analog or Digital 55
Principle in Action: Nyquist Theorem vs.
Shannon Theorem 57
2.1.2 Transmission and Reception Flows 59
2.1.3 Transmission: Line Coding and Digital
Modulation 61
2.1.4 Transmission Impairments 62
Historical Evolution: Software Defined
Radio 63
2.2 Medium 65
2.2.1 Wired Medium 65
2.2.2 Wireless Medium 68
2.3 Information Coding and Baseband
Transmission 70
2.3.1 Source and Channel Coding 71
2.3.2 Line Coding 72
lin76248_FM_i-xiv.indd ix
lin76248_FM_i-xiv.indd ix 24/12/10 6:14 PM
24/12/10 6:14 PM

x Contents
Open Source Implementation 2.1: 8B/10B
Encoder 82
2.4 Digital Modulation and Multiplexing 84
2.4.1 Passband Modulation 84
2.4.2 Multiplexing 92
2.5 Advanced Topics 96
2.5.1 Spread Spectrum 96
2.5.2 Single-Carrier vs. Multiple-Carrier 106
2.5.3 Multiple Inputs, Multiple Outputs
(MIMO) 109
Open Source Implementation 2.2: IEEE
802.11a Transmitter with OFDM 112
Historical Evolution: Cellular Standards 116
Historical Evolution: LTE-Advanced vs. IEEE
802.16m 117
2.6 Summary 118
Common Pitfalls 119
Further Readings 120
Exercises 123
Chapter 3
Link Layer 125
3.1.1 Framing 127
3.1.2 Addressing 129
3.1.3 Error Control and Reliability 130
Principle in Action: CRC or Checksum? 133
Principle in Action: Error Correction
Code 133
Open Source Implementation 3.1:
Checksum 134
Open Source Implementation 3.2: Hardware
CRC-32 135
3.1.4 Flow Control 137
3.1.5 Medium Access Control 138
3.1.6 Bridging 139
3.1.7 Link-Layer Packet Flows 139
Open Source Implementation 3.3: Link-Layer
Packet Flows in Call Graphs 139
3.2 Point-to-Point Protocol 142
3.2.1 High-Level Data Link Control
(HDLC) 143
3.2.2 Point-to-Point Protocol (PPP) 145
3.2.3 Internet Protocol Control Protocol
(IPCP) 147
Open Source Implementation 3.4: PPP
Drivers 148
3.2.4 PPP over Ethernet (PPPoE) 149
3.3 Ethernet (IEEE 802.3) 150
3.3.1 Ethernet Evolution: A Big Picture 150
Historical Evolution: Competitors to
Ethernet 153
3.3.2 The Ethernet MAC 153
CSMA/CD 161
Historical Evolution: Power-Line Networking:
HomePlug 166
3.3.3 Selected Topics in Ethernet 167
Historical Evolution: Backbone Networking:
SONET/SDH and MPLS 169
Historical Evolution: First-Mile Networking:
xDSL and Cable Modem 171
3.4 Wireless Links 171
3.4.1 IEEE 802.11 Wireless LAN 172
Principle in Action: Why Not CSMA/CD in
WLAN? 175
Open Source Implementation 3.6: IEEE 802.11
MAC Simulation with NS-2 177
3.4.2 Bluetooth Technology 182
3.4.3 WiMAX Technology 186
Historical Evolution: Comparing Bluetooth
and IEEE 802.11 187
Historical Evolution: Comparing 3G, LTE, and
WiMAX 190
3.5 Bridging 191
3.5.1 Self-Learning 191
Historical Evolution: Cut-Through vs. Store-
and-Forward 193
Open Source Implementation 3.7: Self-
Learning Bridging 194
3.5.2 Spanning Tree Protocol 196
Open Source Implementation 3.8: Spanning
Tree 198
3.5.3 Virtual LAN 200
Principle in Action: VLAN vs.
Subnet 201
3.6 Device Drivers of a Network Interface 204
3.6.1 Concepts of Device Drivers 204
lin76248_FM_i-xiv.indd x
lin76248_FM_i-xiv.indd x 24/12/10 6:14 PM
24/12/10 6:14 PM

Contents xi
3.6.2 Communicating with Hardware in a Linux
Device Driver 205
Open Source Implementation 3.9: Probing I/O
Ports, Interrupt Handling, and DMA 207
The Network Device Driver in Linux 211
Performance Matters: Interrupt and DMA
Handling within a Driver 214
Historical Evolution: Standard Interfaces for
Drivers 215
3.7 Summary 215
Common Pitfalls 216
Exercises 221
Chapter 4
Internet Protocol Layer 223
4.1.1 Connectivity Issues 224
4.1.2 Scalability Issues 225
Principle in Action: Bridging vs.
Routing 226
4.1.3 Resource Sharing Issues 227
4.1.4 Overview of IP-Layer Protocols and Packet
Flows 228
Open Source Implementation 4.1: IP-Layer
Packet Flows in Call Graphs 229
Performance Matters: Latency within the
IP Layer 230
4.2 Data-Plane Protocols: Internet Protocol 231
4.2.1 Internet Protocol Version 4 232
Open Source Implementation 4.2: IPv4 Packet
Forwarding 238
Performance Matters: Lookup Time at Routing
Cache and Table 241
Open Source Implementation 4.3: IPv4
Checksum in Assembly 244
Open Source Implementation 4.4: IPv4
Fragmentation 246
4.2.2 Network Address Translation (NAT) 248
Principle in Action: Different Types of
NAT 250
Principle in Action: Messy ALG in
NAT 253
NAT 253
Performance Matters: CPU Time of NAT
Execution and Others 258
4.3 Internet Protocol Version 6 259
Historical Evolution: NAT vs. IPv6 259
4.3.1 IPv6 Header Format 260
4.3.2 IPv6 Extension Header 261
4.3.3 Fragmentation in IPv6 262
4.3.4 IPv6 Address Notation 263
4.3.5 IPv6 Address Space Assignment 264
4.3.6 Autoconfiguration 266
4.3.7 Transition from IPv4 to IPv6 266
4.4 Control-Plane Protocols: Address
Management 267
4.4.1 Address Resolution Protocol 268
ARP 269
4.4.2 Dynamic Host Configuration 271
DHCP 275
4.5 Control Plane Protocols: Error
Reporting 277
4.5.1 ICMP Protocol 277
ICMP 280
4.6 Control Plane Protocols: Routing 283
4.6.1 Routing Principles 283
Principle in Action: Optimal Routing 285
4.6.2 Intra-Domain Routing 294
Open Source Implementation 4.9: RIP 297
4.6.3 Inter-Domain Routing 305
OSPF 307
Performance Matters: Computation Overhead
of Routing Daemons 309
Open Source Implementation 4.11: BGP 312
4.7 Multicast Routing 313
4.7.1 Shifting Complexity to Routers 313
4.7.2 Group Membership Management 315
4.7.3 Multicast Routing Protocols 316
Principle in Action: When the Steiner Tree
Differs from the Least-Cost-Path Tree 318
lin76248_FM_i-xiv.indd xi
lin76248_FM_i-xiv.indd xi 24/12/10 6:14 PM
24/12/10 6:14 PM

xii Contents
4.7.4 Inter-Domain Multicast 325
Principle in Action: IP Multicast or Application
Multicast? 326
Mrouted 326
4.8 Summary 328
Common Pitfalls 329
Exercises 335
Chapter 5
Transport Layer 339
5.1.1 Node-to-Node vs. End-to-End 341
5.1.2 Error Control and Reliability 342
5.1.3 Rate Control: Flow Control and Congestion
Control 343
5.1.4 Standard Programming Interfaces 344
5.1.5 Transport-Layer Packet Flows 344
Open Source Implementation 5.1: Transport-
Layer Packet Flows in Call Graphs 344
5.2 Unreliable Connectionless Transfer: UDP 347
5.2.1 Header Format 347
5.2.2 Error Control: Per-Segment
Checksum 348
Open Source Implementation 5.2: UDP and
TCP Checksum 349
5.2.3 Carrying Unicast/Multicast Real-Time
Traffic 350
5.3 Reliable Connection-Oriented Transfer:
TCP 351
5.3.1 Connection Management 351
5.3.2 Reliability of Data Transfers 356
5.3.3 TCP Flow Control 358
Open Source Implementation 5.3: TCP Sliding-
Window Flow Control 362
5.3.4 TCP Congestion Control 363
Historical Evolution: Statistics of TCP
Versions 364
Open Source Implementation 5.4: TCP Slow
Start and Congestion Avoidance 367
Principle in Action: TCP Congestion Control
Behaviors 370
5.3.5 TCP Header Format 371
5.3.6 TCP Timer Management 374
Open Source Implementation 5.5: TCP
Retransmission Timer 375
Open Source Implementation 5.6: TCP Persist
Timer and Keepalive Timer 377
5.3.7 TCP Performance Problems and
Enhancements 378
Historical Evolution: Multiple-Packet-Loss
Recovery in NewReno, SACK, FACK, and
Vegas 385
Principle in Action: TCP for the Networks with
Large Bandwidth-Delay Product 390
5.4 Socket Programming Interfaces 391
5.4.1 Socket 391
5.4.2 Binding Applications through UDP and
TCP 391
Principle in Action: SYN Flooding and
Cookies 394
Open Source Implementation 5.7: Socket Read/
Write Inside Out 394
Performance Matters: Interrupt and Memory
Copy at Socket 397
5.4.3 Bypassing UDP and TCP 399
Open Source Implementation 5.8: Bypassing
the Transport Layer 399
Open Source Implementation 5.9: Making
Myself Promiscuous 401
Open Source Implementation 5.10: Linux
Socket Filter 403
5.5 Transport Protocols for Real-Time
Traffic 404
5.5.1 Real-Time Requirements 404
Principle in Action: Streaming: TCP or
UDP? 406
5.5.2 Standard Data-Plane Protocol:
RTP 407
5.5.3 Standard Control-Plane Protocol:
RTCP 408
Historical Evolution: RTP Implementation
Resources 409
5.6 Summary 410
Common Pitfalls 410
Exercises 413
lin76248_FM_i-xiv.indd xii
lin76248_FM_i-xiv.indd xii 24/12/10 6:14 PM
24/12/10 6:14 PM

Contents xiii
Chapter 6
Application Layer 417
Historical Evolution: Mobile Applications 419
6.1.1 How Ports Work 420
6.1.2 How Servers Start 421
6.1.3 Classification of Servers 421
Historical Evolution: Cloud Computing 426
6.1.4 Characteristics of Application Layer
Protocols 426
6.2 Domain Name System (DNS) 427
6.2.1 Introduction 427
6.2.2 Domain Name Space 428
6.2.3 Resource Records 430
6.2.4 Name Resolution 433
Historical Evolution: Root DNS Servers
Worldwide 434
Open Source Implementation 6.1: BIND 437
6.3 Electronic Mail (E-Mail) 440
6.3.2 Internet Message Standards 442
6.3.3 Internet Mail Protocols 447
Historical Evolution: Web-Based Mail vs.
Desktop Mail 453
Open Source Implementation 6.2: qmail 454
6.4 World Wide Web (WWW) 459
6.4.2 Web Naming and Addressing 460
6.4.3 HTML and XML 463
6.4.4 HTTP 464
Principle in Action: Non-WWW Traffic Over
Port 80 or HTTP 466
Historical Evolution: Google Applications 467
6.4.5 Web Caching and Proxying 468
Open Source Implementation 6.3: Apache 470
Performance Matters: Throughput and
Latency of a Web Server 473
6.5 File Transfer Protocol (FTP) 475
6.5.2 The Two-Connection Operation Model:
Out-of-Band Signaling 477
Historical Evolution: Why Out-of-Band
Signaling in FTP? 478
6.5.3 FTP Protocol Messages 479
wu-ftpd 482
6.6 Simple Network Management Protocol
(SNMP) 485
6.6.2 Architectural Framework 486
6.6.3 Management Information Base (MIB) 487
6.6.4 Basic Operations in SNMP 491
Net-SNMP 493
6.7 Voice over IP (VoIP) 496
Historical Evolution: Proprietary VoIP
Services—Skype and MSN 498
6.7.2 H.323 498
6.7.3 Session Initialization Protocol (SIP) 501
Historical Evolution: H.323 vs. SIP 504
Asterisk 505
6.8 Streaming 510
6.8.2 Compression Algorithms 511
6.8.3 Streaming Protocols 512
Historical Evolution: Streaming with Real
Player, Media Player, QuickTime, and
YouTube 514
6.8.4 QoS and Synchronization
Mechanisms 515
Open Source Implementation 6.7: Darwin
Streaming Server 516
6.9 Peer-to-Peer Applications (P2P) 520
Historical Evolution: Popular P2P
Applications 522
Historical Evolution: Web 2.0 Social
Networking: Facebook, Plurk, and Twitter 523
6.9.2 P2P Architectures 524
6.9.3 Performance Issues of P2P
Applications 529
6.9.4 Case Study: BitTorrent 531
BitTorrent 533
6.10 Summary 539
Common Pitfalls 540
lin76248_FM_i-xiv.indd xiii
lin76248_FM_i-xiv.indd xiii 24/12/10 6:14 PM
24/12/10 6:14 PM

xiv Contents
Exercises 544
Chapter 7
Internet QoS 546
Historical Evolution: The QoS Hype
around 2000s 547
7.1.1 Signaling Protocol 549
7.1.2 QoS Routing 549
7.1.3 Admission Control 549
7.1.4 Packet Classification 549
7.1.5 Policing 550
7.1.6 Scheduling 550
Open Source Implementation 7.1: Traffic
Control Elements in Linux 551
7.2 QoS Architectures 553
7.2.1 Integrated Services (IntServ) 553
7.2.2 Differentiated Services (DiffServ) 556
Principle in Action: Why Both DiffServ and
IntServ Failed 563
Principle in Action: QoS in Wireless Links 563
7.3 Algorithms for QoS Components 564
7.3.1 Admission Control 564
Open Source Implementation 7.2: Traffic
Estimator 566
7.3.2 Flow Identification 568
Open Source Implementation 7.3: Flow
Identification 568
7.3.3 Token Bucket 570
Open Source Implementation 7.4: Token
Bucket 571
7.3.4 Packet Scheduling 574
Open Source Implementation 7.5: Packet
Scheduling 578
7.3.5 Packet Discarding 581
Open Source Implementation 7.6: Random
Early Detection (RED) 583
Principle in Action: QoS Components in Daily
Usage Today 585
7.4 Summary 586
Common Pitfalls 586
Exercises 588
Chapter 8
Network Security 590
8.1.1 Data Security 591
8.1.2 Access Security 593
8.1.3 System Security 593
8.2 Data Security 594
8.2.1 Principles of Cryptography 595
Open Source Implementation 8.1: Hardware
3DES 598
Principle in Action: Secure Wireless
Channels 604
8.2.2 Digital Signature and Message
Authentication 604
Open Source Implementation 8.2: MD5 606
8.2.3 Link Layer Tunneling 609
8.2.4 IP Security (IPSec) 609
Open Source Implementation 8.3: AH and ESP
in IPSec 612
8.2.5 Transport Layer Security 614
Historical Evolution: HTTP Secure (HTTPS)
and Secure Shell (SSH) 616
8.2.6 Comparison on VPNs 618
8.3 Access Security 618
8.3.2 Network/Transport Layer Firewall 619
Open Source Implementation 8.4: Netfilter and
iptables 621
8.3.3 Application Layer Firewall 623
Open Source Implementation 8.5: FireWall
Toolkit (FWTK) 624
Principle in Action: Wireless Access
Control 627
8.4 System Security 627
8.4.1 Information Gathering 628
8.4.2 Vulnerability Exploiting 629
8.4.3 Malicious Code 632
ClamAV 634
8.4.4 Typical Defenses 637
Principle in Action: Bottleneck in IDS 639
lin76248_FM_i-xiv.indd xiv
lin76248_FM_i-xiv.indd xiv 24/12/10 6:14 PM
24/12/10 6:14 PM

Contents xv
Principle in Action: Wireless Intrusions 640
Open Source Implementation 8.7: Snort 640
SpamAssassin 645
Performance Matters: Comparing Intrusion
Detection, Antivirus, Anti-Spam, Content
Filtering, and P2P Classification 647
8.5 Summary 649
Common Pitfalls 649
Exercises 652
Appendices
A Who’s Who 654
A.1 IETF: Defining RFCs 655
A.1.1 IETF History 655
Historical Evolution: Who’s Who in IETF 656
A.1.2 The RFC Process 657
A.1.3 The RFC Statistics 658
A.2 Open Source Communities 660
A.2.1 Beginning and Rules of the Game 660
A.2.2 Open Source Resources 661
A.2.3 Websites for Open Source 663
A.2.4 Events and People 664
A.3 Research and Other Standards
Communities 665
A.4 History 666
B Linux Kernel Overview 669
B.1 Kernel Source Tree 670
B.2 Source Code for Networking 674
B.3 Tools for Source Code Tracing 677
Example: Trace of Reassembly of IPv4
Fragments 677
C Development Tools 683
C.1 Programming 684
C.1.1 Text Editor – vim and gedit 684
C.1.2 Compiler – gcc 685
C.1.3 Auto-Compile – make 688
C.2 Debugging 689
C.2.1 Debugger – gdb 689
C.2.2 GUI Debugger – ddd 690
C.2.3 Kernel Debugger – kgdb 693
C.3 Maintaining 694
C.3.1 Source Code Browser – cscope 694
C.3.2 Version Control – Git 696
C.4 Profiling 699
C.4.1 Profiler – gprof 700
C.4.2 Kernel Profiler – kernprof 701
C.5 Embedding 702
C.5.1 Tiny Utilities – busybox 703
C.5.2 Embedding Development – uClibc and
buildroot 704
D Network Utilities 707
D.1 Name-Addressing 707
D.1.1 Internet’s Who-Is-Who –
host 708
D.1.2 LAN’s Who-Is-Who – arp 708
D.1.3 Who Am I – ifconfig 709
D.2 Perimeter-Probing 710
D.2.1 Ping for Living – ping 711
D.2.2 Find the Way – tracepath 711
D.3 Traffic-Monitoring 713
D.3.1 Dump Raw Data – tcpdump 713
D.3.2 GUI Sniffer – Wireshark 714
D.3.3 Collect Network Statistics –
netstat 714
D.4 Benchmarking 716
D.4.1 Host-to-Host Throughput – ttcp 716
D.5 Simulation and Emulation 717
D.5.1 Simulate the Network – ns 717
D.5.2 Emulate the Network – NIST Net 718
D.6 Hacking 720
D.6.1 Exploit Scanning – Nessus 720
Index 723
lin76248_FM_i-xiv.indd xv
lin76248_FM_i-xiv.indd xv 24/12/10 6:14 PM
24/12/10 6:14 PM

Preface
TRENDS IN NETWORKING COURSES
Technologies in computer networks have gone through many generations of evolution;
many failed or faded away, some prevailed, and some are emerging today. The Internet
technologies driven by TCP/IP currently dominate. Thus, a clear trend in organizing
the content of courses in computer networks is to center around TCP/IP, adding some
lower-layer link technologies and many upper-layer applications, while eliminating
details about the faded technologies, and perhaps explaining why they faded away.
Textbooks on computer networking have also gone through several iterations
of evolution, from traditional, and sometimes dry, protocol descriptions to the appli-
cation-driven, top-down approach and the system-aspect approach. One trend is to
explain more of the why, in addition to the how, for protocol behaviors so that readers
can better appreciate various protocol designs. The evolution, however, shall continue.
GAP BETWEEN DESIGN AND IMPLEMENTATION
Another less clear trend is to add practical flavors to the protocol descriptions. Read-
ers of other textbooks might not know where and how the protocol designs could
be implemented. The net result is that when they do their research in the graduate
schools they tend to simulate their designs for performance evaluation, instead of
real implementation with real benchmarking. When they join the industry, they need
to start from scratch to learn the implementation environment, skills, and issues. Ap-
parently there is a gap between knowledge and skills for students trained by these
textbooks. This gap could be bridged with live running codes easily accessible from
the open source community.
AN OPEN SOURCE APPROACH
Almost all protocols in use today have implementations in the Linux operating sys-
tem and in many open source packages. The Linux and open source communities
have grown, and their applications predominate in the networking world. However,
the abundant resources available there are not yet leveraged by the regular textbooks
in computer science, and more specifically in computer networks. We envision a
trend in textbooks for several courses that could leverage open source resources to
narrow the gap between domain knowledge and hands-on skills. These courses in-
clude Operating Systems (with Linux kernel implementations as examples of process
xvii
lin76248_FM_i-xiv.indd xvii
lin76248_FM_i-xiv.indd xvii 24/12/10 6:14 PM
24/12/10 6:14 PM

xviii Preface
management, memory management, file system management, I/O management,
etc.), Computer Organizations (with verilog codes in www.opencores.org as ex-
amples of processors, memory units, I/O device controllers, etc.), Algorithms (with
GNU libraries as examples of classical algorithms), and Computer Networks (with
open source codes as examples of protocol implementations). This text might prove
to be an early example of this trend.
Our open source approach bridges the gap by interleaving the descriptions of
protocol behaviors with vivid sample implementations extracted from open source
packages. These examples are explicitly numbered with, say, Open Source Imple-
mentation 3.4. The source sites from which complete live examples can be down-
loaded are referred to in the text, so students can access them on the Internet easily.
For example, immediately after explaining the concept of longest prefix matching in
routing table lookup, we illustrate how the routing table is organized (as an ordered
array of hash tables according to prefix lengths) and how this matching is imple-
mented (as the first matching, since the matching process starts from the hash table
with the longest prefixes) in the Linux kernel. This enables instructors to lecture on
the design of routing table lookup and its implementation, and give sound hands-on
projects to, for example, profile the bottleneck of routing table lookup or modify
hash table implementation. We argue that this interleaving approach is better than
a separating approach with a second course or text. It benefits the average students
most because it ties together design and implementation, and the majority of students
would not need a second course. With other textbooks, instructors, teaching assis-
tants, and students have to make an extra effort to bridge this gap that has long been
ignored, or in most cases, simply left untouched.
The protocol descriptions in this text are interleaved with 56 representative open
source implementations, ranging from the Verilog or VHDL code of codec, modem,
CRC32, CSMA/CD, and crypto, to the C code of adaptor driver, PPP daemon and
driver, longest prefix matching, IP/TCP/UDP checksum, NAT, RIP/OSPF/BGP rout-
ing daemons, TCP slow-start and congestion avoidance, socket, popular packages
supporting DNS, FTP, SMTP, POP3, SNMP, HTTP, SIP, streaming, P2P, to QoS
features such as traffic shaper and scheduler, and security features such as firewall,
VPN, and intrusion detection. This system-awareness is further fortified by hands-on
exercises right at the end of each open source implementation and at the end of each
chapter, where readers are asked to run, search, trace, profile, or modify the source
codes of particular kernel code segments, drivers, or daemons. Students equipped
with such system-awareness and hands-on skills, in addition to their protocol domain
knowledge, can be expected to do more sound research works in academia and solid
development works in industry.
WHY IS MORE IMPORTANT THAN HOW
This text was written with the idea that it is more important to understand why a pro-
tocol is designed a certain way than it is to know how it works. Many key concepts
and underlying principles are illustrated before we explain how the mechanisms or
protocols work. They include statelessness, control plane and data plane, routing and
lin76248_FM_i-xiv.indd xviii
lin76248_FM_i-xiv.indd xviii 24/12/10 6:14 PM
24/12/10 6:14 PM

Preface xix
switching, collision and broadcast domains, scalability of bridging, classless and
classful routing, address translation and configuration, forwarding versus routing,
window flow control, RTT estimation, well-known ports and dynamic ports, iterative
and concurrent servers, ASCII application protocol messages, variable-length versus
fixed-field protocol messages, transparent proxy, and many others.
Misunderstandings are as important as understandings, and they deserve special
treatment to identify them. We arrange each chapter to start with general issues to
raise fundamental questions. We have added sidebars about Principles in Action,
Historical Evolution, and Performance Matters. We end with unnumbered sections
on Common Pitfalls (for common misunderstandings in the reader community), Fur-
ther Readings, FAQs on big questions for readers to preview and review, and a set of
hands-on and written exercises.
PREPARING THE AUDIENCE WITH SKILLS
Whether the instructors or students are familiar with Linux systems should not play a
critical factor in adopting this textbook. The Linux-related hands-on skills are covered
in Appendices B, C, and D. Three appendices equip readers with enough hands-on
skills, including Linux kernel overview (with a tutorial on source code tracing), devel-
opment tools (vim, gcc, make, gdb, ddd, kgdb, cscope, cvs/svn,
gprof/kernprof, busybox, buildroot), and network utilities (host,
arp, ifconfig, ping, traceroute, tcpdump, wireshark, net-
stat, ttcp, webbench, ns, nist-net, nessus). Appendix A also
has a section introducing readers to open source resources. There is also a section on
“A Packet’s Life” in Chapter 1 to vividly illustrate the book’s roadmap.
Lowering the barrier of adopting open source implementations is considered.
Instead of code listing and explanation, it is structured into Overview, Block Dia-
gram when needed, Data Structures, Algorithm Implementation, and Exercises. This
provides for ease of adoption for both students and instructors.
PEDAGOGICAL FEATURES AND SUPPLEMENTS
Textbooks usually have a rich set of features to help readers and class support materi-
als to help instructors. We offer a set of features and a set of class support materials,
summarized as follows:
1. Fifty-six explicitly numbered Open Source Implementations for key protocols
and mechanisms.
2. Four appendices on Who’s Who in Internet and open source communities, Linux
kernel overview, development tools, and network utilities.
3. Logicallyreasonedwhy,where,andhowofprotocoldesignsandimplementations.
4. Motivating general issues at the beginning of each chapter with big questions to
answer.
5. “A Packet’s Life” from the server and router perspectives to illustrate the book’s
roadmap and show how to trace packet flows in codes.
lin76248_FM_i-xiv.indd xix
lin76248_FM_i-xiv.indd xix 24/12/10 6:14 PM
24/12/10 6:14 PM

xx Preface
6. “Common Pitfalls” illustrated at the end of each chapter, identifying common
misunderstandings.
7. Hands-on Linux-based exercises in addition to written exercises.
8. Sixty-nine sidebars about historical evolution, principles, in action, and perfor-
mance matters.
9. End-of-chapter FAQs to help readers identify key questions to answer and re-
view after reading each chapter.
10. Class support materials, including PowerPoint lecture slides, solutions manual,
and the text images in PowerPoint are available at the textbook Web site:
www.mhhe.com/lin.
AUDIENCE AND COURSE ROADMAP
The book is intended to be a textbook in Computer Networks for senior undergradu-
ates or first-year graduate students in computer science or electrical engineering. It
could also be used by professional engineers in the data communication industry.
For the undergraduate course, we recommend instructors cover only Chapters 1
through 6. For the graduate course, all chapters should be covered. For instructors
who lecture both undergraduate and graduate courses, two other possible differentia-
tions are heavier hands-on assignments and additional reading assignments in the
graduate course. In either undergraduate or graduate courses, instructors could assign
students to study the appendices in the first few weeks to get familiar with Linux
and its development and utility tools. That familiarity could be checked by either
a hands-on test or a hands-on assignment. Throughout the course, both written and
hands-on exercises can be assigned to reinforce knowledge and skills.
The chapters are organized as follows:
ɀ Chapter 1 offers background on the requirements and principles of net-
working, and then presents the Internet solutions to meet the requirements
given the underlying principles. Design philosophies of the Internet, such
as statelessness, connectionlessness, and the end-to-end argument are illus-
trated. Throughout the process, we raise key concepts, including connectiv-
ity, scalability, resource sharing, data and control planes, packet and circuit
switching, latency, throughput, bandwidth, load, loss, jitter, standards and
interoperability, routing and switching. Next we take Linux as an imple-
mentation of the Internet solutions to illustrate where and how the Internet
architecture and its protocols are implemented into chips, drivers, kernel, and
daemons. The chapter ends with a book roadmap and the interesting descrip-
tion of “A Packet’s Life.”
ɀ Chapter 2 gives a concise treatment of the physical layer. It first offers concep-
tual background on analog and digital signals, wired and wireless media, coding,
modulation, and multiplexing. Then it covers classical techniques and standards
on coding, modulation, and multiplexing. Two open source implementations
illustrate the hardware implementation of Ethernet PHY using 8B/10B encoding
and WLAN PHY using OFDM.
lin76248_FM_i-xiv.indd xx
lin76248_FM_i-xiv.indd xx 24/12/10 6:14 PM
24/12/10 6:14 PM

Preface xxi
ɀ Chapter 3 introduces three dominant links: PPP, Ethernet, and WLAN. Blue-
tooth and WiMAX are also described. LAN interconnection through layer-2
bridging is then introduced. At the end, we detail the adaptor drivers that trans-
mit and receive packets to and from the network interface card. Ten open source
implementations, including hardware design of CRC32 and Ethernet MAC, are
presented.
ɀ Chapter 4 discusses the data plane and control plane of the IP layer. The data
plane discussion includes IP forwarding process, routing table lookup, check-
sum, fragmentation, NAT, and the controversial IPv6, while the control plane
discussion covers address management, error reporting, unicast routing, and
multicast routing. Both routing protocols and algorithms are detailed. Twelve
open source implementations are interleaved to illustrate how these designs are
implemented.
ɀ Chapter 5 moves up to the transport layer to cover the end-to-end, or host-to-
host, issues. Both UDP and TCP are detailed, especially the design philosophies,
behaviors, and versions of TCP. Then RTP for real-time multimedia traffic is
introduced. A unique section follows to illustrate socket design and implementa-
tion where packets are copied between the kernel space and the user space. Ten
open source implementations are presented.
ɀ Chapter 6 covers both traditional applications, including DNS, Mail, FTP, Web,
and SNMP, and new applications, including VoIP, streaming, and P2P applica-
tions. Eight open source packages that implement these eight applications are
discussed.
ɀ Chapter 7 touches on the advanced topic of QoS, where various traffic control
modules such as policer, shaper, scheduler, dropper, and admission control are
presented. Though the IntServ and DiffServ standard frameworks have not
been widely deployed, many of these traffic control modules are embedded in
products that are used every day. Hence they deserve a chapter. Six open source
implementations are presented.
ɀ Chapter 8 looks into network security issues ranging from access security
(guarded by TCP/IP firewall and application firewall), data security (guarded by
VPN), and system security (guarded by intrusion detection and antivirus). Both
algorithms (table lookup, encryption, authentication, deep packet inspection)
and standards (3DES, MD5, IPsec) are covered. Eight open source implementa-
tions are added.
ACKNOWLEDGMENTS
The draft of this text has gone through much evolution and revision. Through-
out the process, many people have directly or indirectly contributed. First, many
lab members and colleagues at National Chiao Tung University, National Chung
Cheng University, and Cisco Systems, Inc., have contributed ideas, examples, and
code explanations to this book. In particular, we would like to thank Po-Ching Lin,
Shih-Chiang Weafon Tsao, Yi-Neng Lin, Huan-Yun Wei, Ben-Jye Chang, Shun-Lee
Stanley Chang, Yuan-Cheng Lai, Jui-Tsun Jason Hung, Shau-Yu Jason Cheng,
lin76248_FM_i-xiv.indd xxi
lin76248_FM_i-xiv.indd xxi 24/12/10 6:14 PM
24/12/10 6:14 PM

xxii Preface
Chia-Yu Ku, Hsiao-Feng Francis Lu, and Frank Lin. Without their inputs, we would
not have been able to embed many interesting and original ideas into this book. We
also thank the National Science Council (NSC) in Taiwan, the Industrial Technology
Research Institute (ITRI), D-Link Corporation, Realtek Semiconductor Corporation,
ZyXEL Corporation, Cisco Systems, Inc., and Intel Corporation for supporting our
networking research in the past few years.
Next, we wish to thank the following who reviewed drafts of all or parts of
the manuscript: Emmanuel Agu, Worcester Polytechnic University; Tricha Anjali,
Illinois Institute of Technology; Ladislau Boloni, University of Central Florida;
Charles Colbourn,Arizona State University; XiaoJiang Du, Temple University; Jiang
Guo, California State University, Los Angeles; Robert Kerbs, California State Poly-
technic University, Pomona; Fang Liu, The University of Texas-Pan American; Oge
Marques, Florida Atlantic University; Mitchell Neilsen, Kansas State University;
Mahasweta Sarkar, San Diego State University; Edwin Sloan, Hillsborough Com-
munity College; Ioannis Viniotis, North Carolina State University; Bin Wang, Wright
State University; Daniel Zappala, Brigham Young University. Thanks also to Chih-
Chiang Wang, National Kaohsiung University of Applied Sciences, who polished the
manuscript grammatically.
Finally, we would like to thank the folks at McGraw-Hill who coached us
through the editorial and production phases. A special thanks should go to our Global
Publisher, Raghu Srinivasan, our Developmental Editor, Lorraine Buczek, our
production Project Manager, Jane Mohr, and Project Manager, Deepti Narwat. They
have been very supportive coaches throughout this endeavor.
lin76248_FM_i-xiv.indd xxii
lin76248_FM_i-xiv.indd xxii 24/12/10 6:14 PM
24/12/10 6:14 PM

McGraw-Hill Create™
Craft your teaching resources to match the way you teach! With McGraw-Hill
Create™, www.mcgrawhillcreate.com, you can easily rearrange chapters, com-
bine material from other content sources, and quickly upload content you have
written like your course syllabus or teaching notes. Find the content you need
in Create by searching through thousands of leading McGraw-Hill textbooks.
Arrange your book to fit your teaching style. Create even allows you to personal-
ize your book’s appearance by selecting the cover and adding your name, school,
and course information. Order a Create book and you’ll receive a complimentary
print review copy in 3–5 business days or a complimentary electronic review
copy (eComp) via email in minutes. Go to www.mcgrawhillcreate.com today and
register to experience how McGraw-Hill Create™ empowers you to teach your
students your way.
McGraw-Hill Higher Education and Blackboard have teamed up.
Blackboard, theWeb-based course-management system, has partnered with McGraw-
Hill to better allow students and faculty to use online materials and activities to
complement face-to-face teaching. Blackboard features exciting social learning and
teaching tools that foster more logical, visually impactful and active learning oppor-
tunities for students.You’ll transform your closed-door classrooms into communities
where students remain connected to their educational experience 24 hours a day.
This partnership allows you and your students access to McGraw-Hill’s Create™
right from within your Blackboard course—all with one single sign-on. McGraw-
Hill and Blackboard can now offer you easy access to industry leading technology
and content, whether your campus hosts it, or we do. Be sure to ask your local
McGraw-Hill representative for details.
Electronic Textbook Options
This text is offered through CourseSmart for both instructors and students.
CourseSmart is an online resource where students can purchase the complete text
online at almost half the cost of a traditional text. Purchasing the eTextbook allows
students to take advantage of CourseSmart’s web tools for learning, which include
full text search, notes and highlighting, and email tools for sharing notes between
classmates. To learn more about CourseSmart options, contact your sales representa-
tive or visit www.CourseSmart.com.
McGraw-Hill Digital
Offerings Include
xxiii
lin76248_FM_i-xiv.indd xxiii
lin76248_FM_i-xiv.indd xxiii 24/12/10 6:14 PM
24/12/10 6:14 PM

C
C h a p
p t e r
r 1
1
Fundamentals
C
omputer networking or data communications is a set of disciplines concerned
with communication between computer systems or devices. It has its require-
ments and underlying principles. Since the first node of ARPANET (Advanced
Research Project Agency Network, later renamed Internet) was established in 1969,
the store-and-forward packet switching technologies formed the Internet architec-
ture, which is a solution to meeting the requirements and underlying principles of
data communications. This solution converged with the TCP/IP protocol suite in
1983 and continued to evolve thereafter.
The Internet, or the TCP/IP protocol suite, is just one possible solution that
happens to be the dominant one. There are other solutions that also meet the require-
ments and satisfy the underlying principles of data communications. For example,
X.25 and Open System Interconnection (OSI) were also developed in the 1970s but
were eventually replaced by TCP/IP. Asynchronous Transfer Mode (ATM), once
popular in the 1990s, has compatibility difficulties with TCP/IP and thus faded away.
Multi-Protocol Label Switching (MPLS) survived because it was designed from the
beginning to be complementary to TCP/IP.
Similarly, there are many implementations of the Internet solution on all sorts of
computer systems or devices. Among them, the open-source implementations share
the same open and bottom-up spirit as the Internet architecture, offering the public
practical accessibility to the software’s source code. In the bottom-up approach,
volunteers contribute their designs or implementations while seeking support and
consensus from the developer community, in contrast to the top-down approach
driven by the authority. Being open-source and freely available, these implementa-
tions serve as solid running examples of how various networking mechanisms work
in specific details.
In this chapter, we intend to acquaint readers with computer network fundamen-
tals used throughout this text. Section 1.1 identifies key requirements for data com-
munications by giving definitions of a computer network in terms of connectivity,
scalability, and resource sharing. It also introduces the concept of packet switching.
In Section 1.2, the underlying principles governing data communications are identi-
fied. Performance measures such as bandwidth, offered load, throughput, latency,
latency variation, and loss are defined first. We then explain the design issues in
protocols and algorithms used for processing control packets and data packets. As
the Internet is one possible solution to computer networking, Section 1.3 describes
the Internet’s version of solutions to connectivity, scalability, and resource sharing as
lin76248_ch01_001-053.indd 1
lin76248_ch01_001-053.indd 1 24/12/10 4:11 PM
24/12/10 4:11 PM

2 Computer Networks: An Open Source Approach
well as its control- and data-packet processing. Section 1.4 discusses how the open-
source implementations further realize the Internet solution in running systems,
especially in Linux. We show why and how various protocol and algorithm modules
are implemented into the kernel, drivers, daemons, and controllers of a computer
system. We plot the roadmap for this book in Section 1.5 by showing a packet’s life
traversing through various modules in a Web server and in an intermediate intercon-
nection device. This section also lays a foundation for understanding the open-source
implementations described in subsequent chapters. Contributors to the designs and
open-source implementations of the Internet solution, along with other short-lived
networking technologies, are reviewed in Appendix A as the supplementary materi-
als to this chapter.
After reading this chapter, you should be able to explain (1) why the Internet so-
lution was designed in the way it is, and (2) how this open solution was implemented
in real systems.
1.1 REQUIREMENTS FOR COMPUTER NETWORKING
The set of requirements for computer networking can be translated into a set of
objectives that must be met when designing, implementing, and operating a com-
puter network. Over the years, this set did change gradually, but its core requirements
remain the same: “connecting an ever increasing number of users and applications
through various shared media and devices such that they can communicate with
each other.” This sentence indicates three requirements for data communications
and the relevant issues to be addressed: (1) connectivity: who and how to con-
nect, (2) scalability: how many to connect, and (3) resource sharing: how to uti-
lize the connectivity. This section presents these core requirements and discusses
generic solutions to meeting these requirements in most computer networks (not just
the Internet).
1.1.1 Connectivity: Node, Link, Path
A computer network, from the aspect of connectivity, can be viewed as “a con-
nected graph constructed from a set of nodes and links, where any pair of nodes
can reach each other through a path consisting of a sequence of concatenated nodes
and links.” We need connectivity between human users to exchange messages or
engage in conversation, between application programs to maintain the network
operations, or between users and application programs to access data or services.
Various media and devices can be used to establish connectivity between nodes,
with the device being hub, switch, router, or gateway and the media being wired
or wireless.
Node: Host or Intermediary
A node in a computer network can be either a host computer or an intermediary
interconnection device. The former is an end-point computer that hosts users and
lin76248_ch01_001-053.indd 2
lin76248_ch01_001-053.indd 2 24/12/10 4:11 PM
24/12/10 4:11 PM

Chapter 1 Fundamentals 3
applications, while the latter serves as an intermediate point with more than one
link interface to interconnect host computers or other intermediaries. Devices such
as hubs, switches, routers, and gateways are common examples of intermediaries.
Unlike a computer-based host, an intermediary might be equipped with specially
designed CPU-offloading hardware to boost the processing speed or to reduce the
hardware and processing costs. As the link or wire speed increases, wire-speed
processing requires either faster CPU or special hardware, e.g., application specific
integrated circuit (ASIC), to offload the CPU.
Link: Point-to-Point or Broadcast
A link in a computer network is called point-to-point if it connects exactly two nodes
with one on each end, or broadcast if it connects more than two attached nodes.
The key difference is that nodes attached to a broadcast link need to contend for the
right to transmit. Nodes communicating over a point-to-point link usually transmit
as they wish if it is a full-duplex link; take turns to transmit if it is a half-duplex link;
or utilize two links to transmit, one for each direction, if it is a simplex link. That
is, a full-duplex link and a half-duplex link support simultaneous bidirectional and
one-at-a-time bidirectional, respectively, while a simplex link supports unidirectional
communication only.
The physical appearance of a link can be wired or wireless, be it point-to-point
or broadcast. Usually links in local area networks (LANs), wired or wireless, are of
broadcast type, while links in wide area networks (WANs) are point-to-point. This
is because the multiple access methods used in broadcast links are usually more ef-
ficient over short distances, as we shall see in Chapter 3. However, exceptions do
exist. For example, the satellite-based ALOHA system uses broadcast-type links for
WANs. Ethernet, originally designed as broadcast links for LANs, has evolved into
point-to-point in both LANs and WANs.
Wired or Wireless
For wired links, common media include twisted pairs, coaxial cables, and fiber
optics. A twisted pair has two copper lines twisted together for better immunity to
noise; they are widely used as the access lines in the plain old telephone system
(POTS) and LANs such as Ethernet. A Category-5 (Cat-5) twisted pair, with a
thicker gauge than the twisted pair for in-home POTS wiring, can carry 10 Mbps
over a distance of several kilometers to 1 Gbps or higher over 100 meters or so.
Coaxial cables separate a thicker copper line from a thinner nested copper wire
with plastic shield, and are suitable for long-haul transmissions such as cable
TV distribution of over 100 6-MHz TV channels for an area spanning 40 km
wide. Through cable modems, some channels each can be digitized at the rate of
30 Mbps for data, voice, or video services. Fiber optics has large capacity and it
can carry signals for much longer distances. Fiber optic cables are used mostly for
backbone networks (Gbps to Tbps) and sometimes for local networks (100 Mbps
to 10 Gbps).
For wireless links, there are radio (104
~ 108
Hz), microwave (108
~ 1011
Hz),
infrared (1011
~ 1014
Hz), and beyond (ultra-velvet, X ray, Gamma ray) in the
lin76248_ch01_001-053.indd 3
lin76248_ch01_001-053.indd 3 24/12/10 4:11 PM
24/12/10 4:11 PM

increasing order of their transmission frequency. A low-frequency (below several
GHz) wireless link is usually a broadcast one, which is omnidirectional, while a
high-frequency (over tens of GHz) wireless link could be point-to-point, which
is more directional. As wireless data communication is still in its booming
stage, the prevailing systems include wireless LANs (54 Mbps to 600 Mbps
data transfer rate within a 100-m radius), general packet radio service (GPRS)
(128 kbps within a few km), 3G (3rd Generation, 384 kbps to several Mbps
within a few km), and Bluetooth (several Mbps within 10 m), all operating within
800 MHz to 2 GHz microwave spectrum.
Historical Evolution: Link Standards
There are many link standards for data communications nowadays. We may
classify links into the following categories: local, last-mile, and leased lines.
Table 1.1 lists the names and data rates of these link standards. The local
links are deployed for use in local area networks, where Category-5 (Cat-5)–
based Ethernet and 2.4 GHz wireless LANs are two dominant technologies.
The former is faster and has dedicated transmission channels over the Cat-5
twisted-pair wire, but the latter is simple to set up and has higher mobility.
TABLE 1.1 Popular Wired and Wireless Link Technologies
Wired Wireless
Local Cat-5 twisted-pair Ethernet (10
Mbps ~ 1 Gbps)
2.4 GHz band WLAN
(2 ~ 54 Mbps ~ 600 Mbps)
Last-mile POTS (28.8 ~ 56 kbps) GPRS (128 kbps)
ISDN (64 ~ 128 kbps) 3G (384 kbps ~ several Mbps)
ADSL (16 kbps ~ 55.2 Mbps) WiMAX (40 Mbps)
CATV (30 Mbps)
FTTB (10 Mbps ~)
Leased-line T1 (1.544 Mbps)
T3 (44.736 Mbps)
OC-1 (51.840 Mbps)
OC-3 (155.250 Mbps)
OC-12 (622.080 Mbps)
OC-24 (1.244160 Gbps)
OC-48 (2.488320 Gbps)
OC-192 (9.953280 Gbps)
OC-768 (39.813120 Gbps)
lin76248_ch01_001-053.indd 4
lin76248_ch01_001-053.indd 4 24/12/10 4:11 PM
24/12/10 4:11 PM

Path: Routed or Switched?
Any attempt to connect two remote nodes must first find a path, a sequence of con-
catenated intermediate links and nodes, between them. A path can be either routed or
switched. When node A wants to send messages to node B, the messages are routed
if they are transferred through non-preestablished and independently selected paths,
perhaps through different paths. By routing, the destination address of the message
is matched against a “routing” table to find the output link for the destination. This
matching process usually requires several table-lookup operations, each of which
costs one memory access and one address comparison. On the other hand, a switched
path requires the intermediate nodes to establish the path and record the state infor-
mation of this path in a “switching” table before a message can be sent. Messages to
be sent are then attached with an index number which points to some specific state
information stored in the “switching” table. Switching a message then becomes easy
indexing into the table with just one memory access. Thus, switching is much faster
than routing but at the cost of setup overhead.
We can view a routed path as a stateless or connectionless concatenation of
intermediate links and nodes, a switched path as a stateful or connection-oriented
concatenation. ATM has all its connections switched; that is, before the data begins
to flow, a connection along a path between the source and the destination has to be
established and memorized at all the intermediate nodes on the path. The Internet, in
contrast, is stateless and connectionless, and Section 1.3 shall discuss the philosophy
behind its connectionless design.
The so-called last-mile or first-mile links span the “first mile” from a home
or a mobile user to an Internet service provider (ISP). Among the items in
this category, asymmetric digital subscriber line (ADSL), cable TV (CATV),
and fiber-to-the-block (FTTB) are the most popular wired link technologies,
and 3G and WiMAX (Worldwide Interoperability for Microwave Access) are
the most popular wireless technologies for the present. POTS and Integrated
Service Digital Network (ISDN) are outdated technologies.
For wired technology, FTTB is faster than the others, but also more expen-
sive. ADSL leverages traditional telephone lines, and its transfer rate degrades
with increasing distance to the ISP. CATV leverages TV coaxial cables; it has
less limitation in distance, but the bandwidth is shared with the TV programs’
signals. If you need site-to-site connectivity that does not go through the pub-
lic shared network, you can lease a dedicated line from a carrier. In North
America, for example, leased line services from carriers include copper-based
Digital Signal 1 (DS1, T1) and DS3 (T3), and various optical STS-x (synchro-
nous transport signal, OC-x [optical carrier]) links. The latter option, though
expensive, is becoming more popular since it can meet the increasing demand
for bandwidth.
lin76248_ch01_001-053.indd 5
lin76248_ch01_001-053.indd 5 24/12/10 4:11 PM
24/12/10 4:11 PM

1.1.2 Scalability: Number of Nodes
Being able to connect 10 nodes is totally different from being able to connect mil-
lions of nodes. Since what could work on a small group does not necessarily work
on a huge group, we need a scalable method to achieve the connectivity. Thus, a
computer network, from the aspect of scalability, must offer “a scalable platform to a
large number of nodes so that each node knows how to reach any other node.”
Hierarchy of Nodes
One straightforward method to connect a huge number of nodes is to organize them
into many groups, each consisting of a small number of nodes. If the number of
groups is very large, we can further cluster these groups into a number of super-
groups, which, if necessary, can be further clustered into “super-supergroups.” This
recursive clustering method creates a manageable tree-like hierarchical structure,
where each group (or supergroup, “super-supergroup,” etc.) connects with only a
small number of other groups. If such clustering is not applied, the interconnection
network for a huge number of nodes may look like a chaotic mesh. Figure 1.1
FIGURE 1.1 Hierarchy of nodes:
grouping of billions of nodes in a
three-level hierarchy.
65,536
65,536
4,294,967,296
256 256
x256
X65,536
Supergroup
Group
Super-supergroup
256
256
x256
Historical Evolution: ATM Faded
ATM once was the presumed backbone switching technology for data commu-
nications. Unlike the Internet architecture, ATM adopted the concept of stateful
switching from POTS: Its switches keep connection-oriented state information
to decide how connections should be switched. Because ATM came up in the
early 1990s, it had to find a way to coexist with the Internet architecture, the most
dominant networking technology at that time. However, integrating connection-
oriented switching with a connectionless routing technology creates lots of over-
head. The integration of these two could take the form of internetworking theATM
domain with the Internet domain, or of a layered hybrid that usesATM to carry the
Internet packets. Both require finding existing ATM connections or establishing
but later tearing down new ATM connections after sending out just a few packets.
Moreover, the layered-hybrid approach brutally wrecks the stateless nature of the
Internet architecture. Quickly or slowly, ATM is meant to be gone.
lin76248_ch01_001-053.indd 6
lin76248_ch01_001-053.indd 6 24/12/10 4:11 PM
24/12/10 4:11 PM

illustrates how 4 billion nodes could be organized and connected into a simple three-
level hierarchy, with 256 branches at the bottom and middle levels and 65,536 branches
at the top level. As we shall see in Section 1.3, the Internet uses a similar clustering
method where group and supergroup are termed subnet and domain, respectively.
LAN, MAN, WAN
It would be natural to form a bottom-level group with the nodes which reside within a
small geographical area, say of several square kilometers. The network that connects the
small bottom-level group is called a local area network (LAN). For a group of size 256, it
would require at least 256 (for a ring-shaped network) and at most 32,640 point-to-point
links (for a fully connected mesh) to establish the connectivity. Since it would be tedious
to manage this many links in a small area, broadcast links thus come to play the dominant
role here. By attaching all 256 nodes to a single broadcast link (with a bus, ring, or star to-
pology), we can easily achieve and manage their connectivity. The application of a single
broadcast link can be extended to a geographically larger network, say metropolitan area
network (MAN), to connect remote nodes or even LANs. MANs usually have a ring
topology so as to construct dual buses for fault tolerance to a link failure.
However, such a broadcast ring arrangement has put limitations on the degree
of fault tolerance and on the number of nodes or LANs a network could support.
Point-to-point links fit in naturally for unlimited, wide area connectivity. A wide area
network (WAN) usually has a mesh topology due to the randomness in the locations
of geographically dispersed network sites. A tree topology is inefficient in WAN’s
case because in a tree network, all traffic has to ascend toward the root and at some
branch descend to the destination node. If the traffic volume between two leaf nodes
is huge, a tree network might need an additional point-to-point link to connect them
directly, which then creates a loop in the topology and turns the tree into a mesh.
In Figure 1.1, a bottom-level group by default is a LAN implemented as a hub
or a switch connecting less than 256 hosts. A middle-level supergroup could be a
campus or enterprise network with less than 256 LANs interconnected by routers
into a tree or meshed structure. At the top level, there could be tens of thousands of
supergroups connected by point-to-point links as a meshed WAN.
1.1.3 Resource Sharing
With scalable connectivity established, we now address how to share this connectiv-
ity, i.e., the capacities of links and nodes, with network users. Again, we can define a
computer network, from the aspect of resource sharing, as “a shared platform where
capacities of nodes and links are used to transfer communication messages between
nodes.” This is where data communications and the traditional voice communica-
tions differ most from each other.
Packet Switching vs. Circuit Switching
In POTS, a circuit between the caller and the callee has to be found and switched first
before a voice conversation can begin. During the whole course of the conversation,
the 64-kbps circuit has to be maintained between the conversing parties, even if both
remain silent all the time. This kind of dedicated resource allocation is called circuit
lin76248_ch01_001-053.indd 7
lin76248_ch01_001-053.indd 7 24/12/10 4:11 PM
24/12/10 4:11 PM

switching, which provides stable resource supplies and thus can sustain high quality
in a continuous data stream such as video or audio signals. However, circuit switch-
ing is not suitable for data communications where interactive or file-transfer applica-
tions pump data whenever they want but remain idle most of the time. Apparently,
allocating a dedicated circuit for such bursty traffic is very inefficient.
A more relaxed and efficient practice of resource sharing is to have all traffic com-
pete for the right of way. However, with this practice, congestion resulting from bursty
data traffic thus becomes inevitable. So how do we handle such traffic congestion? We
queue it up! Putting buffer space at nodes can absorb most congestion caused by tem-
porary data bursts, but if congestion persists for a long period of time, loss eventually
will happen due to buffer overflow. This mode of store-and-forward resource sharing
is called packet switching or datagram switching, where messages in data traffic are
chopped into packets or datagrams, stored at the buffer queue of each intermediate
node on the path, and forwarded along the path toward their destination.
POTS exercises circuit switching, whereas the Internet and ATM exercise
packet switching. As explained in Section 1.1.1, ATM’s paths are “switched” while
the Internet’s paths are “routed.” It thus might confuse readers that the Internet has
“routed” paths in the packet “switching” network. Unfortunately, this community
does not differentiate these networking technologies by name. To be precise, the
Internet runs packet routing while ATM and POTS run packet switching and circuit
switching, respectively. In some sense, ATM imitates circuit switching with connec-
tion setup for better communication quality.
Packetization
To send out a message, some header information must be attached to the message to
form a packet so that the network knows how to handle it. The message itself is then
called the payload of the packet. The header information usually contains the source and
destination addresses and many other fields to control the packet delivery process. But
how large can packets and payload be? It depends on the underlying link technologies.
As we shall see in Section 2.4, a link has its limit on the packet length, which could
cause the sending node to fragment its message into smaller pieces and attach a header
to each piece for transmission over the link, as illustrated in Figure 1.2. The packet head-
ers would tell the intermediate nodes and the destination node how to deliver and how
to reassemble the packets. With the header, each packet can be processed either totally
independently or semi-independently when traversing through the network.
It is the protocol that defines and standardizes the header fields. By definition,
a protocol is a set of standard rules for data representation, signaling, and error
FIGURE 1.2 Packetization:
fragmenting a message into
packets with added headers.
H H H
Message
Packet
with
header
lin76248_ch01_001-053.indd 8
lin76248_ch01_001-053.indd 8 24/12/10 4:11 PM
24/12/10 4:11 PM

detection required to send information over a communication channel. These standard
rules define the header fields of protocol messages and how the receiving side should
react upon receiving the protocol messages. As we shall see in Section 1.3, a message
fragment might have been encapsulated with several layers of headers, each of which
describes a set of protocol parameters and is added in front of its preceding header.
Queuing
As mentioned previously, network nodes allocate buffer queues to absorb the conges-
tion caused by the bursty data traffic. Therefore, when a packet arrives at a node, it
joins a buffer queue with other packet arrivals, waiting to be processed by the proces-
sor in the node. Once the packet moves to the front of the queue, it gets served by the
processor, which figures out how to process the packet according to the header fields.
If the node processor decides to forward it to another data-transfer port, the packet
then joins another buffer queue waiting to be transmitted by the transmitter of that
port. When a packet is being transmitted over a link, it takes some time to propagate
the packet’s data from one side to the other side of the link, be it point-to-point or
broadcast. If the packet traverses through a path with 10 nodes and hence 10 links,
this process will be repeated 10 times.
Figure 1.3 illustrates the queuing process at a node and the node’s out-link,
which can be modeled as a queuing system with a queue and a server. The server in
a node is usually a processor or a set of ASICs whose service time depends on the
clock rate of the nodal modules (e.g., CPU, memory, ASIC). On the other hand, the
service time in a link is actually the sum of (1) the transmission time, which depends
on how fast the transceiver (transmitter and receiver) can pump the data and how
large the packet is, and (2) the propagation time, which depends on how long the
transmitted signal has to propagate. The former stage at the node has only one server
to process the packets, and the time the packet spends in this stage can be reduced
by using faster transceivers. However, the latter stage at the link has a number of
parallel servers (which is equivalent to the maximum number of allowed outstand-
ing packets in the link), and the time consumed here cannot be reduced regardless
of the adopted technologies. Signals propagate through any links at a speed around
2 × 108
m/sec. In conclusion, nodal processing time and transmission time, includ-
ing their queuing times, can be further reduced as the technologies evolve, but the
propagation time would remain fixed since its value is bounded by the speed of light.
FIGURE 1.3 Queuing at a node
and a link.
Propagation
Buffer Transmitter
Buffer Processor
Packets
Node
Packets
Link
lin76248_ch01_001-053.indd 9
lin76248_ch01_001-053.indd 9 24/12/10 4:11 PM
24/12/10 4:11 PM

1.2 UNDERLYING PRINCIPLES
As the underlying technology of data communications, packet switching has laid
down the principles for data communications to follow. We can divide the set of
principles into three categories: performance, which governs the quality of services
of packet switching, operations, which details the types of mechanisms needed for
packet handling, and interoperability, which defines what should be put into standard
protocols and algorithms, and what should not.
1.2.1 Performance Measures
In this subsection, we provide fundamental background so that you can appreci-
ate the rules of the packet switching game. This background is important when
analyzing the behavior of a whole system or a specific protocol entity. To design
and implement a system or protocol without knowing, beforehand or afterward, its
performance measures under the common or extreme operational scenarios is not an
acceptable practice in this area. Performance results of a system come either from
mathematical analysis or system simulations before the real system is implemented,
or from experiments on a test bed after the system has been implemented.
Principle in Action: Datacom vs. Telecom
Here is a good place to reemphasize the major differences between datacom,
i.e., data communications or computer networking, and telecom, i.e., telecom-
munications, to finalize our discussions on the requirements for computer
networking. Among connectivity, scalability, and resource sharing, they do
not differ much from each other in scalability, but the main differences lie in
the type of connectivity they employ and the way they share resources. The
traditional telecom establishes only one type of connectivity between two com-
munication parties, supporting one single application (telephony). On the other
hand, there exists a wide spectrum of applications in datacom, which demands
various types of connectivity. The connectivity may be set between two clients
(e.g. telephony), between a client and a server process (e.g. file download or
streaming), between two server processes (e.g., mail relay or content update),
or even among a group of individuals or processes. Each application might have
a unique traffic profile, either bursty or continuous. Unlike homogeneous and
usually continuous telecom traffic, which is carried by the circuit-switching
technology at high efficiency, datacom traffic requires packet switching to
utilize resource sharing. However, compared to the buffer-less circuit switching
where the call-blocking or call-dropping probability is the only major concern,
packet switching introduces more complex performance issues. As we shall see
in the next section, datacom needs to control buffer overflow or loss, throughput,
latency, and latency variation.
lin76248_ch01_001-053.indd 10
lin76248_ch01_001-053.indd 10 24/12/10 4:11 PM
24/12/10 4:11 PM

How a system performs, as perceived by a user, depends on three things: (1) the
hardware capacity of the system, (2) the offered load or input traffic to this system,
and (3) the internal mechanisms or algorithms built into this system to handle the
offered load. A system with a high capacity but poorly designed mechanisms would
not scale well when handling a heavy offered load, though it might perform fairly
well with a light offered load. Nevertheless, a system with excellent designs but a
small capacity should not be put at a point with heavy traffic volume. The hardware
capacity is often called bandwidth, a common term in the networking area, be it a
node, link, path, or even a network as a whole. The offered load of a system may vary,
from light load, normal operational load, to extremely heavy load (say wire-speed
stress load). There should be a close match between bandwidth and offered load, if
the system is to stay in a stable operation while allowing the designed internal mecha-
nisms to play the tricks to gain more performance. For packet switching, throughput
(the output traffic as compared to the offered load of input traffic) appears to be the
performance measure that concerns us most, though other measures such as latency
(often called delay), latency variation (often called jitter), and loss are also important.
Bandwidth, Offered Load, and Throughput
The term “bandwidth” comes from the study of electromagnetic radiation, and origi-
nally refers to the width of a band of frequencies used to carry data. However, in
computer networking the term is normally used to describe the maximum amount of
data that can be handled by a system, be it a node, link, path, or network, in a certain
period of time. For example, an ASIC might be able to encrypt 100 million bytes per
second (MBps), a transceiver might be able to transmit 10 million bits per second
(Mbps), and an end-to-end path consisting of five 100 Mbps nodes and five 10 Mbps
links might be able to handle up to 10 Mbps given no other interfering traffic along
the path.
One may think of the bandwidth of a link as the number of bits transmitted and
contained in the distance propagated by the signal in one second. Since the speed of
light in a medium is fixed at around 2 × 108
m/sec, higher bandwidth means more
bits contained in 2 × 108
m. For a transcontinental link of 6000 miles (9600 km, with
a propagation delay of 9600 km/(2 × 108
m) = 48 ms) with a bandwidth of 10 Gbps,
the maximum number of bits contained in the link is thus 9600 km/(2 × 108
m) ×
10 Gbps = 480 Mbits. Similarly, the “width” of a transmitted bit propagating on a
link varies according to the link bandwidth, too. As shown in Figure 1.4, the bit width
FIGURE 1.4 Bit width in time and length for a 10-Mbps link where the transmitted data
are encoded by the widely used Manchester code.
1 1 1 0 0 1 0 1 1 0
0.1 ms in time and 20 m in length
lin76248_ch01_001-053.indd 11
lin76248_ch01_001-053.indd 11 24/12/10 4:11 PM
24/12/10 4:11 PM

in a 10-Mbps link is 1/(10 × 106
) = 0.1 μs in time, or 0.1 μs × 2 × 108
m/sec = 20 m,
in length. The signal wave of one bit actually occupies 20 meters in the link.
The offered load or input traffic can be normalized with respect to the bandwidth
and used to indicate the utilization or how busy the system is. For a 10-Mbps link, an
offered load of 5 Mbps means a normalized load of 0.5, meaning the link would be
50% busy on the average. It is possible for the normalized load to exceed 1, though
it would put the system in an unstable state. The throughput or output traffic may or
may not be the same as the offered load, as shown in Figure 1.5. Ideally, they should
be the same before the offered load reaches the bandwidth (see curve A). Beyond
that, the throughput converges to the bandwidth. But in reality, the throughput might
be lower than the offered load (see curve B) due to buffer overflow (in a node or link)
or collisions (in a broadcast link) even before the offered load reaches the bandwidth.
In links with uncontrolled collisions, the throughput may drop down to zero as the
offered load continues to increase, as plotted by curve C in Figure 1.5. With careful
design, we might prevent that from happening by having the throughput converge to
a value lower than the bandwidth.
Latency: Node, Link, Path
In addition to throughput, latency is another key measure we care about. Queuing
theory, first developed by Agner Krarup Erlang in 1909 and 1917, tells us if both
packet inter-arrival time and packet service time are exponentially distributed and
the former is larger than the latter, plus infinite buffer size, the mean latency is the
inverse of the difference between bandwidth and offered load, i.e.,
T = 1/(m − l),
where m is bandwidth, l is offered load, and T is mean latency. Though in reality ex-
ponential distribution does not hold for real network traffic, this equation gives us a
basic relationship between bandwidth, offered load, and latency. From the equation,
latency will be halved if both bandwidth and offered load are doubled, which means
larger systems usually have lower latency. In other words, resources should not be
split into smaller pieces, from the latency point of view. Again, if a system is split
into two equally small systems to handle equally divided offered load, the latency for
both smaller systems would be doubled.
The latency for a packet is actually the sum of queuing time and service time.
The latter is relatively insensitive to the offered load, but the former is quite sensi-
tive to the offered load. The service time at a node is usually the CPU time spent in
FIGURE 1.5 Bandwidth, offered
load, and throughput.
Offered load
Throughput
Bandwidth A: Ideal
B: Reality
C: Collision
lin76248_ch01_001-053.indd 12
lin76248_ch01_001-053.indd 12 24/12/10 4:11 PM
24/12/10 4:11 PM

processing a packet. On the other hand, the service time at a link consists of transmis-
sion time and propagation time. That is, at a node,
latency = queuing + processing.
But at a link,
latency = queuing + transmission + propagation.
Similar to Little’s result for a node, the bandwidth delay product (BDP) for a
link tells how many bits are contained in a pipe in transit. Figure 1.7 compares the
number of bits contained in a long, fat pipe (link) to the number in a short, thin pipe.
The delay here, denoted by L, is the propagation time instead of transmission or
Principle in Action: Little’s Result
For a node, one interesting question is how many packets are contained in a node
if we can measure its offered load and latency. The theorem developed by John
Little in 1961 answered this: If the throughput equals the offered load, which
means no loss, the mean occupancy (the mean number of packets in the node)
equals the mean throughput multiplied by the mean latency. That is,
N = l × T
where l is mean offered load, T is mean latency, and N is mean occupancy.
Little’s result is powerful because it does not have to assume the distribution of
these variables. One useful application of this result is to estimate the buffer size
of a black-box node. Suppose we can measure the maximum no-loss throughput
of a node and its latency under such throughput; the occupancy obtained by
multiplying them is approximately the minimum required buffer size inside the
node. In Figure 1.6, the estimation of occupancy holds provided no loss happens.
FIGURE 1.6 Little’s result: How many packets in the box?
1 packet/sec
Mean latency = 5 secs
1 packet/sec
Mean occupancy = 5 packets
FIGURE 1.7 Bandwidth delay
product: long, fat pipe vs. short,
thin pipe.
0 1 1 0 1 1 0 1 0 1 0 1 0 0 1
0 0 1 0 0 1 1 1 0 0 1 1 1 1 0
1 0 0 1 1 0 0 0 1 0 1 1 0 1 0
0 1 1 0 0 0 1 1 0 1 0 0 1 0 0
L
B
0 1 1 1 0 0 1 0
1 0 0 1 0 1 0 0
L'
B'
Long, fat pipe
Short, thin pipe
lin76248_ch01_001-053.indd 13
lin76248_ch01_001-053.indd 13 24/12/10 4:11 PM
24/12/10 4:11 PM

queuing time, and is determined by the length of the link. BDP is an important factor
for designing traffic control mechanisms. Links or paths with a large BDP should ex-
ercise a more preventive control mechanism instead of a reactive one since it would
be too late to react to congestion.
Jitter or Latency Variation
Some applications in data communications, packet voice, for example, need not only
small but also consistent latency. Some other applications, video and audio streaming,
for example, may tolerate very high latency and can even absorb latency variation or
jitter to some extent. Because the streaming server pumps one-way continuous traffic to
clients, the perceived playout quality would be good provided the playout buffer at clients
would not underflow—that is, get empty—or overflow. Such clients use a playout buffer
to absorb the jitter by delaying the playout times of all packets to some aligned timeline.
For example, if the jitter is 2 seconds, the client automatically delays the playout time of
all packets to the packet playout timestamps plus 2 seconds. Thus, a buffer that can queue
packets for 2 seconds must be in place. Though the latency is prolonged, the jitter is ab-
sorbed or reduced. For packet voice, such jitter elimination cannot be adopted completely
because of the interactivity required between two peers. Here you cannot sacrifice latency
too much for jitter elimination. Nevertheless, jitter is not an important measure at all for
noncontinuous traffic.
Loss
The last but not the least performance measure is the packet loss probability. There
are two primary reasons for packet loss: congestion and error. Data communication
systems are prone to congestion. When congestion occurs at a link or a node, packets
queue up at buffers in order to absorb the congestion. But if congestion persists, buf-
fers start to overflow. Suppose a node has three links with equal bandwidth. When
wire-speed traffic is incoming from both link 1 and link 2 heading to link 3, the node
would have at least 50% packet loss. For such rate mismatch, buffering cannot play
any trick here; some sorts of control mechanisms must be used instead. Buffering
works only for short-term congestion.
Errors that happen at links or nodes also contribute to packet loss. Though many
wired links now have good transmission quality with very low bit error rate, most
wireless links still have high bit error rates due to interference and signal degrada-
tion. A single bit error or multiple bit errors could render the whole packet useless
and hence dropped. Transmission is not the only source of errors; memory errors at
nodes may also account for a significant percentage, especially when the memory
module has been on for years. When packets queue in nodal buffers, bit errors may hit
the buffer memory so that the bytes read out are not the same as the bytes written in.
1.2.2 Operations at Control Plane
Control Plane vs. Data Plane
Operating a packet-switching network involves handling two kinds of packets:
control and data. The control packets carry the messages meant for directing nodes
on how to transfer data packets, while the data packets enclose the messages that
lin76248_ch01_001-053.indd 14
lin76248_ch01_001-053.indd 14 24/12/10 4:11 PM
24/12/10 4:11 PM

users or applications actually want to transfer. The set of operations for handling
control packets is called the control plane, while the one for data packets is called the
data plane. Though there are some other operations for management purposes that
are hence called the management plane, here we merge them into the control plane
for simplicity. The key difference between the control plane and the data plane is
that the former usually happens in background with longer timescales, say hundreds
of milliseconds (ms) to tens of seconds, while the latter occurs in foreground with
shorter timescales and more real-time, say microseconds (ms) to nanoseconds (ns).
The control plane often requires more complex computation per operation in order
to decide, for example, how to route traffic and how to allocate resources so as to
optimize resource sharing and utilization. On the other hand, the data plane has to
process and forward packets on the fly so as to optimize throughput, latency, and
loss. This subsection identifies what mechanisms should be in place for the control
plane while leaving the data plane to the next subsection. Their design considerations
are also raised here.
Again, the mission of the control plane in data communications is to provide
good instructions for the data plane to carry data packets. As shown in Figure 1.8, to
achieve that, the control plane of intermediary equipment needs to figure out where
to route packets (to which links or ports), which usually requires exchange of control
packets and complex route computation. In addition, the control plane may also need
to deal with miscellaneous issues such as error reporting, system configuration and
management, and resource allocation. Whether this mission is done well usually
does not directly affect the performance measures as much as what the data plane is
capable of. Instead, the control plane concerns more whether the resources have been
utilized efficiently, fairly, and optimally. We now look at what mechanisms might be
put into the control plane.
Routing
Most literatures do not differentiate routing and forwarding. Here we define routing
as finding where to send packets and forwarding as sending packets. Routing is thus
to compute the routes and store them in tables which are looked up when forwarding
packets. Routing is usually done in the background periodically, so as to maintain
and update the forwarding tables. (Note that many literatures refer to forwarding
tables as routing tables. We use both terms in this text to mean the same thing.)
It would be too late to compute the route when a packet arrives and needs to be
FIGURE 1.8 Some operations at the control plane and the data plane in an intermediary.
Routing
Error
reporting
Operations at
control plane
Operations at
data plane
System
cfg. and mgmt.
Resource
allocation
Forwarding
Classi-
fication
Error
control
Traffic
control
Quality
of service
Deep pkt.
inspection
lin76248_ch01_001-053.indd 15
lin76248_ch01_001-053.indd 15 24/12/10 4:11 PM
24/12/10 4:11 PM

forwarded right away. There would be time only for table lookup, but not for running
a route computation algorithm.
Routing as route computation is not as simple as one might think at first glance.
There are many questions to be answered before you come to design a routing
algorithm.
Should the route be determined hop-by-hop at each intermediate router or com-
puted at the source host, i.e. source-routed?
What is the granularity of the routing decision: per destination, per source-
destination, per flow, or even per packet in the extreme?
For a given granularity, do we choose single-path routing or multiple-path routing?
Is the route computation based on global or partial information of the network?
How to distribute the global or partial information? By broadcasting among all
routers or exchanging between neighboring routers?
What is the optimal path by definition? Is it the shortest, the widest, or the most
robust one?
Should the router support only one-to-one forwarding or one-to-many forwarding,
that is, unicasting or multicasting?
All these must be carefully thought out first. We underline those design choices that
are made by the Internet, but a different set of choices would be possible for other
network architectures. We do not plan to elaborate here how these choices really
work in the Internet. Here we merely raise the design issues of routing protocols and
algorithms, while leaving the details to Chapter 4.
Traffic and Bandwidth Allocation
It is possible to consider routing from an even more performance-oriented perspec-
tive. If traffic volume and bandwidth resources could be measured and manipulated,
we would be able to allocate a certain traffic volume and direct it through paths with
certain allocated bandwidth. Allocating or assigning traffic has another label similar
to routing, namely traffic engineering. Both bandwidth allocation and traffic engi-
neering usually have specific optimization objectives, such as minimizing the aver-
aged end-to-end latency and optimal load balancing, given a set of system constraints
to satisfy. Because such an optimization problem needs very complex computation,
which might not be finished in real time, and also because only a few systems are
capable of adjusting bandwidth allocation on the fly, traffic and bandwidth allocation
are usually done off-line at the management plane or during the network planning
stage.
1.2.3 Operations at Data Plane
Unlike the operations at the control plane, which may apply only to the control pack-
ets in the timescale of hundreds of milliseconds to tens of seconds, things at the data
plane apply to all packets and proceed in microseconds or less. Forwarding packets
appears to be the primary job at the data plane since a packet arriving to an interface
port or link could be forwarded to another port. In fact, forwarding might be just one
of the services offered at the data plane. Other services might be packet filtering,
lin76248_ch01_001-053.indd 16
lin76248_ch01_001-053.indd 16 24/12/10 4:11 PM
24/12/10 4:11 PM

encryption, or even content filtering. All these services require classifying packets by
checking several fields, mostly in the header but maybe even in the payload, against
the rules maintained by the control plane or preconfigured by administrators. Once
matched, the matching rules tell what services the packet should receive and how to
apply those services.
Forwarding itself cannot guarantee the healthy functioning of a network. In ad-
dition to forwarding and other value-added services already mentioned, error control
and traffic control are two other basic per-packet operations at the data plane; the
former is to ensure the packet is transmitted intact without bit errors, while the latter
is to avoid congestion and maintain good throughput performance. Without these two
basic operations, forwarding alone would turn the network into congestion-prone,
erroneous chaos. Here we take a closer look at these operations listed in Figure 1.8.
Forwarding
Depending on how routing at the control plane is determined, packet forwarding
involves examining one or several header fields in a packet. It may just take the
destination address field to look up the forwarding table, or it may take more fields
in doing so. Decisions made in routing directly determine how forwarding can be
done, including which header field to examine, which entry in the forwarding table
to match, etc. It appears that how this game (forwarding) can be played is already
settled by another game (routing) decided somewhere else, but in fact there is still
much room for players here. Probably the most important question to answer for
packet forwarding is how fast you need to forward packets. Suppose that a router
node has four links, each of 10 Gbps capacity, and also that the packet size is small
and fixed at 64 bytes. The maximum number of aggregated packets per second (pps)
at the router would be 4 × 10 G/(64 × 8) = 78,125,000, which means this router would
need to forward 78,125,000 pps (merely 12.8 ns per packet) if wire-speed forwarding
is desired. This certainly poses challenges in designing the forwarding mechanism.
How to implement the data structure of the forwarding table and the lookup and
update algorithms on this data structure are open to the designers. These designs de-
termine whether a node is capable of wire-speed forwarding. In some circumstances,
specific ASIC might be needed to offload this job from CPU so as to achieve a for-
warding speed of millions of packets per second. While speed certainly is the goal of
this game, size also matters. The data structure to store the forwarding table might be
constrained. For 80,000 forwarding entries each of 2 to 3 bytes, one might try to store
them into a tree or a hash table with no more than hundreds of kilobytes (KB) or in
flat index tables of hundreds of megabytes (MB). An immediate observation is that
there is a tradeoff between time complexity and space complexity in the forwarding-
table implementation.
Classification
As mentioned previously, many services need packet classification operations, a
matching process that takes one or several fields in the packet header to match against
a set of rules. A rule has two parts: condition and action, specifying under what condi-
tion on the field(s) the action should be applied to the matching packet. Since each
service has its own set of fields to examine against its own set of rules, a classifier and
lin76248_ch01_001-053.indd 17
lin76248_ch01_001-053.indd 17 24/12/10 4:11 PM
24/12/10 4:11 PM

its associated rules, or classification database, would be needed for a specific service.
For the forwarding service, the forwarding table is its classification database.
A question similar to how fast you need to forward packets is how fast you need
to classify packets. The speed here depends on two things: the number of fields (from
one to several) and the number of rules (from several to tens of thousands), and both
numbers directly affect the classifier’s throughput scalability. Thus, designing a
multi-field classification algorithm that can scale well with the number of fields and
the number of rules is the goal. A design is less scalable if it has high throughput
when the two numbers are small but much dropped throughput when either one is
relatively large. Similar to forwarding, one may resort to ASIC hardware designs to
achieve high throughput of packet classification.
Deep Packet Inspection
Both forwarding and classification examine packet header fields. But there are
things, often malicious, hidden deep in the packet payload. For example, intrusions
and viruses reside deep in the application headers and payloads, respectively. Know-
ledge about these contents is usually abstracted into a database of signatures, which
is used to match against the payload of incoming packets. This matching process is
called deep packet inspection (DPI) since it looks deep into the payload. Because the
signatures are usually expressed in simple character strings or regular expressions,
string matching is the key operation in DPI.
Again, how fast you can perform string matching is the major concern. This,
compared to the one-dimensional forwarding and two-dimensional classification, is
a three-dimensional problem where the number of signatures, the length of signa-
tures, and the size of character set of the signature strings are the parameters. It would
be even more challenging to design an algorithm that scales both up and down well in
this large problem space. After all, it is an open design issue that also requires ASIC
hardware solutions for high throughput.
Error Control
As discussed in Subsection 1.2.1, bit errors may hit packets. The errors might occur
during packet transmission or when packets are stored in memory. Two fundamental
questions need to be answered: (1) detect or correct? (2) hop-by-hop or end-to-end?
The first question concerns how the receiver of a packet in error detects and handles
the error. Two approaches exist: The receiver may detect the error by the extra redun-
dant bits and notify the sender to retransmit, or it may detect and correct the error
directly if the extra redundant bits can indicate the exact bits that are in error. The lat-
ter approach would require more redundant bits, and hence produce higher overhead.
Whether to do error correction depends on the type of traffic being carried. For real-
time traffic, notifying the sender to retransmit is not an appealing approach. It is then
feasible to simply drop packets in error without further actions if the application can
tolerate a small percentage of loss; otherwise, error correction should be exercised.
The second question is all about where the error might occur: link or node? If bit
errors only occur at links, error control can be placed at each link’s receiver to detect
or also correct the errors. By doing so, a path would be error-free because all links
can recover errors. However, if packets stored at nodes suffer from memory errors,
lin76248_ch01_001-053.indd 18
lin76248_ch01_001-053.indd 18 24/12/10 4:11 PM
24/12/10 4:11 PM

Another Random Scribd Document
with Unrelated Content

CHAPTER IV
IN TOKYO
Where We Settled—A Police Stand—Stores—“Broadway”—
Illumination—The Foreign Settlement.
About two years after I entered the village school I had to leave it for
good and all. My father, as I have said, was in mid-air between the
heaven of old Japan and the prosaic earth of the new institution. He
would fain have remained there, had he had a pillar of gold to
support him. And it is wonderful to see how this glittering pillar does
support one in almost any place. It was a very serious matter for
him to launch in the new current without any helpful equipment. But
he had to do it, and made up his mind to try his fortune at the very
centre of the new civilization, Tokyo. And so one day we said good-
by to our friends who came to see us off, and started for the capital.
“Parting is such sweet sorrow,” as the poet sang, but I hardly
remember now whether I shed tears or not. As I, however, look back
to the day, I cannot but be grateful for the new move, for the
immeasurable benefit it brought at least to us children.
In Tokyo we settled very near where my aunt lived. The street was
by no means in a noisy quarter, but I can hardly think of anywhere
in the city which was so well situated for being in contact with so
many places of interest, at least for a boy just from the country. It
was near to the “Broadway” of Tokyo, and just as near to the foreign
settlement and to the railroad station, the only one of the kind in the
city in those days. And if I wanted a touch of the old order of things,
there was a big temple, a block on the east, which made its
presence known to the forgetful people by striking a big bell every
evening. I cannot say they rang the bell, because the bells at
Buddhist temples do not chime, but boom. They are so big—bigger

than a siege-gun. I liked the sound very much, as it brought to me
like a dream the vision of a hillside sleeping under the setting sun.
But I must not forget to mention a large piece of grassy ground very
near us, where we could romp, fly kites, or play at a tug-of-war.
Now the first thing I did when I came to the new place was to
familiarize myself with the neighborhood for the sake of running
errands, or just to keep myself informed. First I started eastward
and turned the corner to the left, where I found a wee bit of a
house, or rather a box, six feet by nine, where two policemen were
stationed. It was the first time I had ever seen any of them, and I
thought they were a queer sort of people, who looked at me
suspiciously whenever I looked at them in that way. But I thought as
long as I did not do anything wrong, they would have no reason for
coming at me. I also had great faith that if a thief should break into
our house, they would soon come to our help. So I made several
trials to see how quickly I could cover the distance to give them
notice. They must have thought me a strange boy as I came panting
to the police stand and stopped short to look at the clock inside.
A little beyond began the market. First a grocery store, then a fish
stall, a bean-cake shop, and so on. I remember that the house I
most frequented was a sweet potato store. I could get five or six
nice hot baked pieces for a penny. And how I liked them! At regular
intervals fresh ones were ready and we waited for them, falling into
a line. When we got as much as we wanted, we would run a race
lest they should get too cold. At the end of the street, just opposite
a tall fire-ladder, standing erect and with a bell on the top, was a big
meat store. Beef, pork, everything, they had, and sometimes I found
a bill posted saying, “Mountain Whale, To-day.” Whatever that might
be, I never cared to eat such doubtful things. You never tried sea-
horse or sea-elephant, did you?
Then, going in another direction from my house, I made my way to
“Broadway.” I first crossed a bridge which spanned a canal and came
to an object of much interest. It was a telegraph-pole. I was never
able to count the wires on it unless I did it by the help of a

multiplication table, as there were so many of them, coming from all
parts of the country to the central station. A strange thing about
them was that they sang. When I put my ear to the pole, even on a
windless day, I could hear a number of soft voices wailing, as it
were. I thought they must come from messages running on the
wires, many of which were indeed too sad to describe. And then
there was something which made me think that boys in that vicinity
had a very hard time. Many a time I saw kites with warriors’ faces
painted on them, entangled in the wires. The faces which looked
heroic, now seemed only grinning furiously for agony! But I must not
be musing on such things, for if I did not take care in that crowded
thoroughfare, a jinrikisha man would come dashing from behind with
“Heigh, there!” which took the breath out of a country boy.
The Japanese “Broadway.”
Broadway was built after a foreign style,—I don’t know which
country’s, though. There were sidewalks with willow-trees,—and
there are no sidewalks in ordinary Japanese roads,—and brick
houses, two stories high, and with no basement. Horse-cars were
running, but they would not be on the track after ten in the evening.

Many jinrikishas were running, too, and some half a dozen of them
were waiting for customers at each corner. But not a shadow of a
cab was to be seen anywhere. To tell the truth, I never thought of
finding one then, its existence in the world being unknown to me at
that time. There were a good many wonders in store for me in the
shops, and I never grew tired of inspecting them. One curious thing
was that here and there at the notion stores boys were playing
hand-organs, probably to draw customers in. So I thought, anyway,
and every time I passed I obliged them awhile by listening to their
music. As I strolled on, I came across a sign with “Shiruko” in large
letters on it. Shiruko is a sort of pudding, made of sweet bean sauce
and rice dumpling, and served hot. To be sure, it made my mouth
water, but I went on reading a bill over the wall. There were twelve
varieties of shiruko, it said, styled after the names of the months,
and any one who could finish eating all of them at one time, would
get a prize besides the return of the price! How I wished that I had
a big stomach!
The sight of Broadway was prettier in the evening, when the
sidewalks would be lined with hundreds of stalls. I shall have
occasion to describe them later, and so let me now mention one
thing which I never remember without a smile. It was an illumination
on a holiday evening—not of the whole street, but of only one
building, and that of two stories, I remember. It was a newspaper
office. And as newspapers are always giving us something new, this
building, I think, awoke one morning to give us what was very new
at that time. It girdled itself just once with an iron pipe half an inch
in diameter, which twisted itself into some characters in the front,
and awaited a holiday evening. The paper advertised that everybody
should come to see how they were going to celebrate the holiday
evening. So the whole city turned out, and all my folks, too. Hand-
organs in the stores around began a concert, and people waited with
their mouths open. The time came, and lights were seen running
from both ends like serpents, closing up in the centre. Wonder of
wonders! “DAILY NEWS OFFICE” in gaslight appeared!

I must tell you one more adventure I had, and that was an excursion
into the foreign settlement. As I came to the city I met with a
foreigner once in a while. I wondered how I should feel if I but
plunged into their crowd and spoke with them, if possible. So one
day, with a curious mind, I started for the place where the foreigners
lived together, about a mile from my home. As I neared the
settlement I made several discoveries. First, the houses looked very
prim and square, straight up and down, painted white, or in some
light color. When viewed from a distance they looked as if they were
so many gravestones in a temple yard. Unfortunately, it was the only
comparison that occurred to a country boy. As I looked again, I
found out another fact. That was, that while Japanese houses were
nestling under the trees, foreign houses were above them. In fact,
there was nothing more than low bushes around the houses. So my
conclusion was that foreigners lived in gravestone-like houses, and
did not like tall trees, being tall themselves, perhaps. As I entered a
street I found everything just contrary to my expectation. Streets
were deserted instead of being thronged; only one or two people
and a dog were seen crossing. I went on, when, as luck would have
it, I neared a Catholic temple from which two men, or women,—I
could not distinguish which,—dressed in black, with hoods of the
same color, came! How dismal, I thought, and immediately took to
my heels till I came to another part of the street where the houses
faced the sea. I wanted to see a boy or a girl, anyway, if I could not
find a crowd. As I looked I saw something white at one of the gates,
and what was my delight when I found it to be a little girl! I
approached her, but not very near, as we could not talk to each
other. I just kept at an admiring distance. I stood there, one eye on
her and the other on the sea, lest I should drive her in by looking at
her with both my eyes, and began to examine her. What a pretty
creature she was! With her face white as a lily and her cheeks pink
as a cherry flower, she stood there watching me. Her light hair was
parted, a blue ribbon being tied on one side like a butterfly. She had
on a white muslin dress with a belt to match the ribbon, but what
was my astonishment to find that I could not see any dress beyond
her knees! I could not believe it at first, but the dress stopped short

there, and the slender legs, covered with something black,—I did
not care what,—were shooting out. Might not some malicious person
have cut it so? “Oh, please, for mercy’s sake, cover them,” was my
thought. “I don’t care if you have a long dress, the skirt trailing on
the ground.” But was I mistaken in my standard of criticism? I
looked at myself, and, sure enough, my kimono reached down to my
feet!

CHAPTER V
MY NEW SCHOOL
Tomo-chan—The Men with Wens—A Curious Punishment—How I
Experienced It—Kotoro-kotoro.
Of course I attended another school as soon as we were settled.
And every morning I went with my Tomo-chan.
But I must tell you who Tomo-chan was. She—yes, she—was the
adopted daughter of my aunt, of about the same age as I, and in
the same class at school. I wish I had space enough to tell you how
she came to be adopted, but I shall have to be contented just with
telling you that the main cause of her becoming a member of my
aunt’s family was all through me. Aunty had no child, but she had
found how lovely a child is, even if he be mischievous, through my
short visit two years before, which I have had no occasion to tell you
about. Now one of the first principles in physics says that nature
abhors a vacuum. This means that it is unnatural for a place to have
nothing in it. I had gone back: who was to fill my place? So Tomo-
chan, a better and certainly prettier child than I, slipped into my
shoes.
Aunty wished us to be good friends. So I called on her every
morning on my way to school, and in the afternoon we went over
our lesson together. Arithmetic was not very hard for me, and so I
helped her over pitfalls of calculation, while she did the same for me
with reading. Girls remember very well, but do not care to reason
things out, it seems. And indeed, Tomo-chan remembered even the
number of mistakes I made in reading. Now what one can do in half
a day, two can accomplish in half an hour, was the philosophy that
came to me from our case; for our drudgery was over in no time,
and we were going through Tomo-chan’s treasure of nice pictures

and books of fairy-tales. There was a picture in one of the books of
an old man with a wen on his cheek, dancing before a crowd of
demons and goblins. “Look here, what is this?” I asked. She laughed
at the picture and would not tell me about it till she had thoroughly
enjoyed laughing. That is the way of a girl. But with “O dear!” she
started thus:
“One day, this old man with a wen happened to fall into a crowd of
those ugly monsters, and was made to dance. He danced very well,
and so was asked to come again the next day. The goblins wanted
something for a pledge for his keeping his word and so removed the
wen from the man’s cheek. The old man was very glad to part with
it, and went home, when he met another man with a wen.” She
turned the leaf to show another picture. This time the new man was
dancing before the weird crowd. “You see, this man was told how he
could remove his wen, and is now showing his skill before them to
induce them to ask for the pledge. But he did not have any practice
at all in dancing and so was just jumping round. And the goblins got
angry over his deceit, and sent him back with the wen that the old
man had left.” Turning the leaf, “Here he is with wens on both his
cheeks!”
She laughed again, and I could not help laughing with her, too. At
this moment some one was coming up the stairs.
“Why, is this the way you study your lesson?”
It was aunty who entered the room as she said: “I am surprised at
you.” And she laid down a tray with a teapot and cups and a dish of
cakes on it. The sight made us happy all at once, and Tomo-chan
explained to her how soon we had finished our study.
“Why, Ei-chan helped me in arithmetic, so we finished a long, long
time ago.”
“Well, Ei-chan is a good boy, isn’t he?” said aunty. Boys feel awkward
to be well spoken of to their face, and my speech failed me
somehow. By the way, I was no longer “Bot’chan.”

The school I found much larger and finer than the village one. The
pupils numbered ten times more. Each class had its own room, and
boys and girls marched in and out in procession every hour. It was
so much more orderly and systematic than the village school that
there was less of “out-of-tune” matter. But then there was one thing
that puzzled me. It was that often a boy was seen standing in the
hallway with a bowl of water in his hands. Sometimes he stood there
motionless until the class was all dismissed. But I was not slow to
divine the cause. What puzzled me was the question: “How could
that be the best form of punishment?” While a boy stood there he
need not attend the class. That was certainly easy for an idle boy.
And then there was no pain to endure. As to the holding of a bowl,
why, did I not hold my bowl of rice every meal and not know even if
it was heavy or light? But another solution suggested itself to me; it
might have the same effect on the offender as wearing a cap with “I
am a Fool,” written on it. He stood there, and everybody thought he
was a bad boy. “It might be, it might be,” I said, congratulating
myself on the happy solution, when a crow that had just alighted on
a branch of the elm by the gate repeated, “It might be!” I threw a
stone at him without thinking that it was a violation of the school
rule, and, if discovered, I might have undergone the punishment.
At any rate, I was destined, it appeared, to undergo the punishment
once at least. And it happened in this way.
At this school, boys were not allowed to carry iron tops or even
hand-balls. There were too many of them, and if they should all
indulge in these sports, there would be constant danger of breaking
their legs or knocking their noses off. So comparatively harmless
footballs were provided. Now, one noon recess, ten of us wanted to
have a game. We were divided into parties of five and played. Of
course we had no rules to go by, but tried to carry the ball within the
enemy’s lines by every means. One time we fumbled furiously near
the building, and, in the heat of our tackling, one fellow seized the
ball and kicked it without minding in which direction he was aiming.
If he had had less skill the ball would have gone only over the roof
and dropped on the head of a jinrikisha man running on the other

street. But as it was, it went madly against a window-pane and
smashed it all to pieces. What a noise it made! For a minute it made
all the boys and girls playing on the ground keep quite still. And in
this awful suspense a teacher appeared and caught the five, I
among the number, who were still in the position of fumbling,
together with the poor fellow who did the kicking, and who stood
dazed, unable to recover as yet from the shock of his late
experience. I didn’t know how the other four escaped being caught,
but I was glad that they did.
There was no question in the teacher’s mind but that all six should
be exhibited in the hallway, and so we were made to stand there,
each holding a bowl of water. Now I had an ample opportunity to
learn every significance of this form of punishment. Naturally, we felt
merry at first. In the first place, there was something unreasonable
and ludicrous in the way at least five of us came to stand there. And
then when you have companions in your bad luck, you feel surely
light of heart. And so we did. But when fifteen, thirty minutes
passed, our legs got to be stiff and the weightless bowls began to
weigh very much in our hands. Indeed, the slightest inclination
would spill the water! But why did we not drink some of it, you may
say? Well, we should have done it, but we knew that it must all be
there when the teacher came. Forty-five minutes, and the bell rang
for the dismissal. All the boys and girls poured out, leaving us alone.
Ah, that is the saddest moment for any schoolboy, for after that the
school is dismal as a prison. Fifteen minutes more, and all the
teachers, except the one in charge of us, were gone. None of us
dared to look up, our heads being bent with extreme sorrow.
Presently a weak-minded fellow dropped his china and cried out. It
was not I, but we were all ready to follow his example, when the
teacher came out, and, removing the bowls, read us a lecture before
sending us home.
We lost our courage, even to run out of the school compound, but
dragged slowly home. But when I turned the first corner whom
should I meet but my Tomo-chan?

“Why, Tomo-chan!” I looked at her in surprise.
“I could not go home without you. So I waited for you. But isn’t it a
shame for teacher to punish you without your deserving it?” she
said.
“We did not want to let Takeda suffer alone, you know.”
My answer was a surprise even to me. Of course, I did not think to
the contrary, but I was not impressed with the significance of it till I
put it into words and—to her. It came as a new thought to me. Our
hearts became light, the thing was forgotten, and only the prospect
of the fine time we should have that golden afternoon in late
summer occupied our minds.
“Come along,” I said. “Let’s go to the field!”
And we hastened on briskly, and, throwing our things into our
houses on the way, went to the field, green with cool, cushion-like
grass. About a dozen boys and girls were already waiting for us, and
we just jumped among them.
“What shall we play?” said one.
“Let’s have Kotoro-kotoro,” suggested another.
“That’s fun!” all shouted.
To play the game, we must first select from the boys one “chief” to
protect his “sons and daughters,” and one “imp” to catch them. The
boys stand in a circle and are ready to say “Jan-ken-pon,” and to
hammer with their fists. At “pon” you make one of three shapes with
your hand. When your hand is spread, that denotes a sheet of
paper; when two fingers only are stretched, that means a pair of
scissors; and when your hand is held closed, it signifies a stone. A
sheet of paper can be cut by scissors, but the latter is ineffectual on
a stone. But a stone can be wrapped by a sheet of paper. Hence,
each one can defeat one of the rest, but is conquered by the other.
To simplify the matter, you can use only two of the three shapes.
The one who wins at first is to be the chief, the one who is
ultimately defeated, the imp. So we began: “Jan-ken-pon!”

Only three won. Then those three tried again.
“Jan-ken-pon!”
I won; and so was the chief. The rest went on jan-ken-ponning till
the imp was decided.
Now all except the imp held firmly each other’s belt on the back, in a
line, with me at the head. It is a pity you don’t have any belt on your
dress, and so play the sport. It is very convenient to us. Apart from
its use in sport, when we meet a robber, we throw him down by jiu-
jitsu, and, untying our belt, bind him up hand and foot! But to
return. I was ready with the imp in front and with my “little ones”
behind, like the body of a centipede. The imp could not touch me;
he could only seize any one behind. I stretched my arms, ran to and
fro to prevent the imp from getting round to my flanks. The line
swayed, rolled, jerked like a serpent in a rapid flight. And the motion
would all but throw weak-armed ones off their holds. But they
merrily persisted, and could have held on longer but for their mirth
being worked up too high by the very manner of the imp himself.
The boy who played that part was a born comedian. He loved his fun
more than his bread. Once in the midst of his supper he heard a
man come with a monkey dressed in a kimono. No sooner than he
recognized that by the sound of a drum, he threw away his chop-
sticks, and, running out of his house, danced all way up the street
with the professional monkey as his wondering spectator. Now in
playing his part as the imp, he did not go about it like an eagle
intent on his prey. But he brought all his talent into full play in every
motion of his body, suggestive of some grotesque form, heightened
by a queer ejaculation. When, in his series of performances, he
imitated a pig, flapping his hands from his head like large ears of the
animal and grunting, Gr-r-r-r, Gr-r-r-r, it caused everybody to burst
into laughter. At this moment he made a sudden turn, which caused
such a jerk to the line, that, being absent-minded from merriment,
they were all thrown out of their hold, each rolling on the grass, but
still laughing at the grunting. The imp could now jump at anybody

for his prey, but as a true comedian, he also rolled on the grass,
laughing with the rest.

CHAPTER VI
CHINESE EDUCATION
My Chinese Teacher—How I Was Taught—Versification—My
Uncle—Clam Fishing—A Flatfish.
Some months after I entered the public school, my father came to a
conclusion that what was taught there was too modern to have
enough of culture value. My education had to be supplemented by
the study of Chinese classics. And his intention would have been of
great benefit to me if he had been equally wise in selecting a good
private teacher. As it was, I gained but a fraction of it, undergoing a
hard struggle.
There lived a Chinese scholar near by, who was second to none in
his learning within three miles. Formerly he was a priest of Zen sect,
the Unitarian of Buddhism. As it was considered most laudable to a
man of his calling, he never ate fish or meat, and had two frugal
meals a day, taking only a cupful of starch and sugar in the evening,
till he came to lead a secular life. Starch and sugar!—so he must
have come to have such white hair, I thought. Anyway, the snowy
mass heightened the expression of his earnest face, rather youthful
for a man of sixty. He was, indeed, the classic itself; the rhythm of it
seemed to be ringing in his veins, whether awake or asleep. And he
delighted in nothing so much as to eat his dinner listening to the
clear-voiced chanting of boys reviewing their lesson, as if they were
minstrels entertaining at a king’s feast! And, of course, I was sent to
him.
I started from the beginning, which was, indeed, no beginning at all.
The Chinese sages did not write their scriptures as graded school
text-books, but their descendants believed so, anyhow. Genesis was

the genesis of successful mastery. And so I began with that great
sentence in the “Book of Great Learning:”
“Learning is a gateway to virtue.”
I envy those boys who tore Chinese authors, and whose books,
when taken to a second-hand bookstore, were not bought even for a
penny. My books were, on the contrary, just as clean as ever, as if
they had been too loath to impart anything to the owner. And this
was not from any effort on my part to take care of them, but simply
from the little use I made of them. Now this was the way I studied
them. Teacher would read with me about four pages in advance, and
see once how I could read. I stuck; he prompted me; I stuck again;
he prompted me again; I stuck for the third time, and for the third
time he prompted me, and so on, and indeed continually, if I had
gone on till I had thoroughly mastered it. But one review seemed to
him sufficient for such easy passages, and my boyish heart
responded too gladly to be released after a short lesson. And I laid
my book by till the next day. I did not know how the teacher
regarded me, but he must have thought me a very bright fellow for
whom such a slow process as review was totally unnecessary. And
he immediately took up the next four pages and went on in the
usual manner. The first book was finished; the teacher’s instinct
asserted itself, and he wanted me to read a few pages by way of a
test before I proceeded. What a shame! I only recognized a box
here and a starfish there, and that was all. The teacher was angry at
the result. He saw that I was not prepared yet to take up the
classics. And with his admirable pedagogical insight, he sent me to a
primer the very next day. It was a Japanese history, written in easy
Chinese prose. How I enjoyed the change! The passages rolled off
on my tongue as easily as you might say, “Mary had a little lamb.”
The teacher smiled at my ease, and soon recovered his humor. But
his eyes were so constructed as to see nothing but the top and the
foot of a mountain, and his mind worked like a spring-board, which
either stays low or jumps high up. And on the third day I was
ordered to begin the second book of the classics, called the
“Doctrine of Mean!”

And I plodded on. I went through the “Book of Divination,” and
“Odes of Spring and Autumn,” and came out only with some
phantoms of angular, mysterious hieroglyphics dancing before my
eyes. But my Chinese education included something more than
reading. It was versification. Just think of requiring a ten-year-old
boy to write verse in Latin or Greek. But every Saturday I was
required to do the same sort of thing for two years. Oh, how I
struggled! I hunted for something sensible to write, but while all
sorts of nonsense would come up, even common sense, that most
useful guide in a prosaic field, fled from me. Outside, merry shouts
of boys—a happy group who cared for balls and kites more than dry-
as-dust “culture”—were heard, and I mused in a corner of a room,
consulting such help as a phrase book and a rhyming dictionary.
Nothing but doggerel could be born of such a forced labor. Here is a
specimen:
“Shut from the blue of skies in spring,
I sit and fret for words to rhyme.
O bird, if you have songs to sing,
Drop one for me to save my time!”
The Chinese training did me at least one good turn. It drove
Confucius out of my head!
I should have been a blighted boy if Sundays had not come to my
rescue. The real use to which the day should be put had not dawned
on me, nor was it in the mind of those who introduced the
institution. But I am glad to say that it did me good in many ways.
With this, however, my uncle is invariably associated.
I have not said anything about him, but he was a well-fed man with
a goat’s beard. He was very nervous, however, and could not keep
from pulling his beard. This accounted for its scantiness. It was very
amusing to observe how easily his temper was disturbed out of its
normal mood. When he was contradicted he pulled hard at his beard
and wrung his hands furiously. His body seemed to expand with the
inner fire when he ejaculated many an “Ahem!” preliminary to an
eruption. Everybody had to find shelter and thrust his fingers into his

ears, lest the drums should break. But when he was pleased, his
face melted with laughter; he went to a cupboard to look for some
nice thing for us, ordered dinner to be hurried for our sake, and
went round and round us to see if we were really comfortable.
He was very alert, and was always looking for a new thing. He did
well, too, to keep himself abreast of the age, and, indeed, mastered
something of the English language, of which he could well boast in
his day. His pronunciation, however, was rather painful to hear, and
in his talk with foreigners his nervous hands played a large part to fill
in the gaps in his vocabulary, with an intermixture of many a “you
know.”
One good thing about him was his love for outdoor sports. He could
not sit all day like my Chinese teacher, and if ever an eruption
occurred, it was always on the occasion of such confinement to his
room. His Sundays were scheduled for this or that kind of pleasure
excursion. And of course I was wise enough to do what I could to
please him in order that I might not be left out of his party.
One Sunday we were to go clam-fishing. When it was announced on
Friday before, I thought of a great time and could hardly sleep for
joy. After a tedious labor of writing verse was over the next
Saturday, I busied myself the rest of the afternoon with the
preparation for the next day. I kept going to my uncle’s to see
whether we had the same things that they had, and also to suggest
the necessity of providing things we had and they had not. Many
conferences for this purpose were held at the door-sill with Tomo-
chan. Small hand-rakes were bought, one for each; small and large
baskets, knives, thick-soled socks, small sashes, and so forth, were
collected from various sources. To this I added a net three by four
feet large, with two poles to meet the exigency of encountering
some large fish—perhaps a whale. But of this I did not speak to
anybody.
Mother was also busy preparing our lunch. For this she got up very
early in the morning and boiled rice, which she made into triangular,
round, or square masses, speckled with burned sesame seeds. She

packed them in several lacquered boxes, with fresh pickles and
cooked vegetables. We relied on our clams for chief dishes; so some
cooking utensils were necessary. Also some tea and a teapot, cups
and dishes, together with chop-sticks and toothpicks, even.
The day was not fair, but it was just the kind of weather for the
season, dull and somewhat hazy, but bespeaking a calm sea. The
tide was fast ebbing when we started in a boat. There was a good
company of us, including uncle, aunt, mother, Tomo-chan, and me.
As we emerged into the bay from the canal, the extended view was
delightful. On one side green masses of pine-trees overhung the
stone mounds and merged into a leafy hill, which stretched itself like
an arm into the sea. On the other, beyond reedy shoals, the old
forts, with a lighthouse on one of them, dotted the expanse. The
view was washed in gray, and even the sails of junks, hanging lazily
from the masts, were scarcely lighter than the background.
All was calm. But as we sighted from a distance some other parties
already on the scene, we soon forgot everything for the excitement
and let the boatman hurry with all his strength. It was nine when we
arrived at the desired spot, and we had three hours to enjoy
ourselves. We fixed our boat to a pole, from the top of which was
drooping a piece of red and white cloth. This served as our mark to
enable us to find the boat quickly in the case of need. So each party
had something of its own design. Purple, green, white, and red in all
sorts of combinations and forms were displayed, while a coat, a
shirt, or even an improvised scarecrow was not denied use.
So we went into water, our sleeves and skirts being tied up and our
legs bared to the knees. Each was provided with a basket and a
hand-rake—except myself, who, in addition to the implements, took
out secretly my net, wound round the poles. My people were all too
busy to observe me, however. We went on raking for clams. There
seemed to be lots of black or white shells which we did not want,
but I soon found that clams were rather a matter of chance, and a
chance would come no more than once in every fifteen minutes! I
luckily struck on three nice ones in a short time, and dug diligently

for some thirty minutes, but without any result. So I grew tired, and
began inspection. Aunt had ten, mother eight, and uncle five. When
I approached him, he looked up, red in the face. I wondered if he
was not angry. But it was not so, for he heaved a sigh and
straightening up and striking his back with his fist, said, “O dear!”
“Uncle, you will soon be quitting your job, just as I shall, I think,”
said I.
“Pshaw! How many have you?”
“Three, sir.”
“You can’t have more than that for your lunch, you understand,
unless you get more. Now don’t be in my way.” And again he
doubled his corpulent body to work. But I was right in thinking that
he could not keep himself in the same posture for another three
minutes. Now I passed on to Tomo-chan. Poor Tomo-chan had only
two! She was all but weeping for the bad luck. She, however, looked
comforted to find that I did not fare much better. But what was her
surprise when I threw all my clams in with hers!
“Keep them, Tomo-chan. I am going to fish with this net.” Her eyes
looked gratitude. “Oh, thank you ever so much. But I’ll catch fish
with you if I don’t fare any better.”
“All right.” And I went on thinking that if I could not get clams for my
lunch, I should have fish to the envy of all. I looked among the rocks
for some shadow of them. Surely I saw something shooting away
now and then, without waiting for me to find out whether it was
large or not. But anyway, they were all right if I could get a number
of them, and so I fixed my net and tried to drive them into it, little
thinking that the very whiteness of my net—I appropriated a net
made for the purpose of keeping flies off—scared every fish. I got
irritated with my ill-success, and finally splashed the water
vigorously to punish them.
By this time my uncle had quit his work, as I predicted, and was
engaging with hen-like anxiety to look after his flock. He kept his
eyes on them, and would go like a shepherd dog to fetch any one

who went too far away from the boat. He looked at his watch to see
if the tide was not turning on, and went occasionally to the boat to
see if anything was lost. He seemed to like this kind of work better
than clam-fishing, for I could see even from a distance that he was
pulling at his beard, as he was wont to do when his mind was
occupied. Presently he heard me splashing the water far away, and
started at once to bring me back. Time could not be lost, he must
have thought, but I did not know anything of his approach till I
heard a shriek behind me. Surprised, I turned round when I found
him just recovering his balance and looking intently into the water.
“What’s matter, uncle?” I hastened toward him.
“Stop. A flatfish somewhere.” Seeing me with a net, he exclaimed,
“Quick with your net.”
“A flatfish?” I queried in excitement.
“Yes, I stepped on him and he gave me a slip.... Oh, here he is;
cover him quick!” And we covered him with my net without much
ado. I was surprised to see how easily I could catch him compared
with other fish that I had tried for. As I raised him, however, I found
he was already crushed dead under my uncle’s weight!
But it was a large one, and I could have an honorable share at
lunch.

CHAPTER VII
AN EVENING FÊTE
My Father—His Love for Potted Trees—A Local Fête—Show
Booths—Goldfish Booths—Singing Insects—How a Potted Tree
Was Bought.
Evenings were not without enjoyment for me. And for this I owe
much to my father.
My father was a silent, close-mouthed man. His words to children
were few and mostly in a form of command. They were never
disobeyed, partly because it was father who spoke, but more
because we knew that he spoke only when he had to. Indeed, he
carried a formidable air about him, apparently engrossed in thought
somewhat removed from his immediate concern. He was by no
means philosophical, however, and his reticent habit was born of the
peculiar circumstances under which he was laboring. Fortune was
evidently against him. And partly out of sympathy with him and
partly out of fear of breaking his spell, when we had something to
ask of him—boys have many wants—we had some indirect means to
devise. Thus, when my cap had worn out and I wanted a new one, I
dropped a hint in his presence by way of a soliloquy: “I wish I had a
new cap. My old one is worn out.” Saying this just once at a time
and thrice in the course of one evening, if I persevered for three
nights, I used to have my old cap replaced with a new one on the
next day!
He knew that he was fighting against odds, but his spirit was never
crushed. He only persevered. One day he came back from his
evening stroll with a piece of bamboo flute. Evidently he was
attracted by a tune a man at the corner of a street was playing on it
as he sold his wares, and felt his soul suddenly gain its freedom and

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!
ebookultra.com

Computer Networks An Open Source Approach 1st Edition Ying-Dar Lin

More Related Content

Similar to Computer Networks An Open Source Approach 1st Edition Ying-Dar Lin (20)

Recently uploaded (20)

Computer Networks An Open Source Approach 1st Edition Ying-Dar Lin