Packet Network Performance

* Three main metrics

** Throughput – rate at which we can move data across a network.

** Delay – Time required for packet to go from end-to-end.
** Data loss – Fraction of data that is corrupted or discarded by network.

* What constrains network performance?

** Physical infrastruture – data rate of network links, propagation delay of signals,

interference/noise.
** Competing traffic – creates queuing delays, packet loss due to queue overflow.

* Providing performance guarantees

** Requires reserving network capacity for specific traffic streams.

** Can be done in packet networks and is done with many private networks- no
support for this in public internet.
 Delays in Networks
* Speed-of-light delay

** In fiber, about 130000 miles/s.

** NY to LA is about 5000 km, so 23ms. (but network links add distance making
30 ms a better estimate).

* Transmission delay – determined by data rate of links

** On 1 Mb/s link, takes 10 ms to send a 10000 bit packet.

** On 10 Gb/s link takes 1 micro sec, and on 50 Kb/s links takes 200 ms.

* Queuing delays

** Each link in a network is preceded by a queue.

*** Implemented using memory.
*** Packets must wait for those ahead of them in the queue.
** Depends on number/length of packets in queue and link speed.
** For lightly loaded links, rarely more than 10 packets in queue.
** On overloaded links, queuing delays may exceed 100 ms.
 Delays in Networks
transmission
A
propagation

B
nodal
processing queueing

Total Delay= PD+QD+TD+PropD

TD = L/R, Where L = Packet length, R = Link bandwidth (bps)

PropD = d/s Where d = distance of link, s = propagation speed in medium

QD = a L/R Where L = Packet length, R = Link bandwidth (bps) and a =

Average packet arrival rate.
* La/R ~ 0 : avg. Queuing delay is small.
* La/R -> 1 : avg. Queuing delay is large.
* La/R > 1 : more work is arriving than can be serviced, avg. Delay is
infinite.
 Other Sources of delay
* Packetization delay – time to acquire data to be sent

** voice typically encoded at 32 Kb/s (4 bytes per milliseconds).

** So, if we limit packetization delay to 20 ms, each packet carries 80 bytes of
voice data.
** An internet packet has about 50 bytes of “overhead” (40% of total).
** Can reduce overhead percentage by increasing delay.
** For telephony, need to limit delay for good user experience.

* Component processing delay

** Components like routers, wireless access points and hosts consume some
time processing packets.
*** for routers this includes checking packets for errors and determining where
they should go next.
** added to other delays (like queuing , transmission).
** typically fairly small: 1-10 micro seconds for routers, 10-50 micro seconds for
hosts.
 End-To-End Delay
3 probes 3 probes

3 probes
 Packet loss
* Bits corrupted on links

** very rare in fiber – typically, less than 1 bit in 10^12 have errors.
** Far more frequent in wireless – one in 10^3 to one in 10 ^5.
*** also highly variable: interference, distance from access point.
*** can reduce using varity of coding techniques.
** Electrical signals over wire – intermediate error rates.
** Errors detected by routers, which discard corrupted packets.

* Losses due to lack of space in packet queues

** can be kept close to zero if traffic flows are regulated to avoid overloads.
** but very common in internet (packet loss rates of 2-20% are not unusual).

* Components like routers may corrupt packet data

** Extremely rare in correctly functioning components.

 Throughput
* Rate (bits/time unit) at which bits transferred between sender/receiver.

* Instantaneous : rate at given point in time

* Average : rate over longer period of time

Suppose Host A wants to send a large file to Host B. The path from Host A to Host B has four
links, of rates R1 = 500 kbps, R2 = 2 Mbps, R3 = 1 Mbps and R4=3Mbps. Assuming no other
traffic in the network, what is the throughput for the file transfer?

Answer: 500 kbps

Consider a LAN with a maximum distance of 2km. At what bandwidth would propagation
delay (at a speed of 1 x 108 m/s) equals to transmit delay for 100-byte packets? What
about 512-byte packets?.
Solution

prop delay = distance / prop speed

= 2 * 10^3 m / 1 * 10^8 mps = 1 * 10^-5 s = 20 us

trans time = size / bandwidth

For an 800 bit packet

= 800 b / x Mbps = 20 us

x = 40 Mbps= 5MBps

For a 4096 bit packet

x = approx 204.5 Mbps= 25.6 MBps

 OSI Reference Model

The International Standards Organization (ISO) proposal for

the standardization of various protocols used in computer
networks is called the Open Systems Interconnection
Reference Model.

Although the OSI model is a just a model (not a

specification), it is generally regarded as the most complete
model.
OSI Reference Model
Application Layer:
● The Application Layer is where users interact with the system.
● Applications such as Telnet, FTP, SMTP, mail, http, live at this layer.
● The Application layer is responsible for coding the message.
● An Application Layer Header is added to the data.

Presentation Layer:
● Translation, cryptography, and code conversion take place at this level.
● A common Language is determined.
● Data Compression occurs.
● Data Encryption occurs.
● Big endians, little endians: data can be encoded prior to transmission data can
be decoded upon receipt.

Session Layer:
● Managing dialog control: Traffic can go in both directions at the same time, or
in only one direction at a time.
● Token management: both sides do not attempt the same operation at the same
time.
● Synchronization:Insertion of checkpoints to determine portions of
transmissions.
Transport Layer:

● Frees upper layers from the concerns of achieving data transfer.

● The transport layer deals with accepting data from its higher layer, splitting
it up into smaller units if necessary, and then passing these units to the
network layer.

● This layer also ensures that all of the units arrive correctly at the other end,
and that all of this is done efficiently and in such a way as to isolate the
upper layers.

● Design issues include:

● Connection orientation
● Flow control:The issue of ensuring that a fast machine does not
swamp a slow machine, must be considered.
● The possible use of multiple connections: Normally, the transport
layer creates a distinct network connection for each connection
required by the session layer.
● The possible use of multiplexing: If high throughput is required, and
multiple connections are too expensive, then may multiplex several
connections onto the same connection.
● Controlling congestion.
● What type of service to provide: point-to-point isolated messages
broadcast
Network Layer:

● The network layer deals with controlling the operation of the subnet.

● The subnet contains switching elements and hosts between two

computers.

● Design issues include:

● How to route packets from a source to a destination (routing).

There may be many paths depending upon network topology.

● Controlling congestion

● Accounting functions

● Different addressing and size requirements, and protocols used

when interconnecting heterogeneous networks (translation
between different network types).

● packet headers

● virtual circuits
Data Link Layer:
● The data link layer deals with taking a raw transmission facility and
transforming it into a line that appears free of undetected transmission
errors to the network layer.

● Design issues include:

● Frame boundaries: The data link layer performs its primary task by
breaking the input data into frames.

● Possible errors in frame data: A noise burst on the line can

completely destroy a frame.

● Transmission rate: Some traffic regulation mechanism must be

employed to ensure that a very fast machine doesn't send data at
such a high rate that it "swamps" the receiving machine.

● How to resolve competition for the line when full duplex transmission
is used.

Physical Layer:
● The physical layer deals with the transmission of raw bits over a
communication channel.

● Mechanical, electrical and procedural interfaces, the transmission

medium.
 Some apps

● E-mail ● voice over IP (e.g., Skype)

● Web ● real-time video conferencing

● text messaging ● social networking

● remote login ● search

● P2P file sharing

● multi-user network games

● streaming stored video

(YouTube, Hulu, Netflix)
Creating a network app application
transport
network
write programs that: data link
physical
● run on (different) end systems

● communicate over network

● e.g., web server software

communicates with browser
software

no need to write software for application

network-core devices: transport
network
data link application
physical transport
● network-core devices do not run network
user applications data link
physical

● applications on end systems allows

for rapid app development,
propagation
 Application architectures

possible structure of applications:

● Client-server

● peer-to-peer (P2P)
 Client-server architecture

server:

● always-on host

● permanent IP address

● data centers for scaling

clients:

client/server
● communicate with server

● may be intermittently connected

● may have dynamic IP addresses

● do not communicate directly with

each other
 P2P architecture
● no always-on server
peer2peer
● arbitrary end systems directly
communicate

● peers request service from other

peers, provide service in return to
other peers

○ self scalability – new peers

bring new service capacity, as
well as new service demands

● peers are intermittently connected

and change IP addresses
○ complex management
 Processes communicating

clients, Servers
process: program running within a
host

● within same host, two processes client process: process that initiates
communicate using inter-process communication
communication (defined by OS)
server process: process that waits
to be contacted
● processes in different hosts
communicate by exchanging
messages
● aside: applications with P2P
architectures have client
processes & server processes
 Sockets

● process sends/receives messages to/from its socket

● socket analogous to door

○ sending process shoves message out door

○ sending process relies on transport infrastructure on other side of door
to deliver message to socket at receiving process

application application
socket controlled by
process process app developer

transport transport
network network controlled
link by OS
link Internet
physical physical
 Addressing processes

● to receive messages, process ● identifier includes both IP

must have identifier address and port numbers
associated with process on
● host device has unique 32-bit host.
IP address
● example port numbers:
● Q: does IP address of host on ○ HTTP server: 80
which process runs suffice for ○ mail server: 25
identifying the process?
● to send HTTP message to
gaia.cs.umass.edu web server:
▪ A: no, many processes can
be running on same host ○ IP address: 128.119.245.12
○ port number: 80
 App-layer protocol defines

● types of messages open protocols:

exchanged, ● defined in RFCs
○ e.g., request, response
● allows for interoperability
● message syntax:
○ what fields in messages & ● e.g., HTTP, SMTP
how fields are delineated
proprietary protocols:
● message semantics
● e.g., Skype
○ meaning of information in
fields

● rules for when and how

processes send & respond to
messages
What transport service does an app need?
data integrity throughput
● some apps (e.g., multimedia)
● some apps (e.g., file transfer,
require minimum amount of
web transactions) require 100%
throughput to be “effective”
reliable data transfer

● other apps (“elastic apps”)

● other apps (e.g., audio) can
make use of whatever
tolerate some loss
throughput they get

timing security
● ● encryption, data integrity, …
 Transport service requirements: common apps

application data loss throughput time sensitive

file transfer no loss elastic no

e-mail no loss elastic no
Web documents no loss elastic no
real-time audio/video loss-tolerant audio: 5kbps-1Mbps yes, 100’s msec
video:10kbps-5Mbps
stored audio/video loss-tolerant same as above yes, few secs
interactive games loss-tolerant few kbps up yes, 100’s msec
text messaging no loss elastic yes and no
Internet apps: application, transport protocols

application underlying
application layer protocol transport protocol

e-mail SMTP [RFC 2821] TCP

remote terminal access Telnet [RFC 854] TCP
Web HTTP [RFC 2616] TCP
file transfer FTP [RFC 959] TCP
streaming multimedia HTTP (e.g., YouTube), TCP or UDP
RTP [RFC 1889]
Internet telephony SIP, RTP, proprietary
(e.g., Skype) TCP or UDP
 Web and HTTP

● web page consists of objects

● object can be HTML file, JPEG image, Java applet, audio file,…

● web page consists of base HTML-file which includes several

referenced objects

● each object is addressable by a URL, e.g.,

www.someschool.edu/someDept/pic.gif

host name path name

 HTTP overview

HTTP: hypertext transfer

protocol HT
TP
re que
❖ Web’s application layer st
protocol PC running
Firefox browser
❖ client/server model HT
TP
res st
pon ue
▪ client: browser that P
sreeq
requests, receives, (using T
HT server
HTTP protocol) and running
“displays” Web objects nse
po Apache Web
P res server
T
▪ server: Web server sends HT
(using HTTP protocol) iphone running
objects in response to Safari browser
requests
 HTTP overview (cont..)

uses TCP: HTTP is “stateless”

● client initiates TCP connection
(creates socket) to server, ● server maintains no
port 80 information about past
client requests
● server accepts TCP
connection from client aside
protocols that maintain “state”
are complex!
● HTTP messages
(application-layer protocol ● past history (state) must be
messages) exchanged maintained
between browser (HTTP
client) and Web server (HTTP ● if server/client crashes, their
server) views of “state” may be
inconsistent, must be
● TCP connection closed reconciled
 HTTP connections

non-persistent HTTP persistent HTTP

● at most one object sent over ● multiple objects can be sent

TCP connection over single TCP connection
○ connection then closed between client, server

● downloading multiple objects

required multiple
connections
 Non-persistent HTTP
suppose user enters URL: (contains text,
www.someSchool.edu/someDepartment/home.index references to 10
jpeg images)
1a. HTTP client initiates TCP
connection to HTTP server
(process) at 1b. HTTP server at host
www.someSchool.edu on port www.someSchool.edu waiting
80 for TCP connection at port 80.
“accepts” connection, notifying
2. HTTP client sends HTTP client
request message (containing
URL) into TCP connection 3. HTTP server receives request
socket. Message indicates that message, forms response
client wants object message containing requested
someDepartment/home.index object, and sends message into
its socket
time
 Non-persistent HTTP (cont.)

4. HTTP server closes TCP

connection.

5. Steps 1-5 repeated for each of

10 jpeg objects
 Non-persistent HTTP: response time

RTT (definition): time for a small

packet to travel from client to
server and back

HTTP response time: initiate TCP

connection
● one RTT to initiate TCP
connection RTT
● one RTT for HTTP request and request
first few bytes of HTTP file
response to return time to
RTT transmit
● file transmission time file
● non-persistent HTTP response file
time = received
2RTT+ file transmission time
time time
 Persistent HTTP

non-persistent HTTP issues: persistent HTTP:

● requires 2 RTTs per object ● server leaves connection

open after sending response
● OS overhead for each TCP
connection ● subsequent HTTP messages
between same client/server
● browsers often open parallel sent over open connection
TCP connections to fetch
referenced objects ● client sends requests as
soon as it encounters a
referenced object

● as little as one RTT for all the

referenced objects
 HTTP request message

● two types of HTTP messages: request, response

● HTTP request message:

○ ASCII (human-readable format) carriage return character
line-feed character
request line
(GET, POST, GET /index.html HTTP/1.1\r\n
HEAD commands) Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept:
header text/html,application/xhtml+xml\r\n
lines Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
carriage return, Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
line feed at start Keep-Alive: 115\r\n
Connection: keep-alive\r\n
of line indicates \r\n
end of header lines
 Method types

HTTP/1.0: HTTP/1.1:
● GET ● GET, POST, HEAD

● POST ● PUT
○ uploads file in entity body
● HEAD to path specified in URL
○ asks server to leave field
requested object out of
response ● DELETE
○ deletes file specified in
the URL field
 HTTP response message

status line
(protocol
status code HTTP/1.1 200 OK\r\n
status phrase) Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02
GMT\r\n
header ETag: "17dc6-a5c-bf716880"\r\n
lines Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html;
charset=ISO-8859-1\r\n
\r\n
data, e.g., data data data data data ...
requested
HTML file
 HTTP response status codes

● status code appears in 1st line in

server-to-client response message.
● some sample codes:
200 OK
▪ request succeeded, requested object later in this msg
301 Moved Permanently
▪ requested object moved, new location specified later in this msg
(Location:)
400 Bad Request
▪ request msg not understood by server
404 Not Found
▪ requested document not found on this server
505 HTTP Version Not Supported
 User-server state: cookies
example:
many Web sites use cookies ● Susan always access Internet
four components: from PC
1) cookie header line of HTTP ● visits specific e-commerce site
response message for first time
2) cookie header line in next ● when initial HTTP requests
HTTP request message arrives at site, site creates:
3) cookie file kept on user’s ○ unique ID
host, managed by user’s ○ entry in backend database
browser for ID
4) back-end database at Web
site
 Cookies: keeping “state” (cont.)

client server

ebay 8734
usual http request msg Amazon server
cookie file creates ID
usual http response 1678 for user create backend
ebay 8734
set-cookie: 1678 entry database
amazon 1678
usual http request msg
cookie: 1678 cookie- access
specific
usual http response msg action

one week later:

access
ebay 8734 usual http request msg
amazon 1678 cookie: 1678 cookie-
specific
usual http response msg action
 Cookies (cont..)
aside
what cookies can be used for:
● authorization cookies and privacy:
● shopping carts ● cookies permit sites to learn
● recommendations a lot about you
● user session state (Web
e-mail) ● you may supply name and
e-mail to sites

how to keep “state”:

● protocol endpoints: maintain state at
sender/receiver over multiple transactions
● cookies: http messages carry state
 More about Web caching

● cache acts as both client and why Web caching?

server ● reduce response time for client
○ server for original request
requesting client ● reduce traffic on an institution’s
○ client to origin server access link
● Internet dense with caches:
● typically cache is installed by enables “poor” content
ISP (university, company, providers to effectively deliver
residential ISP) content (so too does P2P file
sharing)
 Web caches (proxy server)

goal: satisfy client request without involving origin server

● user sets browser: Web HT

accesses via cache TP
rteq q u est
s ues re
u e t TP
● browser sends all HTTP e q HT
requests to cache TPr
H T proxy
○ object in cache: cache server
returns object client HTTP p o nse
res res origin
○ else cache requests pon T P
se HT server
object from origin server,
then returns object to
client
se
pon
es
T Pr
T
client H origin
server
 Conditional GET
client server
● Goal: don’t send object if
cache has up-to-date
cached version HTTP request msg
○ no object transmission If-modified-since: <date> object
delay not
○ lower link utilization modified
HTTP response
before
● cache: specify date of HTTP/1.0
<date>
cached copy in HTTP 304 Not Modified
request
If-modified-since: <date>
● server: response contains
no object if cached copy is HTTP request msg
up-to-date: If-modified-since: <date> object
HTTP/1.0 304 Not Modified modified
HTTP response after
HTTP/1.0 200 OK <date>
<data>
 DNS: domain name system

people: many identifiers: Domain Name System:

▪ SSN, name, passport # ● distributed database
Internet hosts, routers: implemented in hierarchy of
many name servers
▪ IP address (32 bit) - used
for addressing datagrams ● application-layer protocol:
hosts, name servers
▪ “name”, e.g., communicate to resolve names
www.yahoo.com - used (address/name translation)
by humans
○ note: core Internet function,
Q: how to map between IP
address and name, and vice implemented as
versa ? application-layer protocol
○ complexity at network’s
“edge”
 DNS: services, structure
DNS services why not centralize DNS?
● hostname to IP address ● single point of failure
translation
● host aliasing ● traffic volume
○ canonical, alias names
● mail server aliasing ● distant centralized database
● load distribution
○ replicated Web servers: ● maintenance
many IP addresses
correspond to one name
 DNS: a distributed, hierarchical database
Root DNS Servers

… …

com DNS servers org DNS servers edu DNS servers

pbs.org poly.edu umass.edu

yahoo.com amazon.com
DNS servers DNS serversDNS servers
DNS servers DNS servers

client wants IP for www.amazon.com; 1st approx:

● client queries root server to find com DNS server
● client queries .com DNS server to get amazon.com DNS server
● client queries amazon.com DNS server to get IP address for
www.amazon.com
 DNS: root name servers

● contacted by local name server that can not resolve name

● root name server:
○ contacts authoritative name server if name mapping not known
○ gets mapping
○ returns mapping to local name server

c. Cogent, Herndon, VA (5 other sites)

d. U Maryland College Park, MD k. RIPE London (17 other sites)
h. ARL Aberdeen, MD
j. Verisign, Dulles VA (69 other sites ) i. Netnod, Stockholm (37 other sites)

e. NASA Mt View, CA m. WIDE Tokyo

f. Internet Software C. (5 other sites)
Palo Alto, CA (and 48 other
sites)

a. Verisign, Los Angeles CA 13 root name

(5 other sites)
b. USC-ISI Marina del Rey, CA
“servers”
l. ICANN Los Angeles, CA worldwide
(41 other sites)
g. US DoD Columbus,
OH (5 other sites)
 TLD, authoritative servers

top-level domain (TLD) servers:

○ responsible for com, org, net, edu, aero, jobs, museums, and all
top-level country domains, e.g.: uk, fr, ca, jp
○ Network Solutions maintains servers for .com TLD
○ Educause for .edu TLD

authoritative DNS servers:

○ organization’s own DNS server(s), providing authoritative
hostname to IP mappings for organization’s named hosts
○ can be maintained by organization or service provider
 Local DNS name server

● does not strictly belong to hierarchy

● each ISP (residential ISP, company, university) has one

○ also called “default name server”

● when host makes DNS query, query is sent to its local DNS
server
○ has local cache of recent name-to-address translation pairs
(but may be out of date!)
○ acts as proxy, forwards query into hierarchy
 DNS name root DNS server
resolution example
2
● host at cis.poly.edu wants 3
TLD DNS server
IP address for 4
gaia.cs.umass.edu
5

iterated query: local DNS server

dns.poly.edu
● contacted server replies
with name of server to 7 6
1 8
contact
● “I don’t know this name, authoritative DNS server
but ask this server” dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu
 DNS name root DNS server
resolution example
2 3
recursive query: 7
6
❖ puts burden of name
TLD DNS
resolution on contacted server
name server
local DNS server
4
❖ heavy load at upper dns.poly.edu 5
levels of hierarchy? 1 8

authoritative DNS server

dns.cs.umass.edu
requesting host
cis.poly.edu

gaia.cs.umass.edu
 DNS: caching, updating records

● once (any) name server learns mapping, it caches mapping

○ cache entries timeout (disappear) after some time (TTL)
○ TLD servers typically cached in local name servers
■ thus root name servers not often visited

● cached entries may be out-of-date (best effort name-to-address

translation!)
○ if name host changes IP address, may not be known
Internet-wide until all TTLs expire

● update/notify mechanisms proposed IETF standard

○ RFC 2136
 DNS records

DNS: distributed db storing resource records (RR)

RR format: (name, value, type, ttl)

type=A type=CNAME
▪ name is hostname ▪ name is alias name for some
▪ value is IP address “canonical” (the real) name
▪ www.ibm.com is really
type=NS
▪ name is domain (e.g., servereast.backup2.ibm.com
foo.com) ▪ value is canonical name
▪ value is hostname of
authoritative name type=MX
server for this domain ▪ value is name of mailserver
associated with name
 DNS protocol, messages

● query and reply messages, both with same message format

2 2
b b
yt yt
msg header identificatio
e flage
n s ss
● identification: 16 bit # for # # answer
query, reply to query uses questio RRs
same # # authority
ns # additional
RRs RRs
● flags: questions (variable # of
○ query or reply questions)
○ recursion desired answers (variable # of
○ recursion available RRs)
○ reply is authoritative authority (variable # of
RRs)

additional info (variable # of

RRs)
 Attacking DNS

DDoS attacks Redirect attacks

● Bombard root servers with ● Man-in-middle
traffic ○ Intercept queries
○ Not successful to date ● DNS poisoning
○ Traffic Filtering ○ Send bogus relies to
○ Local DNS servers cache DNS server, which
IPs of TLD servers, caches
allowing root server Exploit DNS for DDoS
bypass
● Send queries with spoofed
● Bombard TLD servers source address: target IP
○ Potentially more ● Requires amplification
dangerous
 TCP: Overview

point-to-point: ● full duplex data:

one sender, one receiver ○ bi-directional data flow in
same connection
reliable, in-order byte stream: ○ MSS: maximum segment
no “message boundaries” size

pipelined: ● connection-oriented:
TCP congestion and flow ○ handshaking (exchange of
control set window size control msgs) inits sender,
receiver state before data
exchange

● flow controlled:
○ sender will not overwhelm
receiver
 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
 TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #

▪ byte stream “number” of first sequence number

acknowledgement
byte in segment’s data number rwn
d pointer
acknowledgements: checksum urg

▪ seq # of next byte expected window size

N
from other side
▪ cumulative ACK
Q: how receiver handles sender sequence number space
out-of-order segments
▪ A: TCP spec doesn’t say, - sent sent, usable not
up to implementor ACKed not-yet but not usable
ACKed yet sent
(“in-flight”)
incoming segment to sender
source port # dest port #
sequence number
acknowledgement
number
A rwn
checksum d pointer
urg
 TCP reliable data transfer

● TCP creates rdt service on top

of IP’s unreliable service let’s initially consider simplified
○ pipelined segments TCP sender:
○ cumulative acks ignore duplicate acks
○ single retransmission timer ignore flow control,
congestion control
● retransmissions triggered by:
○ timeout events
○ duplicate acks
 TCP sender events:

data rcvd from app: timeout:

● create segment with seq # retransmit segment that caused
timeout
● seq # is byte-stream number
of first data byte in segment restart timer
ack rcvd:
● start timer if not already
running if ack acknowledges previously
○ think of timer as for oldest unacked segments
unacked segment update what is known to be
○ expiration interval: ACKed
TimeOutInterval start timer if there are still
unacked segments
 Connection Management
before exchanging data, sender/receiver “handshake”:
● agree to establish connection (each knowing the other willing to
establish connection)

● agree on connection parameters

application application

connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client

network network

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
 TCP 3-way handshake

client server state

state
LISTEN LISTEN
choose init seq num,
x
SYNSEN send TCP SYN msg SYNbit=1, Seq=x
T choose init seq num,
y
send TCP SYNACK SYN
SYNbit=1, Seq=y msg, acking SYN RCVD
ACKbit=1;
received SYNACK(x) ACKnum=x+1
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1,
client-to-server data
ACKnum=y+1 received ACK(y)
indicates client is live
ESTAB
 TCP: closing a connection

● client, server each close their side of connection

○ send TCP segment with FIN bit = 1

● respond to received FIN with ACK

○ on receiving FIN, ACK can be combined with own FIN

● simultaneous FIN exchanges can be handled

 TCP: closing a connection

client state server state

ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1;
can still
FIN_WAIT_2 wait for server ACKnum=x+1 send data
close

LAST_A
FINbit=1, seq=y CK
TIMED_WAIT can no longer
send data
ACKbit=1;
timed wait ACKnum=y+1
for 2*max CLOSED
segment
lifetime

CLOSED