Chapter 2 Network & Transport Layer
Part II Transport Layer
Transport Layer Overview and Protocols
application
transport
Provide logical communication network
data link
between app processes running physical
on different hosts
lo
gi
Transport protocols run in end
ca
l
systems
en
d-
send side: breaks app
en
d
messages into segments,
tr
a ns
passes to network layer
po
r
rcv
t
side: reassembles applicatio
segments into messages, n
transport
passes to app layer network
data link
More than one transport physical
protocol available to apps
Internet: TCP and UDP
Transport vs. Network Layer
Network layer: logical communication between hosts
Transport layer: logical communication between
processes
Relies on, enhances, network layer services
Transport Services
Multiplexing, Demultiplexing
Reliable data transfer
Flow control
Congestion control
Multiplexing/Demultiplexing
Multiplexing at sender: Demultiplexing at receiver:
handle data from multiple
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
UDP: User Datagram Protocol [RFC 768]
“best effort” service, UDP UDP use:
segments may be: Streaming multimedia
lost apps (loss tolerant, rate
delivered out-of-order to sensitive)
app DNS
Connectionless: SNMP
No handshaking between Reliable transfer over
UDP sender, receiver UDP:
Each UDP segment Add reliability at
handled independently of application layer
others Application-specific
error recovery!
UDP: Segment Header
Length in bytes of UDP
32 bits segment, including
source port # dest port # header
length checksum
why is there a UDP?
No connection
application establishment (which can
data add delay)
(payload) Simple: no connection
state at sender, receiver
Small header size
No congestion control:
UDP segment format
UDP can blast away as
fast as desired
TCP: Overview RFCs: 793,1122,1323, 2018, 2581
Point-to-point: Full duplex data:
one sender, one receiver bi-directional data flow
Reliable, in-order byte in same connection
steam Connection-oriented:
Pipelined: handshaking (exchange
TCP congestion and of control msgs) inits
sender, receiver state
flow control set window before data exchange
size
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 #
sequence number
byte stream “number” of acknowledgement number
first byte in segment’s checksum
rwnd
urg pointer
data window size
acknowledgements: N
seq # of next byte
expected from other side sender sequence number space
sent sent, not- usable not
ACKed yet but not usable
ACKed yet sent
(“in-
flight”)
incoming segment to sender
source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer
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: connection state:
ESTAB ESTAB
connection variables: connection Variables:
seq # client-to- seq # client-to-
server server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
network
at server,client network
at server,client
Socket clientSocket = Socket connectionSocket =
newSocket("hostname","port [Link]();
number");
TCP 3-way Handshake
client state server state
LISTEN 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 ACKbit=1, ACKnum=y+1
contain
client-to-server data 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
[Link]()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime
CLOSED
Principles of Congestion Control
Congestion:
Informally: “too many sources sending too much
data too fast for network to handle”
Different from flow control!
Manifestations:
lost packets (buffer overflow at routers)
long delays (queueing in router buffers)
Flow Control and Congestion Control
Two different factors can limit the rate at
which a source sends data
The inability of the destination to accept new
data
Techniques that address this are referred to as
flow control.
The number of packets within the subnet.
Techniques that address this are referred to as
congestion control
Approaches to Congestion Control
An approach that can be used at either the network
or transport layers is
Rate control: this refers to techniques where the
source rate is explicitly controlled based on
feedback from either the network and/or the receiver
For example, routers in the network may send a
source a "choke packet" upon becoming
congested. When receiving such a packet, the
source should lower it rate
Congestion Control in TCP
TCP implements end-to-end congestion control
TCP detects congestion via the ACK's from the sliding-
window ARQ algorithm used for providing reliable service
When the source times out before receiving an ACK, the
most likely reason is because a link became congested
TCP uses this as an indication of congestion
TCP will slow down the transmission rate
TCP controls the transmission rate of a source by varying
the window size used in the sliding window protocol