Chap-4-Transport_layer
Chap-4-Transport_layer
Chap-4-Transport_layer
LAYER
Dr.K.Suresh
Babu
Professor of
CSE JNTUH
Transport Layer 3-1
Introduction
Together with the network layer, the
transport layer is the heart of the protocol
hierarchy.
The network layer provides end-to-end
packet delivery using datagrams or virtual
circuits.
The transport layer builds on the network
layer to provide data transport from a
process on a source machine to a
process on a destination machine with a
desired level of reliability that is
independent of the physical networks
currently in use.
Transport Layer 3-2
Transport services and
protocols
provide logical
applicatio
ntransport
network
data link
communication between physical
reassembles
segments into
messages, passes to
app layer Transport Layer 3-3
Transport vs. network layer
network layer:
household
logical kids in Ann’s house
analogy:
12
communicati sending
on between letters to 12 kids in
hosts Bill’s house:
transport hosts = houses
processes = kids
layer: app messages =
logical letters in envelopes
communication transport protocol =
between Ann
and Bill who demux
processes to in-
relies on, house siblings
enhances, network-layer
network protocol = postal
layer service Transport Layer 3-4
Transport Layer 3-5
Transport Layer 3-6
Services Provided to the Upper
Layers
The ultimate goal of the transport layer is to
provide efficient, reliable, and cost-effective data
transmission service to its users, normally
processes in the application layer.
To achieve this, the transport layer makes use
of the services provided by the network layer.
The software and/or hardware within the
transport layer that does the work is called the
transport entity.
The transport entity can be located in the
operating system kernel, in a library package
bound into network applications, in a separate
user process, or even on the network interface
card.
Just as there are two types of network
service, connection-oriented and connectionless,
there are also two types of transport service.
transfer,and Transport Layer
Transport Layer 3-8
Transport Layer 3-9
Why 2
Layers?
The obvious question is this: if the transport layer service is so
similar to the network layer service, why are there two distinct layers?
The transport code runs entirely on the users’ machines, but the network layer mostly
runs on the
routers, which are operated by the carrier (at least for a wide area network).
What happens if the network layer offers inadequate service? What if it
frequently loses packets? What happens if routers crash from time to
time?
Problems occur, that’s what. The users have no real control over the network layer, so
they cannot solve the problem of poor service by using better routers or putting
more error handling in the data link layer because they don’t own the routers.
The only possibility is to put on top of the network layer another layer that improves
the quality of the service.
If, in a connectionless network, packets are lost or mangled, the transport
entity can
detect the problem and compensate for it by using retransmissions.
If, in a connection-oriented network, a transport entity is informed halfway
through a long transmission that its network connection has been
abruptly terminated, with no indication of what has happened to the data
currently in transit, it can set up a new network connection to the remote
transport entity.
In essence, the existence of the transport Transport Layer 3-
Transport Service Primitives
The transport primitives can be implemented as
calls to library procedures to make them
independent of the network primitives.
Application programmers can write code
according to a standard set of primitives and
have these programs work on a wide variety of
networks, without having to worry about dealing
with different network interfaces and levels of
reliability.
For this reason, many people have made a
qualitative distinction between layers 1 through 4
on the one hand and layer(s) above 4 on the
other.
The bottom four layers can be seen as the
transport service provider, whereas the
upper layer(s) are the transport service Transport Layer 3-
Transport Service Primitives
To allow users to access We will use the
transport service, the
term segment for
layer
transportmust provide from transport
messages sententity
some operations to the transport
to
application programs, that entity
TCP, . UDP and other
is, a transport service Internet protocols use this
interface. term. Some older
Each transport service protocols name
ungainly used the
has its own interface. (TransportProtocol
TPDU
Let us look into a Data Unit).
hypothetical transport
service primitives, that
are provided to the
application layer
Nesting of segments, packets, and frames
Segment
Segme
nt
Transport Layer 3
Transport Service Primitives
State diagram for a simple connection-oriented
service
Make a
socket
Try to
connect
..
.
CN5E by Tanenbaum &
Wetherall, © Pearson Education-
Socket Example – Internet File
Server
Client code
(cont.)
...
Write data
(equivalent to send)
Loop reading
(equivalent to receive)
until no more data; exit
implicitly calls close
Make a
socket
Assign
address
Prepare for
incoming
connectio
.. ns
Read (receive)
request and treat
as file name
Transport Layer 3-
ELEMENTS OF T R A N S P O RT
PROTOCOLS
Addressing »
Connection establishment »
Connection release »
Error control and flow control »
Multiplexing »
Crash recovery »
Transport Layer 3-
Addressi
ng
• Transport
layer adds
(Transport
Service
Access
Points)TSAPs
• Multiple
with
clients a and
servers
single
networ can
run
k on (IP)
a
• host
addres
TSAPs are
s
ports for CN5E by Tanenbaum &
Wetherall, © Pearson Education-
Addressi
ng
A possible scenario for a transport
connection is as follows:
1. A mail server process attaches itself to TSAP 1522 on
host 2 to wait for an incoming call. How a process
attaches itself to a TSAP is outside the networking model
and depends entirely on the local operating system. A
call such as our LISTEN might be used, for example.
2. An application process on host 1 wants to send an
email message, so it attaches itself to TSAP 1208 and
issues a CONNECT request. The request specifies
TSAP 1208 on host 1 as the source and TSAP 1522 on
host 2 as the destination. This action ultimately results
in a transport connection being established between
the application process and the server.
3. The application process sends over the mail
message.
4. The mail server responds to say that it will deliver
the message.
Connection
Establishment (1)
Key problem is to ensure reliability
even though packets may be lost,
corrupted, delayed, and
duplicated
Don’t treat an old or duplicate
packet as new
(Use ARQ and checksums for
loss/corruption)
Approach:
Don’t reuse sequence numbers within
twice the MSL (Maximum Segment
CN5E by Tanenbaum & Wetherall, © Pearson
Education- Prentice Hall and D. Wetherall,
2011
Connection
Establishment (2) space large
Use a sequence number
enough that it will not wrap, even
when sending at full rate
Clock (high bits) advances & keeps
state over crash
Spurious ACK
does not
connect
b) Duplicate CR
and DATA. b
X
Same plus )
X
DATA will be
rejected
(wrong ACK).
Connection Release
Releasing a connection is easier
than establishing one.
There are two styles of
terminating a connection:
asymmetric release and
symmetric release.
Asymmetric release is the way
the telephone system works: when
one party hangs up, the connection is
broken.
two unidirection connectio
Symmetric
al and release
requires each treats
ns be the
separate
separatel
one toas
connection released
Connection Release
Key problem is
to ensure
reliability while
releasing
Asymmetric release
(when one side
breaks X
connection) is
abrupt and may
lose data
Normal release
sequence, initiated
by transport user
on Host 1
DR=Disconn
ect Request
Both DRs are
ACKed by the
other side
Multiplexi Inverse
ng Multiplexing
CN5E by Tanenbaum &
Wetherall, © Pearson Education-
Crash
Application needs to help recovering
Recovery
from a crash
Transport can fail since A(ck) /
W(rite) not atomic
Transport Layer 3-
Regulating the Sending
Rate
Transport Layer 3-
Approaches towards congestion
control
two broad approaches towards congestion
control:
end-end network-assisted
congestion congestion
control:
no explicit control:
routers/switches
feedback provide feedback to
from network end systems
congestion single bit
inferred from indicating
end-system congestion (SNA,
observed loss, DECbit, TCP/IP
delay ECN, ATM)
approach taken explicit rate for
by TCP sender to
send at Transport Layer 3-
TCP congestion control: additive
increase multiplicative
decrease
approach: sender increases transmission rate
(window size), probing for usable bandwidth,
until loss occurs
additive increase: increase cwnd by 1
MSS every RTT until loss
additively increase window size …
detected …. until loss occurs (then cut window in
multiplicative decrease:
half)
cut cwnd in half
congestion window
cwnd: TCP sender
AIMD saw
tooth after loss
behavior:
size
probing for
bandwidth
tim
e
Transport Layer 3-
TCP Slow
Start
when connection
Host
A
Host
B
begins, increase rate
exponentially until
first loss event:
RTT
initially cwnd = 1
MSS
double cwnd every
RTT
done by
incrementing
cwnd for
every ACK tim
received e
summary: initial
rate is slow but Transport Layer 3-
TCP: detecting, reacting to
loss
loss indicated by timeout:
cwnd set to 1 MSS;
window then grows exponentially (as in
slow start) to threshold, then grows
linearly
loss indicated by 3 duplicate ACKs: TCP
RENO
dup ACKs indicate network capable of
delivering
some segments
cwnd is cut in half window then grows
linearly
Transport Layer 3-
TCP: switching from slow start
towhen
Q: CAshould
the
exponential
increase switch
to linear?
A: when cwnd
gets to 1/2 of
its value before
timeout.
Implementatio
n:
variable
ssthresh
on loss event,
ssthresh is set to Transport Layer 3-
Internet transport-layer
protocols
reliable, in-
applicatio
ntransport
network
congestion link
physica
physical
networ
l k data
control link
physica
flow control l
networ
k data
link
physic
connection al network
data link
setup physic
networ al
k data applicatio
unreliable, physic
link
al networ
d
kata
ntransport
network
unordered
data link
link
physic
al physical
delivery: UDP
no-frills extension
of
“best-effort” IP
Transport Layer 3-
Multiplexing/
demultiplexing
multiplexing at
handle
sender:data from demultiplexing at
sockets,
multiple add transport use header info to
receiver:
header (later used for deliver received
demultiplexing) segments to correct
socket
applicatio
n
application application socket
P1
P3 P2 P4
proces
transport transport s
transpo
network rt network
link network link
physical physic
link
al
physica
l
Transport Layer 3-
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 applicati
each segment has on data
(payload)
source,
destination port
number TCP/UDP segment
format
host uses IP
addresses & port
Transport Layer 3-
Connectionless
demultiplexing
recall: created socket recall: when
has host-local port creating datagram
#:
DatagramSocket mySocket1 UDP
to send socket,
into must
= new DatagramSocket(12534);
specify
destination IP
address
when host receives destination
IP datagrams port
with #
UDP segment: same dest. port #,
checks destination but different source
port # in IP addresses and/or
segment source port numbers
will be directed to
directs UDP same socket at dest
segment to socket
with that port #
Transport Layer 3-
Connectionless demux:
example DatagramSocket
serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new DatagramSocket mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); applicatio (5775);
application n application
P3 P1 P4
transpo
transport rt transport
networ
network k lin network
link k
physic link
physical al physical
Transport Layer 3-
UDP: User Datagram Protocol
[RFC 768]
“no frills,” “bare UDP use:
bones” Internet streaming
transport protocol multimedia apps
“best effort” (loss tolerant, rate
service, UDP sensitive)
segments may be: DNS
lost SNMP
delivered out-of-
order to app
reliable transfer
over UDP:
connectionless: add reliability at
no handshaking
application layer
between UDP application-specific
sender, receiver
each UDP error recovery!
segment
handled Transport Layer 3-
UDP: segment header
length, in bytes
32 of UDP
bits segment,
source port dest port
including
# length # header
checksu why is there a
m UDP?
no connection
applicati establishment (which
on data can add delay)
(payload) simple: no
connection state at
sender, receiver
small header size
UDP segment
format
no congestion
control: UDP can
blast away as fast
as desired Transport Layer 3-
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in
transmitted segment
sende receive
treat segment compute checksum of
r: contents, including r:
received segment
header fields, as check if computed
sequence of 16-bit
integers checksum equals
checksum field value:
checksum: N O - error detected
addition (one’s
complement YES - no error
sum) of detected. But maybe
segment errors nonetheless?
contents More later
sender puts …. Transport Layer 3-
Internet checksum:
example
example: add two 16-bit
integers 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
su 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
m 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
checksu
m
Transport Layer 3-
Selective repeat: sender, receiver
windows
Transport Layer 3-
Selective
repeat
sender receiver
data from above: pkt n in [rcvbase,
if next available seq rcvbase+N-1]
# in window, send send ACK(n)
pkt out-of-order: buffer
timeout(n): in-order: deliver (also
resend pkt n, deliver buffered, in-
restart timer order pkts), advance
ACK(n) in window to next not-
[sendbase,sendbase+N]: yet-received pkt
mark pkt n as pkt n in [rcvbase-N,rcvbase-
received 1]
if n smallest unACKed
ACK(n)
pkt, advance window otherwise:
base to next ignore Transport Layer 3-
Selective repeat in
action
sender window sender receiv
(N=4)
012 4567 send er
312
0 8567
4 pkt0
3
012 8
4567 send receive pkt0, send
312 4
8567 pkt1 ack0
0 Xlos
3 8 send receive pkt1, send
pkt2
s receive
ack1 pkt3,
01 2 3 5 6 7 send buffer,
0 4 2 3 48 pkt3 send ack3
1 5
(wait) receive pkt4,
record ack3
buffer,
arrivedrcv ack0,
pkt 2 send ack4
send receive pkt5,
01 234 67 timeout
pkt4 buffer,
5 8 send pkt2
0 234 67 678 rcv senpkt2,
rcv pkt2; deliver
record ack4 d ack5
1 5 8 ack1, pkt3, pkt4, pkt5; send
01 234 67 arrived record
send ack2
5 8
Q: what
ack5 happenspkt5when ack2 does not
arrived
01 234 67
5 8
arrive?
Transport Layer 3-
sender receiver
Selective window
(after
window (after
receipt)
repeat: receipt)
2
01 301 pkt0
dilemma
2 pkt 01 2 0 1
01 301
2 2 3 2
01 301 1 0 23 1
2 2 1 0 2
pkt 01 30 2
01 2 0 1 pkt3 2 1
example: 3 2
0 23 1
2 X
seq #’s: 0, 1, 2, 3 1 0 2 pkt0 will accept
packet with seq
window size=3 (a) no number 0
problem
receiver receiver can’t see sender side.
sees receiver behavior identical in both
no difference cases!
in two something’s (very)
scenarios! 0 1 3 0 1 wrong!
pkt
2 2 0
duplicate data 01 301 01 2 0 1
2 2 3 2
pkt 0 23 1
accepted as 01
2
301
2
1
1 0
01 30 2
2
Q:new
whatinrelationship
(b) pkt
2 1
between seq # timeo
retransmit
ut 2 X
size and window pkt0
01 301 pkt
0X will accept
size to avoid 2 2
X packet with seq
(b)
A: problem in (b)? number 0
window size <= oops!
Transport Layer 3-
TCP: RFCs: 793,1122,1323, 2018,
2581
Overview
point-to-point: full duplex data:
one sender, one bi-directional data
receiver flow
reliable, in-order in same connection
MSS: maximum
byte steam:
segment size
no
“message
connection-
boundarie oriented:
s” handshaking
pipelined: (exchange of
TCP congestion and control msgs) inits
flow control set sender, receiver
window size state before data
exchange
Transport Layer 3-
TCP segment
structure 32
URG: urgent bits
countin
data (generally source port # dest port # g by
not used) bytes
sequence number
ACK: ACK acknowledgement of data
# headnumber (not
receive
valid U AP R S F segme
window # bytes
checksu Urg data nts!)
PSH: not len rcvr
m pointer
RST,push
SYN,data willing to
used options (variable
FIN: now accept
length)
connection
(generall
estab (setup,
y not
application
teardown
used)
Intern
commands) data
et (variable
checksum length)
(as in
UDP)
Transport Layer 3-
TCP seq. numbers,
ACKs
sequence numbers:
outgoing segment from
sender
source port
#
dest port #
sequence number
byte stream acknowledgement
“number” of number
checksum
rwnd
urg pointer
first byte in window
segment’s data size N
acknowledgements:
seq # of next byte
sender sequence number
expected from other space
side sent sent, usable not
ACKe not- yet
cumulative ACK d ACKed but not
(“in-
flight” usable yet
Q: how receiver sent
) incoming segment to
handles out-of-order sender
source port
#
dest port #
doesn’t say, A
checksum
rwnd
urg pointer
- up to Transport Layer 3-
TCP seq. numbers,
ACK s Host Host
A B
Use
r
type Seq=4 ACK=79 data =
s 2, , ‘C’ host ACKs
‘C
’ receipt of
‘C’,
Seq=79, ACK=43, data = echoes
host ‘C’
ACKs back ‘C’
receip
t of Seq=43,
echoed ACK=80
‘
C’ simple telnet
scenario
Transport Layer 3-
TCP round trip time,
timeout
Q: how to set Q: how to estimate
TCP timeout RTT?
value? SampleRTT:
measured time from
longer than RTT segment
but RTT varies transmission until
too short: ACK receipt
ignore
premature
timeout, retransmissions
unnecessary
SampleRTT will vary,
want estimated RTT
retransmissions “smoother”
too long: slow average several
reaction to recent
segment loss measurements, not
Transport Layer 3-
TCP reliable data
transfer
TCP creates rdt
service on top of
IP’s unreliable
service
pipelined segments let’s initially consider
cumulative acks simplified TCP
single sender:
retransmission ignore duplicate
timer acks
retransmissio ignore flow control,
ns triggered congestion control
by:
timeout
events Transport Layer 3-
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
Transport Layer 3-
Agreeing to establish a
connection
2-way
handshake: Q: will 2-way
handshake always
work in network?
Let’s
talk ESTA
variable delays
OK B
ESTA retransmitted
B messages (e.g.
req_conn(x)) due to
message loss
choose
message reordering
req_conn(
x
x) ESTA
can’t “see” other
acc_conn(
ESTA x)
B side
B
Transport Layer 3-
Agreeing to establish a
connection
2-way handshake failure
scenarios:
choose choose
req_conn( x req_conn(
x
x) ESTA x) ESTA
retransm B retransm acc_conn( B
acc_conn(
it it x)
x) req_conn(
req_conn(
x) x)
data(x+ accept
req_conn( 1)
EST EST data(x+
x)
AB AB 1)
connection connectio
clien x server retrans nx serve
clien
mit completes
t completes forgets t data(x+ rforgets x
terminat x terminat req_conn(x)
es 1)
es
ESTA ESTAB
data(x+ accept
half open B
1) data(x+
connection! 1)
(no client!)
Transport Layer 3-
TCP 3-way
handshake
client server
state state
LISTEN choose init seq LISTE
num, x send TCP
SYN msg
N
SYNSEN SYNbit=1,
T Seq=x choose init seq
num, y send TCP
SYNACK msg, SYN
SYNbit=1, Seq=y acking SYN RCVD
ACKbit=1;
received ACKnum=x+1
ESTA SYNACK(x)
indicates server is
B live; send ACK for ACKbit=1,
SYNACK;
this segment may ACKnum=y+1 received ACK(y)
contain client-to- indicates client is
server data live ESTA
B
Transport Layer 3-
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
Transport Layer 3-
TCP: closing a
connection
client state server
state
ESTAB
clientSocket.close() ESTAB
FIN_WAIT_ can no FINbit=1,
1 longer seq=x
send but CLOSE_WAI
can ACKbit=1; T
receive can still
FIN_WAIT_ wait for ACKnum=x+1 send
data server
2 data
close
LAST_AC
FINbit=1, K
TIMED_WAI seq=y can no
longer send
T data
ACKbit=1;
timed ACKnum=y+1
wait for 2*max CLOSE
segment
lifetime
D
CLOSE
D
Transport Layer 3-
Fairness
(more)
Fairness and UDP Fairness, parallel
multimedia apps TCP
often do not use connections
TCP application can open
do not want rate multiple parallel
throttled by connections between
congestion control
two hosts
instead use UDP: web browsers do this
send audio/video at
constant rate, e.g., link of rate R
tolerate packet loss with 9 existing
connections:
new app asks for 1 TCP,
gets rate
R/10
Transport Layer 3-
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: