INTRODUCTION & REVIEW

INTERNET PROTOCOL AND

SERVICES

Some slides have been taken from: Computer Networking: A Top

Down Approach Featuring the Internet, 3rd edition. Jim Kurose, Keith Ross.
Addison-Wesley, July 2004. All material copyright 1996-2004. J.F Kurose and
K.W. Ross, All Rights Reserved.

1
Contents
• Internet protocol stack
• Application layer
• UDP & TCP
• Network layer

2
What’s the Internet?
mobile network
• Internet: “network of networks”
• Interconnected ISPs global ISP
• protocols control sending,
receiving of msgs home
• e.g., TCP, IP, HTTP, Skype, 802.11 network
regional ISP
• Internet standards
• RFC: Request for comments
• IETF: Internet Engineering Task
Force

institutional
network

3
What’s the Internet?
mobile network
• Infrastructure that provides
services to applications: global ISP

• Web, VoIP, email, games, e-

commerce, social nets, … home
network
• provides programming regional ISP
interface to apps
• hooks that allow sending and
receiving app programs to
“connect” to Internet
• provides service options,
analogous to postal service
institutional
network

4
What’s a protocol?
human protocols: network protocols:
• “what’s the time?” • machines rather than
• “I have a question” humans
• introductions • all communication
activity in Internet
… specific msgs sent governed by protocols
… specific actions taken protocols define format, order
when msgs received, of msgs sent and received
or other events
among network entities,
and actions taken on msg
transmission, receipt
5
TCP/IP protocol stack
• application: supporting network
applications application
• FTP, SMTP, STTP
transport
• transport: host-host data transfer
• TCP, UDP network
• network: routing of datagrams from
link
source to destination
• IP, routing protocols physical
• link: data transfer between neighboring
network elements
• PPP, Ethernet
• physical: bits “on the wire”

6
 source
message M application
Encapsulation
segment Ht M transport
datagram Hn Ht M network
frame Hl Hn Ht M link
physical
link
physical

switch

destination Hn Ht M network
M application Hl Hn Ht M link Hn Ht M
Ht M transport physical
Hn Ht M network
Hl Hn Ht M link router
physical
7
Application layer
• E-mail • Internet telephone
• Web • Real-time video
• Instant messaging conference
• Remote login • Massive parallel
• P2P file sharing
computing
• Multi-user network games
• Streaming stored video
clips

8
Creating a network app
application
Write programs that transport
network
• run on different end systems data link
physical
and
• communicate over a network.
• e.g., Web: Web server software
communicates with browser
software
No software written for
devices in network core application
application
transport
transport network
• Network core devices do not network data link
data link physical
function at app layer??? physical

9
Application architectures
• Client-server
• Peer-to-peer (P2P)
• Hybrid of client-server and P2P

10
 Client-server architecure

client clients:
• communicate with server
• may be intermittently
client connected
• may have dynamic IP
addresses
• do not communicate directly
client with each other
Server

server:
• always-on host
client • permanent IP address
• server farms for scaling

11
Pure P2P architecture
• no always on server Peer Peer
• arbitrary end systems
directly communicate
• peers are intermittently
connected and change IP
addresses
• example: Gnutella

Highly scalable
Peer Peer
But difficult to manage
12
Hybrid of client-server and P2P
BitTorrent Client
• File transfer P2P
• File search centralized:
• Peers register content at central
server
• Peers query same central server
to locate content Server
Instant messaging
• Chatting between two users is
P2P
• Presence detection/location
centralized: Client
Client
• User registers its IP address with
central server when it comes
online
• User contacts central server to find P2P Comm.
IP addresses of buddies Client-Server Comm.
13
Processes communicating
Process: program running Client process: process
within a host. that initiates
• within same host, two communication
processes communicate Server process: process
using inter-process that waits to be
communication (defined contacted
by OS).
• processes in different  Note: applications with
hosts communicate by P2P architectures have
exchanging messages client processes &
server processes

14
 Sockets
host or host or
• process sends/receives server server
messages to/from its socket
controlled by
• Defined by app developer
process process
• Port number Socket
• IP Address address socket socket

• TCP/UDP TCP with TCP with

buffers, Internet buffers,
• API: (1) choice of transport variables variables
protocol; (2) ability to fix a
few parameters controlled
by OS

15
Processes communicating
• Client process: sends request
• Server process: replies response
• Typically: single server - multiple clients
• The server does not need to know anything about the
client
• The client should always know something about the
server
• at least the socket address of the server

wait for result handles response

client

request response

server
wait handle wait
request 16
App-layer protocol defines
• Types of messages exchanged, e.g, request &
response messages
• Syntax of message types: what fields in messages &
how fields are delineated
• Semantics of the fields, e.g., meaning of information
in fields
• Rules for when and how processes send & respond
to messages

17
What transport service does an app need?

Data loss Bandwidth

• some apps (e.g., audio) can  some apps (e.g.,
tolerate some loss multimedia) require
• other apps (e.g., file transfer, minimum amount of
telnet) require 100% reliable bandwidth to be
data transfer “effective”
Timing  other apps (“elastic
• some apps (e.g., Internet apps”) make use of
telephony, interactive whatever bandwidth
games) require low delay they get
to be “effective”

18
Transport services and protocols
• provide logical communication application
transport
between app processes running network
data link network
on different hosts physical data link
network physical
• transport protocols run in end data link
physical
systems network
data link
physical network
• send side: breaks app data link
physical
messages into segments,
network
passes to network layer data link
physical
• rcv side: reassembles
segments into messages, application
transport
passes to app layer network
data link
physical
• more than one transport protocol
available to apps
• Internet: TCP and UDP

19
Internet transport protocols services
TCP service: UDP service:
• reliable transport between
sending and receiving • unreliable data transfer
process between sending and
• flow control: sender won’t receiving process
overwhelm receiver
• does not provide:
• congestion control: throttle
sender when network reliability, flow control,
overloaded congestion control,
• does not provide: timing, timing, throughput
minimum throughput guarantee, security, or
guarantee, security
• connection-oriented: setup connection setup,
required between client
and server processes

20
 Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

21
How demultiplexing works
❖host receives IP 32 bits
datagrams source port # dest port #
▪ each datagram has source IP
address, destination IP address
other header fields
▪ each datagram carries one
transport-layer segment
▪ each segment has source,
application
destination port number
data
❖host uses IP addresses (payload)
& port numbers to direct
segment to appropriate TCP/UDP segment format
socket
22
 UDP: User Datagram Protocol [RFC 768]

• “no frills,” “bare bones”

Internet transport protocol Why is there a UDP?
• “best effort” service, UDP • no connection establishment
segments may be: (which can add delay)
• lost • simple: no connection state at
sender, receiver
• delivered out of order to
app • small segment header

• connectionless: • no congestion control: UDP

can blast away as fast as
• no handshaking between
desired
UDP sender, receiver
• each UDP segment
handled independently of
others

23
UDP demultiplexing
• Create sockets with port • When host receives UDP
numbers: segment:
mySocket = socket(AF_INET, • checks destination port
SOCK_DGRAM, 0) number in segment
• UDP socket identified by two- • directs UDP segment to
tuple: socket with that port number
(dest IP address, dest port number) • IP datagrams with different
source IP addresses and/or
source port numbers
directed to same socket

24
 UDP demux
serverSocket =
socket(AF_INET,
mySocket = mySocket =
socket(AF_INET, SOCK_DGRAM, 0);
socket(AF_INET,
SOCK_DGRAM, 0); bind(…) SOCK_DGRAM, 0);
application
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
25
 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

• point-to-point: • connection-oriented:
• one sender, one receiver • handshaking (exchange of
control msgs) init’s sender,
• reliable, in-order byte
receiver state before data
steam: exchange
• no “message boundaries”
• flow controlled:
• pipelined: • sender will not overwhelm
• TCP congestion and flow receiver
control set window size
• full duplex data:
• send & receive buffers • bi-directional data flow in
same connection
application application
socket
writes data reads data
socket
• MSS: maximum segment
door
TCP TCP
door
size
send buffer receive buffer
segment
26
TCP Connection Management: Setup

Recall: TCP sender, receiver Three way handshake:

establish “connection” before
exchanging data segments Step 1: client host sends TCP
• initialize TCP variables: SYN segment to server
• seq. #s • specifies initial seq #
• buffers, flow control info • no data
(e.g. RcvWindow) Step 2: server host receives SYN,
• client: connection initiator replies with SYNACK segment
• connect()
• server allocates buffers
• server: contacted by client
• specifies server initial seq. #
• accept()
Step 3: client receives SYNACK,
replies with ACK segment, which
may contain data
27
Principles of reliable data transfer

sending receiving
process process
application dat dat
transport a a

sender-side of receiver-side
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
▪ unless communicated via a unreliable channel
message??????
reliable service implementation

28
 TCP segment structure
32 bits

source port # dest port # segment seq #: counting

ACK: seq # of next expected sequence number bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
head not
length (of TCP header) len used C E UA P R S F receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept
options (variable
C, E: congestion notification length)
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable length) TCP socket

29
TCP sequence numbers, ACKs
outgoing segment from sender
Sequence numbers: source port # dest port #
sequence number
• byte stream “number” of acknowledgement number
rwnd
first byte in segment’s data checksum urg pointer

window size
Acknowledgements: N

• seq # of next byte expected

from other side sender sequence number space

• cumulative ACK sent sent, not- usable not

ACKed yet ACKed but not usable
(“in-flight”) yet sent
Q: how receiver handles out-of-
order segments outgoing segment from receiver

• A: TCP spec doesn’t say, - up

source port # dest port #
sequence number

to implementor acknowledgement number

A rwnd
checksum urg pointer

30
TCP sequence numbers, ACKs
Host A Host B

User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt
of‘C’, echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt
of echoed ‘C’
Seq=43, ACK=80

simple telnet scenario

31
TCP: retransmission scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

32
TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK covers

for earlier lost ACK

33
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers
buffers?
TCP
code
Network layer
delivering IP
datagram payload
IP
into TCP socket
code
buffers

from sender

receiver protocol stack

34
TCP flow control
▪ TCP receiver “advertised” free
buffer space in rwnd field in TCP to application process
header
• RcvBuffer size set via socket RcvBuffer buffered data
options (typical default is 4096 bytes)
• many operating systems auto adjust rwnd free buffer space
RcvBuffer
▪ sender limits amount of unACKed
TCP segment payloads
(“in-flight”) data to received rwnd
▪ guarantees receive buffer will not TCP receiver-side buffering
overflow

35
 TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTEN
clientSocket.connect((serverName,serverPort)) LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

36
Connection-oriented demux
• TCP socket identified by • Server host may support
4-tuple: many simultaneous TCP
• source IP address sockets:
• source port number • each socket identified by its
• dest IP address own 4-tuple
• dest port number • Web servers have different
• recv host uses all four sockets for each
values to direct segment connecting client
to appropriate socket

37
 Connection-oriented demux: example

application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets 38
 Connection-oriented demux: example
threaded server
application
application application
P4
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80

39
Network layer
application

• transport segment from transport

network
data link
sending to receiving host physical
network network

• on sending side network

data link
data link
physical
data link
physical

encapsulates segments physical network

data link
network
data link

into datagrams physical physical

• on receiving side, delivers network

data link
network
data link

segments to transport physical

network
data link
physical

layer physical
application
network transport
• network layer protocols in network
data link
physical
network
data link
network
data link
every host, router data link
physical
physical physical

• router examines header

fields in all IP datagrams
passing through it
40
Two key network-layer functions
• forwarding: move packets
analogy:
from router’s input to
• routing: process of
appropriate router output
planning trip from source
• routing: determine route to dest
taken by packets from
source to dest.
• forwarding: process of
getting through single
• routing algorithms interchange

41
Interplay between routing and forwarding
routing algorithm routing algorithm determines
end-end-path through network

local forwarding table forwarding table determines

header value output link local forwarding at this router
0100 3
0101 2
0111 2
1001 1

value in arriving
packet’s header
0111 1

3 2

42
Why an internet layer?
 Why not one big flat LAN?
 Different LAN protocols
 Flat address space not scalable

 IP provides:
 Global addressing
 Scaling to WANs
 Virtualization of network
isolates end-to-end protocols
from network details/changes
“hourglass model”
(Steve Deering)
43
IP addressing: introduction
223.1.1.1

• IP address: 32-bit 223.1.2.1

identifier for host, router
interface 223.1.1.2
223.1.1.4 223.1.2.9

• interface: connection
between host/router and 223.1.3.27
223.1.1.3
physical link 223.1.2.2

• router’s typically have

multiple interfaces
• host typically has one or 223.1.3.1 223.1.3.2
two interfaces (e.g., wired
Ethernet, wireless 802.11)
• IP addresses associated 223.1.1.1 = 11011111 00000001 00000001 00000001
with each interface
223 1 1 1

44
 IP addressing: “class-full”
class
1.0.0.0 to
A 0 network host 127.255.255.255

B network 128.0.0.0 to
10 host
191.255.255.255
192.0.0.0 to
C 110 network host
223.255.255.255
224.0.0.0 to
D 1110 multicast address
239.255.255.255

32 bits

• Class-full addressing:
• inefficient use of address space, address space exhaustion
• e.g., class B net allocated enough addresses for 65K hosts, even
if only 2K hosts in that network
45
IP addressing: “class-less”
CIDR: Classless Inter-Domain Routing
• subnet portion of address of arbitrary length
• address format: a.b.c.d/x, where x is # bits in subnet portion of
address

subnet host
part part
11001000 00010111 00010000 00000000
200.23.16.0/23

46
Address Allocation for Private Internets
• RFC1918

10.0.0.0/8
Private address 172.16.0.0/16 → 172.31.0.0/16
192.168.0.0/24 → 192.168.255.0 /24
Loopback address 127.0.0.0 /8
224.0.0.0
Multicast address
～239.255.255.255

• Link local address: 169.254.0.0/16

47
 NAT: network address translation

rest of local network

Internet (e.g., home network)
10.0.0/24 10.0.0.1

10.0.0.4
10.0.0.2
138.76.29.7

10.0.0.3

all datagrams leaving local datagrams with source or

network have same single destination in this network
source NAT IP address: have 10.0.0/24 address for
138.76.29.7,different source source, destination (as usual)
port numbers
48
 NAT: network address translation
motivation: local network uses just one IP address as far as
outside world is concerned:
• range of addresses not needed from ISP: just
one IP address for all devices
• can change addresses of devices in local
network without notifying outside world
• can change ISP without changing addresses of
devices in local network
• devices inside local net not explicitly
addressable, visible by outside world (a security
plus)
49
NAT: network address translation
implementation: NAT router must:

• outgoing datagrams: replace (source IP address, port #) of

every outgoing datagram to (NAT IP address, new port #)
. . . remote clients/servers will respond using (NAT IP
address, new port #) as destination addr

• remember (in NAT translation table) every (source IP

address, port #) to (NAT IP address, new port #)
translation pair

• incoming datagrams: replace (NAT IP address, new port #)

in dest fields of every incoming datagram with
corresponding (source IP address, port #) stored in NAT
table
50
 NAT: network address translation
NAT translation table 1: host 10.0.0.1
2: NAT router WAN side addr LAN side addr
changes datagram sends datagram to
source addr from 138.76.29.7, 5001 10.0.0.1, 3345 128.119.40.186, 80
10.0.0.1, 3345 to …… ……
138.76.29.7, 5001,
updates table S: 10.0.0.1, 3345
D: 128.119.40.186, 80
10.0.0.1
1
S: 138.76.29.7, 5001
2 D: 128.119.40.186, 80 10.0.0.4
10.0.0.2
138.76.29.7 S: 128.119.40.186, 80
D: 10.0.0.1, 3345
4
S: 128.119.40.186, 80
D: 138.76.29.7, 5001 3 10.0.0.3
4: NAT router
3: reply arrives changes datagram
dest. address: dest addr from
138.76.29.7, 5001 138.76.29.7, 5001 to 10.0.0.1, 3345

51
NAT: network address translation
• 16-bit port-number field:
• 60,000 simultaneous connections with a single
LAN-side address!
• NAT is controversial:
• routers should only process up to layer 3
• violates end-to-end argument
• NAT possibility must be taken into account by app
designers, e.g., P2P applications
• address shortage should instead be solved by
IPv6
52
NAT traversal problem
• client wants to connect to
server with address 10.0.0.1 10.0.0.1
• server address 10.0.0.1 local to client
LAN (client can’t use it as ?
destination addr) 10.0.0.4
• only one externally visible NATed
address: 138.76.29.7 138.76.29.7 NAT
router
• solution1: statically configure
NAT to forward incoming
connection requests at given
port to server
• e.g., (123.76.29.7, port 2500)
always forwarded to 10.0.0.1 port
25000
53
NAT traversal problem
• solution 2: Universal Plug and
Play (UPnP) Internet Gateway 10.0.0.1
Device (IGD) Protocol. Allows
NATed host to: IGD
❖ learnpublic IP address
(138.76.29.7)
❖ add/remove port mappings (with NAT
lease times) router

i.e., automate static NAT port map

configuration

54
 NAT traversal problem
• solution 3: relaying (used in Skype)
• NATed client establishes connection to relay
• external client connects to relay
• relay bridges packets between to connections

2. connection to
relay initiated 1. connection to 10.0.0.1
by client relay initiated
by NATed host
3. relaying
client established
138.76.29.7 NAT
router

55
NAT traversal problem
• solution 4: NAT hole punching. Example: STUN protocol

56