Computer Networks

1
Computer Networks

• Guest Lecture in COS 318
• Jennifer Rexford
• http//www.cs.princeton.edu/jrex

2
Goal of the Lecture

• Brief introduction to data networking
• Best-effort service and the hourglass model
• From sending packets to downloading Web pages
• Internet addressing, routing, and topology
• Teaser for COS 461, offered next term
• MW 130-250pm

3
Best-Effort Packet-Delivery Service
4
IP Service Model Best-Effort Packet Delivery

• Packet switching
• Send data in packets
• Header with source destination address
• Best-effort delivery
• Packets may be lost
• Packets may be corrupted
• Packets may be delivered out of order

source
destination
IP network
5
IP Service Model Why Packets?

• Data traffic is bursty
• Logging in to remote machines
• Exchanging e-mail messages
• Dont want to waste reserved bandwidth
• No traffic exchanged during idle periods
• Better to allow multiplexing
• Different transfers share access to same links
• Packets can be delivered by most anything
• RFC 2549 IP over Avian Carriers (aka birds)
• still, packet switching can be inefficient
• Extra header bits (envelope) for every packet

6
IP Service Model Why Best-Effort?

• Its easier not to make promises
• Dont reserve bandwidth and memory
• Dont do error detection and correction
• Dont remember from one packet to next
• Easier to survive failures
• Transient disruptions are okay during failover
• but, applications do want efficient, accurate
  transfer of data in order, in a timely fashion

7
IP Service Model Best-Effort is Enough

• No error detection or correction
• Receiver can discard corrupted packets
• Sender can send the packets again
• Successive packets may not follow the same path
• Okay as long as packets reach the destination
• Packets can be delivered out-of-order
• Receiver can put packets back in order
• Packets may be lost or arbitrarily delayed
• Sender can send the packets again
• No network congestion control (beyond drop)
• Sender can slow down in response to loss or delay

8
Layering in the IP Protocols Hourglass
Telnet
HTTP
RTP
DNS
FTP
Transmission Control Protocol (TCP)
User Datagram Protocol (UDP)
Internet Protocol
Ethernet
SONET
ATM
9
Transport Protocols Between End Hosts
10
Transmission Control Protocol (TCP)

• Communication service (socket)
• Ordered, reliable byte stream
• Simultaneous transmission in both directions
• Key mechanisms at end hosts
• Retransmit lost and corrupted packets
• Discard duplicate packets and put packets in
  order
• Flow control to avoid overloading the receiver
  buffer
• Congestion control to adapt sending rate to
  network load

TCP connection
source
network
destination
11
Opening and Closing a TCP Connection
B
ACK
ACK
SYN ACK
SYN
ACK
Data
FIN
FIN
ACK
A
time

• Three-way handshake to establish connection
• Host A sends a SYN to the host B
• Host B returns a SYN and acknowledgement
• Host A sends an ACK to acknowledge the SYN ACK
• Four-way handshake to close the connection
• Finish (FIN) to close and receive remaining bytes
  , or
• Reset (RST) to close and not receive remaining
  bytes

12
Lost and Corrupted Packets

• Detecting corrupted and lost packets
• Error detection via checksum on header and data
• Sender sends packet, sets timeout, and waits for
  ACK
• Receiver sends ACKs for received packets
• Sender infers loss from timeout or duplicate ACKs
• Retransmission by sender
• Sender retransmits lost/corrupted packets
• Receiver reassembles and reorders packets
• Receiver discards corrupted and duplicated packets

13
TCP Flow and Congestion Control

• Window-based flow control
• Sender limits number of outstanding bytes (window
  size)
• Receiver window ensures data does not overflow
  receiver
• Adapting to network congestion
• Congestion window tries to avoid overloading the
  network (increase with successful delivery,
  decrease with loss)
• TCP connection starts with small initial
  congestion window

congestion window
congestion avoidance
slow start
time
14
User Datagram Protocol (UDP)

• Some applications do not want or need TCP
• Avoid overhead of opening/closing a connection
• Avoid recovery from lost/corrupted packets
• Avoid sender adaptation to loss/congestion
• Example applications that use UDP
• Multimedia streaming applications
• Domain Name System (DNS) queries/replies
• Dealing with the growth in UDP traffic
• Interference with TCP performance
• Pressure to apply congestion control
• Future routers may enforce TCP-friendly behavior

15
Converting Host Names to Numerical Addresses
16
Domain Name System (DNS)

• Properties of DNS
• Hierarchical name space divided into zones
• Translation of names to/from IP addresses
• Distributed over a collection of DNS servers
• Client application
• Extract server name (e.g., from the URL)
• Invoke system call to trigger DNS resolver code
• E.g., gethostbyname() on www.cs.princeton.edu
• Server application
• Extract client IP address from socket
• Optionally invoke system call to translate into
  name
• E.g., gethostbyaddr() on 12.34.158.5

17
Domain Name System
unnamed root
zw
arpa
com
edu
org
ac
uk
generic domains
country domains
in- addr
bar
ac
west
east
12
cam
foo
my
34
usr
my.east.bar.edu
usr.cam.ac.uk
56
12.34.56.0/24
18
DNS Resolver and Local DNS Server
Application
DNS cache
Local DNS server
DNS resolver
Caching based on a time-to-live (TTL) assigned by
the DNS server responsible for the host name to
reduce latency in DNS translation.
19
Building Applications on Top (e.g., Web)
20
Application-Layer Protocols

• Messages exchanged between applications
• Syntax and semantics of the messages between
  hosts
• Tailored to the specific application (e.g., Web,
  e-mail)
• Messages transferred over transport connection
  (e.g., TCP)
• Popular application-layer protocols
• Telnet, FTP, SMTP, NNTP, HTTP,

GET /index.html HTTP/1.1
Client
Server
HTTP/1.1 200 OK
21
Example Many Steps in Web Download
Browser cache
DNS resolution
TCP open
1st byte response
Last byte response

• Sources of variability of delay
• Browser cache hit/miss, need for cache
  revalidation
• DNS cache hit/miss, multiple DNS servers, errors
• Packet loss, round-trip time, server accept queue
• RTT, busy server, CPU overhead (e.g., CGI script)
• Response size, receive buffer size, congestion
• downloading embedded image(s) on the page

22
IP Suite End Hosts vs. Routers
host
host
HTTP message
HTTP
HTTP
TCP segment
TCP
TCP
router
router
IP packet
IP packet
IP packet
IP
Ethernet interface
SONET interface
SONET interface
23
Routers, Addressing, and Forwarding
24
What is a Router?

• A computer with
• Multiple interfaces
• Implementing routing protocols
• Packet forwarding
• Wide range of variations of routers
• Small LinkSys device in a home network
• Linux-based PC running router software
• Million-dollar high-end routers with large
  chassis
• and links
• Serial line
• Ethernet
• Packet-over-SONET

25
Network Components
Links
Interfaces
Switches/routers
Ethernet card
Large router
Fibers
Wireless card
Coaxial Cable
Telephone switch
26
Inside a High-End Router
Processor
Switching Fabric
Line card
Line card
Line card
Line card
Line card
Line card
27
Happy Routers Make Happy Packets

• Routers forward packets
• Forward incoming packet to outgoing link
• Store packets in queues
• Drop packets when necessary
• Routers compute paths
• Routers run routing protocols
• Routers compute forwarding tables
• A famous quotation from RFC 791
• A name indicates what we seek. An address
  indicates where it is. A route indicates how we
  get there. -- Jon Postel

28
IP Addressing

• 32-bit number in dotted-quad notation
  (12.34.158.5)
• Divided into network host portions (left and
  right)
• 12.34.158.0/24 is a 24-bit prefix with 28
  addresses

12
34
158
5
Network (24 bits)
Host (8 bits)
29
whois h whois.arin.net 128.112.136.35

• OrgName Princeton University
• OrgID PRNU
• Address Office of Information Technology
• Address 87 Prospect Avenue
• City Princeton
• StateProv NJ
• PostalCode 08544-2007
• Country US
• NetRange 128.112.0.0 - 128.112.255.255
• CIDR 128.112.0.0/16
• NetName PRINCETON
• NetHandle NET-128-112-0-0-1
• Parent NET-128-0-0-0-0
• NetType Direct Allocation
• RegDate 1986-02-24

30
Packet Forwarding

• Forwarding tables in IP routers
• Maps each IP prefix to next-hop link(s)
• Destination-based forwarding
• Packet has a destination address
• Router identifies longest-matching prefix
• Cute algorithmic problem very fast lookups

forwarding table
4.0.0.0/8 4.83.128.0/17 12.0.0.0/8 12.34.158.0/24
126.255.103.0/24
destination
12.34.158.5
outgoing link
Serial0/0.1
31
Internet Topology and Routing
32
Autonomous Systems (ASes)
Path 6, 5, 4, 3, 2, 1
4
3
5
2
6
7
1
Web server
Client
33
Internet Routing Architecture

• Divided into Autonomous Systems
• Distinct regions of administrative control
• Routers/links managed by a single institution
• Service provider, company, university,
• Hierarchy of Autonomous Systems
• Large, tier-1 provider with a nationwide backbone
• Medium-sized regional provider with smaller
  backbone
• Small network run by a single company or
  university
• Interaction between Autonomous Systems
• Internal topology is not shared between ASes
• but, neighboring ASes interact to coordinate
  routing

34
Autonomous System Numbers
AS Numbers are 16 bit values.
Currently around 20,000 in use.

• Level 3 1
• MIT 3
• Harvard 11
• Yale 29
• Princeton 88
• ATT 7018, 6341, 5074,
• UUNET 701, 702, 284, 12199,
• Sprint 1239, 1240, 6211, 6242,

35
Interdomain Routing (Between ASes)

• ASes exchange info about who they can reach
• IP prefix block of destination IP addresses
• AS path sequence of ASes along the path
• Policies configured by the network operator
• Path selection which of the paths to use?
• Path export which neighbors to tell?

I can reach 12.34.158.0/24 via AS 1
I can reach 12.34.158.0/24
1
2
3
data traffic
data traffic
12.34.158.5
36
Inside an AS Abilene Internet2 Backbone
37
Intradomain Routing (Within an AS)

• Routers exchange topology information
• Routers compute next hop to other routers
• Path chosen based on link weights (shortest path)
• Link weights configured by network operator
• to control the flow of traffic

2
1
3
1
3
2
1
5
4
3
38
Funny Things About the Internet

• Nobody really knows how big it is
• No global registry of the topology
• Hard to know what traffic it carries
• New applications try to hide their identity
• Built based on trust in others
• Do congestion control, announce only the
  addresses you own, and so on
• Operators do a lot of things manually
• Half of outages are caused by operator error
• Diagnosing performance problems is hard
• So many things can go wrong, in so many places

39
Learn More

• COS 461, spring 2006
• MW 130-250pm