Internet Routing COS 598A

1
Internet Routing COS 598A

• Jennifer Rexford
• http//www.cs.princeton.edu/jrex/teaching/spring2
  005
• Tuesdays/Thursdays 1100am-1220pm

2
Who am I, and Who are You?

• Who am I?
• Joined the CS faculty in Feb 2005 (i.e., today)
• Worked for 8.5 years at ATT LabsResearch
• Research on routing protocols, network
  measurement, and network operations
• Who are you, and what do you do?
• Introductions

3
What is Internet Routing?

• The glue that holds the Internet together
• How routers know where to forward packets
• How operators control the load on their links
• How networks achieve business relationships

4
3
5
2
6
7
1
Client
Web server
4
What Does This Course Cover?

• Internet architecture
• Best-effort packet-delivery service
• Intradomain and interdomain routing
• Network topology
• Inside a network, and between networks
• Traffic engineering
• Getting the traffic to go where you want
• Convergence
• Delay to respond to change
• Whether the protocol ever converges

5
What Does the Course Cover? (Continued)

• Routers
• Router hardware and software
• Router configuration
• Scaling to many destinations, routers, networks
• Measurement
• Monitoring the routing protocols
• Characterizing the routing system
• Troubleshooting routing problems
• Routing protocol security
• New architectural directions

6
Emphasis of the Course

• Not so much on the protocols
• though we will cover BGP, OSPF, IS-IS, MPLS, and
  various other acronyms of the day
• Or on the routers
• though we will talk about how routers work
• But more on how people manage routing
• Selecting which protocols to use
• Deciding how to set the parameters
• Troubleshooting problems as they arise
• Preventing attacks

7
Structure of the Course

• Classroom time
• Mixture of lecture and discussion of papers
• Readings
• Selected research papers and surveys
• Videocasts of presentations (e.g., from NANOG)
• Optional short food for thought reading each
  week
• Course project
• Literature survey, measurement or simulation
  study, protocol design, theoretical analysis,
  etc.
• Grading
• Final course project (written report and oral
  presentation)
• Class participation (written reviews, class
  discussion, etc.)

8
Today, and Thursday

• Goal
• Explain IP best-effort delivery model
• Today
• What is the service model?
• How can you do anything useful with this?
• Thursday
• How do the routers support the service model?
• How do the routing protocols work?

9
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
10
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 on every packet

11
IP Packet Structure
4-bit Header Length
8-bit Type of Service (TOS)
4-bit Version
16-bit Total Length (Bytes)
3-bit Flags
16-bit Identification
13-bit Fragment Offset
20-byte Header
8-bit Time to Live (TTL)
8-bit Protocol
16-bit Header Checksum
32-bit Source IP Address
32-bit Destination IP Address
Options (if any)
Payload
12
IP Service Model Why Best-Effort?

• Its easier not to make promises
• Dont need to reserve bandwidth and memory
• Dont need to do error detection correction
• Dont need to 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

13
IP Service Model Best-Effort is Enough

• No error detection or correction
• Higher-level protocol can provide error checking
• Successive packets may not follow the same path
• Not a problem as long as packets reach the
  destination
• Packets can be delivered out-of-order
• Receiver can put packets back in order (if
  necessary)
• Packets may be lost or arbitrarily delayed
• Sender can send the packets again (if desired)
• No network congestion control (beyond drop)
• Sender can slow down in response to loss or delay

14
Layering in the IP Protocols
Telnet
HTTP
RTP
DNS
FTP
Transmission Control Protocol (TCP)
User Datagram Protocol (UDP)
Internet Protocol
Ethernet
SONET
ATM
15
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
16
Source and Destination Port Numbers

• Motivation for port numbers
• Unique identifier of the TCP connection on each
  end
• Necessary to (de)multiplex packets at the
  end-points
• Assigning port numbers
• Port numbers below 1024 are assigned
• Well-known port numbers for common applications
• Web client contacting a web server
• Browser click results in creation of a TCP socket
• Client machine assigns an available port (gt1024)
• Client machine requests a connection with the
  server
• Open TCP connection to port 80 at the server

17
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

18
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

19
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
20
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

21
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.foo.com
• Server application
• Extract client IP address from socket
• Optionally invoke system call to translate into
  name
• E.g., gethostbyaddr() on 12.34.158.5

22
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
23
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.
24
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
25
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, high RTT, 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

26
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
This course focuses on the routers
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
Reading for Thursday

• Two classic papers
• End-to-end arguments in system design (1984)
• Design philosophy of the DARPA Internet protocols
  (1988)
• New perspectives on success of the Internet
• Tussle in cyberspace Defining tomorrows
  Internet (2002)

29
Backup Slides

• TTL and traceroute

30
Time-to-Live Field

• Potential robustness problem
• Routing loops can cause packets to cycle forever
• Confusing if the packet arrives much later
• Time-to-live field in packet header
• TTL field decremented by each router on the path
• Packet is discarded when TTL field reaches 0
• and send timer expired message to source

31
Traceroute Measuring the Forwarding Path

• Time-To-Live field in IP packet header
• Source sends a packet with a TTL of n
• Each router along the path decrements the TTL
• TTL exceeded sent when TTL reaches 0
• Traceroute tool exploits this TTL behavior

destination
source
Send packets with TTL1, 2, 3, and record
source of time exceeded message